From nobody Mon Oct 5 11:04:55 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 838C91B321B; Mon, 5 Oct 2015 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 iBCpB7t8KhQq; Mon, 5 Oct 2015 11:04:52 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C05D1B3207; Mon, 5 Oct 2015 11:04:49 -0700 (PDT) Received: by vkgd64 with SMTP id d64so102067187vkg.0; Mon, 05 Oct 2015 11:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R5RthneiaNbOjgM5+cSHhb7aLzqPAlzuk8EYqH/u8co=; b=W0Bqurb3CgPjNv3jOzg+MA4q9wfNPEgJ9DxT+ySczJ94pXxte9qBBIO9hMuTe6HBii wAs3C4XvYAWBYatLF93CnhkYol6G3snZ5idKQZATAYcO6Z2Y2tkTSmGyjPsxibU68VG4 WKWuHJMQelGzFvBH2OnTkEttlMvqKvraC4aR9J2uNJPXoohjyT7Sl3qNPA2VHiq6HeYi ZSk7kSvHGfclBTTTtxucamG8PGo3IZYm4ENfQHv5OsZQrBCdOkYRVlwQnSp59kXFoi+C SFKR7Ljk9Gff8E5KizKaCulboTKed024TFHlyh4a5vYLdEqEkxt/Ag9at7TLtCrsdDcZ pb0w== MIME-Version: 1.0 X-Received: by 10.31.49.67 with SMTP id x64mr20855555vkx.133.1444068288452; Mon, 05 Oct 2015 11:04:48 -0700 (PDT) Received: by 10.31.49.134 with HTTP; Mon, 5 Oct 2015 11:04:48 -0700 (PDT) Date: Mon, 5 Oct 2015 13:04:48 -0500 Message-ID: From: Lyle Bertz To: draft-ietf-dmm-fpc-cpdp@ietf.org, dmm@ietf.org Content-Type: multipart/alternative; boundary=001a1143fc925d5b9105215f5980 Archived-At: Subject: Re: [DMM] draft-ietf-dmm-fpc-cpdp-01 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, 05 Oct 2015 18:04:53 -0000 --001a1143fc925d5b9105215f5980 Content-Type: text/plain; charset=UTF-8 All, I took a look at the draft and am generally happy with it. I do have a few questions: 1. When looking at mapping something as common as an IPFilterRule to this specification, I understand why the direction value is left out as it is obvious and the use of the TrafficSelector makes the mappings straight forward, imo. However, the options portion of the IPFilterRule is left out of this current specficaiton. This could be added as other data to the rule with the understanding that it does add complexity and needs some language on matching beyond longest match for priority. Could the authors help me understand this design and if such options will not be supported how does a carrier support an IPFilterRule in mobility (other than never specifying no options in it)? Could some sort of extension be added to the rule because, imo, it does not belong to the port properties but I can be wrong here. 2. Drops are implicit (send packet to a port with no forwarding configuration) but as an operations person troubleshooting a solution using FPC is there something that can be done in this document (specification OR noting it as a warning) to make it obvious that a drop configuration was intentional vs a poor client not following through or some connection error condition? 3. This is a RFC 6088 question but why would there be a SPI range in a traffic selector and is that something necessary in FPC? Lyle --001a1143fc925d5b9105215f5980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I took a look at the draft and am = generally happy with it.=C2=A0 I do have a few questions:

1.=C2=A0 When looking at mapping something as common as an IPFilter= Rule to this specification, I understand why the direction value is left ou= t as it is obvious and the use of the TrafficSelector makes the mappings st= raight forward, imo.=C2=A0 However, the options portion of the IPFilterRule= is left out of this current specficaiton. =C2=A0 This could be added as ot= her data to the rule with the understanding that it does add complexity and= needs some language on matching beyond longest match for priority. =C2=A0 = Could the authors help me understand this design and if such options will n= ot be supported how does a carrier support an IPFilterRule in mobility (oth= er than never specifying no options in it)?=C2=A0 Could some sort of extens= ion be added to the rule because, imo, it does not belong to the port prope= rties but I can be wrong here.

2. Drops are implic= it (send packet to a port with no forwarding configuration) but as an opera= tions person troubleshooting a solution using FPC is there something that c= an be done in this document (specification OR noting it as a warning) to ma= ke it obvious that a drop configuration was intentional vs a poor client no= t following through or some connection error condition? =C2=A0=C2=A0
<= div>
3.=C2=A0 This is a RFC 6088 question but why would there= be a SPI range in a traffic selector and is that something necessary in FP= C? =C2=A0=C2=A0

Lyle

--001a1143fc925d5b9105215f5980-- From nobody Tue Oct 6 08:38: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 C54A41A014C; Tue, 6 Oct 2015 08:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 KAKU8LwxYl0t; Tue, 6 Oct 2015 08:38:03 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A051A01E7; Tue, 6 Oct 2015 08:38:02 -0700 (PDT) Received: by obbzf10 with SMTP id zf10so157037038obb.2; Tue, 06 Oct 2015 08:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3VajxkStK5+w71+a3atRATNWzJRDMXdDA3x0o5gGpPA=; b=00kNzGq2AGW0PsEbMtNOA7sKXFP/2scV+c1lqgve0N6UyeNA98Sj+LZNWv35iLJ2BY XFRjvofAwY9Sdghv9QdtY4fm1CzJAvru+/bj/IVgKjR0l4WgAB4OHnhpznOwl+qhTwoX MNsu/X1UlLRo2FOLdOq445QiW/rTfn3QQb4T+0azYWnGHwxmJS1/rh+gyJmv0ifnLwGi AcGLGbWAmjJCr58kbGVUGOAhBBBWS42DJChMJ0HhJxJzffIcJUzQWZi4jQ8Xi7OvsPYN 4R2epfxqkokPAkUEkPbw+b3JunNUBRQpMgaq4gAdw6gWt8JRruAg+2RnYuw+O3J7mDTc 3sQQ== MIME-Version: 1.0 X-Received: by 10.60.140.132 with SMTP id rg4mr22585647oeb.70.1444145881953; Tue, 06 Oct 2015 08:38:01 -0700 (PDT) Received: by 10.202.198.23 with HTTP; Tue, 6 Oct 2015 08:38:01 -0700 (PDT) Date: Tue, 6 Oct 2015 10:38:01 -0500 Message-ID: From: Lyle Bertz To: draft-ietf-dmm-fpc-cpdp@ietf.org, dmm@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a7e504c3d370521716a6a Archived-At: Subject: [DMM] Copying Traffic in FPC 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, 06 Oct 2015 15:38:04 -0000 --047d7b3a7e504c3d370521716a6a Content-Type: text/plain; charset=UTF-8 When looking at the latest draft I was curious about how copying for the purpose of troubleshooting / probes would be supported? My thought would be some sort of property on a port that copies the traffic and notes the PRT that it could be forwarded to. Could we support this use case (I am not married to the suggestion above) in the specification given its importance to trouble management? This is easy enough to support in underlying DPN technologies such as SDN and I see no reason to not specify it in FPC and avoid using yet another protocol for forwarding. Comments / Thoughts would be appreciated on this matter. Thank you. Lyle --047d7b3a7e504c3d370521716a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When looking at the latest draft I was curious about how c= opying for the purpose of troubleshooting / probes would be supported? =C2= =A0=C2=A0

My thought would be some sort of property on a= port that copies the traffic and notes the PRT that it could be forwarded = to. =C2=A0=C2=A0

Could we support this use case (I= am not married to the suggestion above) in the specification given its imp= ortance to trouble management? =C2=A0 This is easy enough to support in und= erlying DPN technologies such as SDN and I see no reason to not specify it = in FPC and avoid using yet another protocol for forwarding.

<= /div>
Comments / Thoughts would be appreciated on this matter.

Thank you.

Lyle=C2=A0
--047d7b3a7e504c3d370521716a6a-- From nobody Tue Oct 6 08:40:54 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 49A7D1A1A72 for ; Tue, 6 Oct 2015 08:40:53 -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 tbSVPG7RDllU for ; Tue, 6 Oct 2015 08:40:52 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e: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 318EC1A1A67 for ; Tue, 6 Oct 2015 08:40:52 -0700 (PDT) Received: by pacex6 with SMTP id ex6so213975268pac.0 for ; Tue, 06 Oct 2015 08:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=KjnhtHwpTVaJPycvL2LfQY3z4KzRCR3IINTCenmP1as=; b=m6Z5ICakU2gQrZBX2LCsuz4Xt0EFYivihSi8mYvc3Ne79MmiurqKokjBXoLUsRmrQ9 oLIYLcJG0g7Kr4WfzE70lKjZR3E16SJsCQ3s66xtgUhXfMjbQPnU+Wtrb+DQl0QE3PuW puY5d6UrwBfB7RZH3jwgW7flixMT+A9r70556ubPGkkFCSD8N0KACtZ6eoTagpZDdqfB rRkrEle3G292qO4a3vi1tNsAbuioJSaazw1Ov3+obSelz9OeGU5OfNg3CIRr8JV0vraj PaR5Koy3hWGTQAtdIA9hWD8eAlJBh+snwdk4LIC9sYdg6o2sW7uHBg82J90CZ2RZ6JHj 5/3g== X-Received: by 10.68.57.197 with SMTP id k5mr47548415pbq.142.1444146051810; Tue, 06 Oct 2015 08:40:51 -0700 (PDT) Received: from [10.16.11.20] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id ci2sm6418064pbc.66.2015.10.06.08.40.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Oct 2015 08:40:50 -0700 (PDT) To: "dmm@ietf.org" References: <5601AFC4.4030106@gmail.com> From: Jouni Korhonen Message-ID: <5613EB82.1040606@gmail.com> Date: Tue, 6 Oct 2015 08:40:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5601AFC4.4030106@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Agenda forming for IETF94 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, 06 Oct 2015 15:40:53 -0000 FYI a friendly reminder. 9/22/2015, 12:45 PM, Jouni Korhonen kirjoitti: > Folks, > > We have again requested 2.5h slot. If you want to have a slot send the > chairs a request, topic, "why" and time needed. The preference will be > on the existing charter items & documents. > > - Jouni & Dapeng From nobody Thu Oct 8 06:00:39 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 CADA71B3371; Thu, 8 Oct 2015 06:00:38 -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 sO9nnmhjhLxv; Thu, 8 Oct 2015 06:00:36 -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 A219C1B3370; Thu, 8 Oct 2015 06:00:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 663FD10AB92; Thu, 8 Oct 2015 15:00:33 +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 YQIQcjulLOjv; Thu, 8 Oct 2015 15:00:33 +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 4454E10AB8B; Thu, 8 Oct 2015 15:00:27 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.86]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Thu, 8 Oct 2015 15:00:27 +0200 From: Marco Liebsch To: Lyle Bertz , "draft-ietf-dmm-fpc-cpdp@ietf.org" , "dmm@ietf.org" Thread-Topic: draft-ietf-dmm-fpc-cpdp-01 Thread-Index: AQHQ/5hZNQN3s8VSpk+/F3Ni5IQnCJ5hjIsA Date: Thu, 8 Oct 2015 13:00:26 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DA63B5B44@PALLENE.office.hd> References: In-Reply-To: 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_69756203DDDDE64E987BC4F70B71A26DA63B5B44PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] draft-ietf-dmm-fpc-cpdp-01 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, 08 Oct 2015 13:00:39 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DA63B5B44PALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTHlsZSwNCg0KdGhhbmtzIGZvciB5b3VyIHBvc2l0aW9uIGFuZCBnb29kIGNvbW1lbnRzIHRv IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KRmlyc3Qgb2YgYWxsLCB0aGUgZHJh ZnQgaXMgbm90IGNvbXBsZXRlIGFuZCBmb3Igc3VyZSBuZWVkcyBmZWVkYmFjayBvbiByZXF1aXJl ZA0KY29udHJvbC4gU28sIHlvdXIgcHJvcG9zYWwgaXMgbW9yZSB0aGFuIHdlbGNvbWUuDQoNCk15 IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBjb21tZW50IGlzIHRoYXQgeW914oCZcmUgbG9va2luZyBm b3IgY29udHJvbCBvbiBhIHJ1bGUsIHRoYXQNCmZpbHRlcnMgdHJhZmZpYy4gVGhlIGN1cnJlbnQg c3BlYyBjb21wcmlzZXMgdHJhZmZpYyBkZXNjcmlwdG9ycywgYW5kIHByb3BlcnRpZXMsIHRoYXQN CmFwcGx5IHRvIHRoZSBkZXNjcmliZWQgdHJhZmZpYy4NCg0KSSBjYW4gaW1hZ2luZSB0d28gdHlw ZXMgb2YgZmlsdGVyczoNCigxKSBPbmUgaXMgYSBkZWZhdWx0IGZpbHRlciwgd2hpY2ggYXBwbGll cyB0byBhbGwgdHJhZmZpYyB0aGF0IGRvZXMgbm90IG1hdGNoIGFueSBvZg0KdGhlIGRlc2NyaXB0 aW9ucy4gQW4gYXNzb2NpYXRlZCBwcm9wZXJ0eSBjYW4gYmUgZHJvcCwgb3IgZm9yd2FyZCB0byBh IHBhcnRpY3VsYXINCklQIGFkZHJlc3MgYXMgbmV4dCBob3AuDQoNCigyKSBBbm90aGVyIGlzIHRo YXQgdHJhZmZpYywgdG8gd2hpY2ggdGhlIGZpbHRlciBhcHBsaWVzLCBpcyBleHBsaWNpdGx5IGRl c2NyaWJlZCB1c2luZyB0aGUNCnRyYWZmaWMgZGVzY3JpcHRvcnMuDQoNCkJvdGggcmVxdWlyZSBt aW5vciBleHRlbnNpb25zIG9mIHRoZSBzcGVj4oCZcyBhdHRyaWJ1dGVzIGxpc3QuIEl0IHdvdWxk IHJlcXVpcmUgYSB0cmFmZmljIGRlc2NyaXB0b3INCndoaWNoIGFwcGxpZXMgdG8gYWxsIG90aGVy IHRyYWZmaWMgZm9yIHdoaWNoIG5vIHByb3BlcnRpZXMgaGF2ZSBiZWVuIGNvbmZpZ3VyZWQuDQpB bHNvLCBhZGRpdGlvbmFsIHByb3BlcnRpZXMgbWF5IGJlIG5lZWRlZCB0byBjb25maWd1cmUgd2hh dCB0byBkbyB3aXRoIHRoZSBmaWx0ZXJlZCB0cmFmZmljLg0KDQpTdWNoIGZpbHRlcmluZyBjYW4g YmUgaW1wbGljaXQgYW5kIGVuZm9yY2VkIGJ5IERhdGEtUGxhbmUgZGV2aWNlIG1hbmFnZW1lbnQu DQpPcjogSWYgd2Ugd2FudCB0aGUgQ29udHJvbC1QbGFuZSB0byBlbmZvcmNlIGR5bmFtaWMgY29u ZmlndXJhdGlvbiB0byBmaWx0ZXIgcGFydGljdWxhcg0KdHJhZmZpYyBhbmQgY29udHJvbCB3aGF0 IHRvIGRvIHdpdGggdGhlIGZpbHRlcmVkIHRyYWZmaWMsIHRoZW4gd2UgY2FuIGFkZCB0aGUgYXNz b2NpYXRlZCBhdHRyaWJ1dGVzLg0KDQpJIGhvcGUgdGhhdCBhZGRyZXNzZXMgeW91ciBjb21tZW50 cyAxIGFuZCAyLiBBYm91dCBjb21tZW50IDM6IFdlIGFkZGVkIHRoZSB0cmFmZmljIHNlbGVjdG9y DQp0byBoYXZlIG1lYW5zIHRvIGRlc2NyaWJlIElQIGRhdGEgdHJhZmZpYyBtb3JlIGFjY3VyYXRl LCBub3Qgb25seSBwZXIgYWdncmVnYXRlZCBvciBwZXItaG9zdCBJUCBhZGRyZXNzZXMuDQpUaGF0 IGRvZXMgbm90IG1lYW4gYWxsIGZpZWxkcyBpbiB0aGUgVHJhZmZpYyBzZWxlY3Rvciwgc3VjaCBh cyB0aGUgU1BJLCBuZWVkIHRvIGJlIHVzZWQuDQoNCkJ1dCB0aGF0IG1ha2VzIG1lIGFjdHVhbGx5 IGF3YXJlIG9mIHRoZSBuZWVkIG9mIGFkZGl0aW9uYWwgdHJhZmZpYyBkZXNjcmlwdG9ycywgd2hp Y2ggaWRlbnRpZnkgdHJhZmZpYyBvbiBhIEdSRSBrZXkgb3IgYSBHVFAgVEVJRC4NCg0KV2hhdCBk byB5b3UgdGhpbms/DQoNClRoYW5rcywNCk1hcmNvDQoNCg0KDQpGcm9tOiBMeWxlIEJlcnR6IFtt YWlsdG86bHlsZWI1NTExNDRAZ21haWwuY29tXQ0KU2VudDogTW9udGFnLCA1LiBPa3RvYmVyIDIw MTUgMjA6MDUNClRvOiBkcmFmdC1pZXRmLWRtbS1mcGMtY3BkcEBpZXRmLm9yZzsgZG1tQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1kbW0tZnBjLWNwZHAtMDENCg0KQWxsLA0KDQpJ IHRvb2sgYSBsb29rIGF0IHRoZSBkcmFmdCBhbmQgYW0gZ2VuZXJhbGx5IGhhcHB5IHdpdGggaXQu ICBJIGRvIGhhdmUgYSBmZXcgcXVlc3Rpb25zOg0KDQoxLiAgV2hlbiBsb29raW5nIGF0IG1hcHBp bmcgc29tZXRoaW5nIGFzIGNvbW1vbiBhcyBhbiBJUEZpbHRlclJ1bGUgdG8gdGhpcyBzcGVjaWZp Y2F0aW9uLCBJIHVuZGVyc3RhbmQgd2h5IHRoZSBkaXJlY3Rpb24gdmFsdWUgaXMgbGVmdCBvdXQg YXMgaXQgaXMgb2J2aW91cyBhbmQgdGhlIHVzZSBvZiB0aGUgVHJhZmZpY1NlbGVjdG9yIG1ha2Vz IHRoZSBtYXBwaW5ncyBzdHJhaWdodCBmb3J3YXJkLCBpbW8uICBIb3dldmVyLCB0aGUgb3B0aW9u cyBwb3J0aW9uIG9mIHRoZSBJUEZpbHRlclJ1bGUgaXMgbGVmdCBvdXQgb2YgdGhpcyBjdXJyZW50 IHNwZWNmaWNhaXRvbi4gICBUaGlzIGNvdWxkIGJlIGFkZGVkIGFzIG90aGVyIGRhdGEgdG8gdGhl IHJ1bGUgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IGl0IGRvZXMgYWRkIGNvbXBsZXhpdHkg YW5kIG5lZWRzIHNvbWUgbGFuZ3VhZ2Ugb24gbWF0Y2hpbmcgYmV5b25kIGxvbmdlc3QgbWF0Y2gg Zm9yIHByaW9yaXR5LiAgIENvdWxkIHRoZSBhdXRob3JzIGhlbHAgbWUgdW5kZXJzdGFuZCB0aGlz IGRlc2lnbiBhbmQgaWYgc3VjaCBvcHRpb25zIHdpbGwgbm90IGJlIHN1cHBvcnRlZCBob3cgZG9l cyBhIGNhcnJpZXIgc3VwcG9ydCBhbiBJUEZpbHRlclJ1bGUgaW4gbW9iaWxpdHkgKG90aGVyIHRo YW4gbmV2ZXIgc3BlY2lmeWluZyBubyBvcHRpb25zIGluIGl0KT8gIENvdWxkIHNvbWUgc29ydCBv ZiBleHRlbnNpb24gYmUgYWRkZWQgdG8gdGhlIHJ1bGUgYmVjYXVzZSwgaW1vLCBpdCBkb2VzIG5v dCBiZWxvbmcgdG8gdGhlIHBvcnQgcHJvcGVydGllcyBidXQgSSBjYW4gYmUgd3JvbmcgaGVyZS4N Cg0KMi4gRHJvcHMgYXJlIGltcGxpY2l0IChzZW5kIHBhY2tldCB0byBhIHBvcnQgd2l0aCBubyBm b3J3YXJkaW5nIGNvbmZpZ3VyYXRpb24pIGJ1dCBhcyBhbiBvcGVyYXRpb25zIHBlcnNvbiB0cm91 Ymxlc2hvb3RpbmcgYSBzb2x1dGlvbiB1c2luZyBGUEMgaXMgdGhlcmUgc29tZXRoaW5nIHRoYXQg Y2FuIGJlIGRvbmUgaW4gdGhpcyBkb2N1bWVudCAoc3BlY2lmaWNhdGlvbiBPUiBub3RpbmcgaXQg YXMgYSB3YXJuaW5nKSB0byBtYWtlIGl0IG9idmlvdXMgdGhhdCBhIGRyb3AgY29uZmlndXJhdGlv biB3YXMgaW50ZW50aW9uYWwgdnMgYSBwb29yIGNsaWVudCBub3QgZm9sbG93aW5nIHRocm91Z2gg b3Igc29tZSBjb25uZWN0aW9uIGVycm9yIGNvbmRpdGlvbj8NCg0KMy4gIFRoaXMgaXMgYSBSRkMg NjA4OCBxdWVzdGlvbiBidXQgd2h5IHdvdWxkIHRoZXJlIGJlIGEgU1BJIHJhbmdlIGluIGEgdHJh ZmZpYyBzZWxlY3RvciBhbmQgaXMgdGhhdCBzb21ldGhpbmcgbmVjZXNzYXJ5IGluIEZQQz8NCg0K THlsZQ0KDQo= --_000_69756203DDDDE64E987BC4F70B71A26DA63B5B44PALLENEofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90 dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTHlsZSw8YnI+DQo8YnI+DQp0aGFua3MgZm9yIHlvdXIg cG9zaXRpb24gYW5kIGdvb2QgY29tbWVudHMgdG8gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUg ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0IG9mIGFsbCwgdGhlIGRy YWZ0IGlzIG5vdCBjb21wbGV0ZSBhbmQgZm9yIHN1cmUgbmVlZHMgZmVlZGJhY2sgb24gcmVxdWly ZWQ8YnI+DQpjb250cm9sLiBTbywgeW91ciBwcm9wb3NhbCBpcyBtb3JlIHRoYW4gd2VsY29tZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBjb21tZW50IGlzIHRoYXQgeW914oCZ cmUgbG9va2luZyBmb3IgY29udHJvbCBvbiBhIHJ1bGUsIHRoYXQ8YnI+DQpmaWx0ZXJzIHRyYWZm aWMuIFRoZSBjdXJyZW50IHNwZWMgY29tcHJpc2VzIHRyYWZmaWMgZGVzY3JpcHRvcnMsIGFuZCBw cm9wZXJ0aWVzLCB0aGF0PGJyPg0KYXBwbHkgdG8gdGhlIGRlc2NyaWJlZCB0cmFmZmljLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBjYW4gaW1hZ2luZSB0d28gdHlwZXMgb2YgZmlsdGVyczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+KDEpIE9uZSBpcyBhIGRlZmF1bHQgZmlsdGVyLCB3aGljaCBhcHBsaWVz IHRvIGFsbCB0cmFmZmljIHRoYXQgZG9lcyBub3QgbWF0Y2ggYW55IG9mPGJyPg0KdGhlIGRlc2Ny aXB0aW9ucy4gQW4gYXNzb2NpYXRlZCBwcm9wZXJ0eSBjYW4gYmUgZHJvcCwgb3IgZm9yd2FyZCB0 byBhIHBhcnRpY3VsYXI8YnI+DQpJUCBhZGRyZXNzIGFzIG5leHQgaG9wLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KDIp IEFub3RoZXIgaXMgdGhhdCB0cmFmZmljLCB0byB3aGljaCB0aGUgZmlsdGVyIGFwcGxpZXMsIGlz IGV4cGxpY2l0bHkgZGVzY3JpYmVkIHVzaW5nIHRoZTxicj4NCnRyYWZmaWMgZGVzY3JpcHRvcnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Cb3RoIHJlcXVpcmUgbWlub3IgZXh0ZW5zaW9ucyBvZiB0aGUgc3BlY+KAmXMg YXR0cmlidXRlcyBsaXN0LiBJdCB3b3VsZCByZXF1aXJlIGEgdHJhZmZpYyBkZXNjcmlwdG9yPGJy Pg0Kd2hpY2ggYXBwbGllcyB0byBhbGwgb3RoZXIgdHJhZmZpYyBmb3Igd2hpY2ggbm8gcHJvcGVy dGllcyBoYXZlIGJlZW4gY29uZmlndXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QWxzbywgYWRkaXRpb25hbCBwcm9wZXJ0aWVzIG1heSBiZSBuZWVkZWQgdG8gY29uZmlndXJlIHdo YXQgdG8gZG8gd2l0aCB0aGUgZmlsdGVyZWQgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1Y2ggZmlsdGVy aW5nIGNhbiBiZSBpbXBsaWNpdCBhbmQgZW5mb3JjZWQgYnkgRGF0YS1QbGFuZSBkZXZpY2UgbWFu YWdlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3I6IElmIHdlIHdhbnQgdGhl IENvbnRyb2wtUGxhbmUgdG8gZW5mb3JjZSBkeW5hbWljIGNvbmZpZ3VyYXRpb24gdG8gZmlsdGVy IHBhcnRpY3VsYXI8YnI+DQp0cmFmZmljIGFuZCBjb250cm9sIHdoYXQgdG8gZG8gd2l0aCB0aGUg ZmlsdGVyZWQgdHJhZmZpYywgdGhlbiB3ZSBjYW4gYWRkIHRoZSBhc3NvY2lhdGVkIGF0dHJpYnV0 ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIGhvcGUgdGhhdCBhZGRyZXNzZXMgeW91ciBjb21tZW50cyAxIGFuZCAy LiBBYm91dCBjb21tZW50IDM6IFdlIGFkZGVkIHRoZSB0cmFmZmljIHNlbGVjdG9yPGJyPg0KdG8g aGF2ZSBtZWFucyB0byBkZXNjcmliZSBJUCBkYXRhIHRyYWZmaWMgbW9yZSBhY2N1cmF0ZSwgbm90 IG9ubHkgcGVyIGFnZ3JlZ2F0ZWQgb3IgcGVyLWhvc3QgSVAgYWRkcmVzc2VzLjxicj4NClRoYXQg ZG9lcyBub3QgbWVhbiBhbGwgZmllbGRzIGluIHRoZSBUcmFmZmljIHNlbGVjdG9yLCBzdWNoIGFz IHRoZSBTUEksIG5lZWQgdG8gYmUgdXNlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHRoYXQgbWFrZXMgbWUg YWN0dWFsbHkgYXdhcmUgb2YgdGhlIG5lZWQgb2YgYWRkaXRpb25hbCB0cmFmZmljIGRlc2NyaXB0 b3JzLCB3aGljaCBpZGVudGlmeSB0cmFmZmljIG9uIGEgR1JFIGtleSBvciBhIEdUUCBURUlELjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGRvIHlvdSB0aGlu az88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyw8YnI+DQpNYXJjbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEx5bGUgQmVydHogW21haWx0bzps eWxlYjU1MTE0NEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9udGFnLCA1LiBPa3Rv YmVyIDIwMTUgMjA6MDU8YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtZG1tLWZwYy1jcGRwQGll dGYub3JnOyBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYt ZG1tLWZwYy1jcGRwLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdG9vayBhIGxvb2sgYXQgdGhlIGRyYWZ0IGFuZCBhbSBnZW5lcmFsbHkgaGFwcHkg d2l0aCBpdC4mbmJzcDsgSSBkbyBoYXZlIGEgZmV3IHF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4mbmJzcDsgV2hlbiBsb29r aW5nIGF0IG1hcHBpbmcgc29tZXRoaW5nIGFzIGNvbW1vbiBhcyBhbiBJUEZpbHRlclJ1bGUgdG8g dGhpcyBzcGVjaWZpY2F0aW9uLCBJIHVuZGVyc3RhbmQgd2h5IHRoZSBkaXJlY3Rpb24gdmFsdWUg aXMgbGVmdCBvdXQgYXMgaXQgaXMgb2J2aW91cyBhbmQgdGhlIHVzZSBvZiB0aGUgVHJhZmZpY1Nl bGVjdG9yIG1ha2VzIHRoZSBtYXBwaW5ncyBzdHJhaWdodCBmb3J3YXJkLCBpbW8uJm5ic3A7IEhv d2V2ZXIsDQogdGhlIG9wdGlvbnMgcG9ydGlvbiBvZiB0aGUgSVBGaWx0ZXJSdWxlIGlzIGxlZnQg b3V0IG9mIHRoaXMgY3VycmVudCBzcGVjZmljYWl0b24uICZuYnNwOyBUaGlzIGNvdWxkIGJlIGFk ZGVkIGFzIG90aGVyIGRhdGEgdG8gdGhlIHJ1bGUgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0 IGl0IGRvZXMgYWRkIGNvbXBsZXhpdHkgYW5kIG5lZWRzIHNvbWUgbGFuZ3VhZ2Ugb24gbWF0Y2hp bmcgYmV5b25kIGxvbmdlc3QgbWF0Y2ggZm9yIHByaW9yaXR5LiAmbmJzcDsgQ291bGQNCiB0aGUg YXV0aG9ycyBoZWxwIG1lIHVuZGVyc3RhbmQgdGhpcyBkZXNpZ24gYW5kIGlmIHN1Y2ggb3B0aW9u cyB3aWxsIG5vdCBiZSBzdXBwb3J0ZWQgaG93IGRvZXMgYSBjYXJyaWVyIHN1cHBvcnQgYW4gSVBG aWx0ZXJSdWxlIGluIG1vYmlsaXR5IChvdGhlciB0aGFuIG5ldmVyIHNwZWNpZnlpbmcgbm8gb3B0 aW9ucyBpbiBpdCk/Jm5ic3A7IENvdWxkIHNvbWUgc29ydCBvZiBleHRlbnNpb24gYmUgYWRkZWQg dG8gdGhlIHJ1bGUgYmVjYXVzZSwgaW1vLCBpdA0KIGRvZXMgbm90IGJlbG9uZyB0byB0aGUgcG9y dCBwcm9wZXJ0aWVzIGJ1dCBJIGNhbiBiZSB3cm9uZyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBEcm9wcyBhcmUgaW1wbGljaXQg KHNlbmQgcGFja2V0IHRvIGEgcG9ydCB3aXRoIG5vIGZvcndhcmRpbmcgY29uZmlndXJhdGlvbikg YnV0IGFzIGFuIG9wZXJhdGlvbnMgcGVyc29uIHRyb3VibGVzaG9vdGluZyBhIHNvbHV0aW9uIHVz aW5nIEZQQyBpcyB0aGVyZSBzb21ldGhpbmcgdGhhdCBjYW4gYmUgZG9uZSBpbiB0aGlzIGRvY3Vt ZW50IChzcGVjaWZpY2F0aW9uIE9SIG5vdGluZyBpdCBhcyBhIHdhcm5pbmcpDQogdG8gbWFrZSBp dCBvYnZpb3VzIHRoYXQgYSBkcm9wIGNvbmZpZ3VyYXRpb24gd2FzIGludGVudGlvbmFsIHZzIGEg cG9vciBjbGllbnQgbm90IGZvbGxvd2luZyB0aHJvdWdoIG9yIHNvbWUgY29ubmVjdGlvbiBlcnJv ciBjb25kaXRpb24/ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiZuYnNwOyBUaGlzIGlzIGEgUkZDIDYwODggcXVlc3Rp b24gYnV0IHdoeSB3b3VsZCB0aGVyZSBiZSBhIFNQSSByYW5nZSBpbiBhIHRyYWZmaWMgc2VsZWN0 b3IgYW5kIGlzIHRoYXQgc29tZXRoaW5nIG5lY2Vzc2FyeSBpbiBGUEM/ICZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MeWxl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_69756203DDDDE64E987BC4F70B71A26DA63B5B44PALLENEofficehd_-- From nobody Thu Oct 8 06:40: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 703DC1B33E2; Thu, 8 Oct 2015 06:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 gFBwk7-s1XVy; Thu, 8 Oct 2015 06:40:00 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115DD1B33CF; Thu, 8 Oct 2015 06:40:00 -0700 (PDT) Received: by vkgd64 with SMTP id d64so32093721vkg.0; Thu, 08 Oct 2015 06:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YPfx1HxfySqz1eGSeWswjyIbhYdkt+LNb6mTbTufOh4=; b=MdMfoORSxEo/zhU7NYnExid2VNbmkTHmtEQdIQutC0KInPTMdY7jkgu334AE2sENUf Zqnt0nZb9ZqJvU8eHBito9/jAkh/CkXGEBeJ/wLMoZciZoUu1zPqrWXtPGTvu2wqMPx9 5p0xl4eTglV4Vds76rQeZQ4WXYjM45ihI5tYS4EvduNUxyquV4aAVhJujb0eGRSpC8a5 VBm803YLf5aTnMePANiFOaJ9iQ9LU/VkP94x/nrlWiaYIxIyfYVKF0D3L0vv/KaQQixQ 8ADz5DygBCnOQIDLSR4bB5oWdU3ch9cuIgYfwWbD5UklBq92B3akQMNmYYfoucUkjpE6 9a/Q== MIME-Version: 1.0 X-Received: by 10.31.165.132 with SMTP id o126mr5115845vke.101.1444311599176; Thu, 08 Oct 2015 06:39:59 -0700 (PDT) Received: by 10.31.49.134 with HTTP; Thu, 8 Oct 2015 06:39:59 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DA63B5B44@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26DA63B5B44@PALLENE.office.hd> Date: Thu, 8 Oct 2015 08:39:59 -0500 Message-ID: From: Lyle Bertz To: Marco Liebsch Content-Type: multipart/alternative; boundary=001a114162c2d06618052197ff31 Archived-At: Cc: "draft-ietf-dmm-fpc-cpdp@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] draft-ietf-dmm-fpc-cpdp-01 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, 08 Oct 2015 13:40:02 -0000 --001a114162c2d06618052197ff31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marco, Thanks for the response. In general, I agree with you that the properties is most likely the way to go. It would be interesting if it is of any value to add properties per rule. I would note you already have port properties supporting tunnels so I am not sure that adding this information as part of the traffic selector is ideal. In general, a port level property is perfect for common property construction and should remain in the specification. This now becomes a matter of construction. Does the community believe that there will be enough single (narrow) traffic selectors with properties that we will unintentionally create multiple ports? If so, the properties attached to the rule may be of value. My number one concern is the second e-mail on copying and tunneling packets. For operators this is a priority given their obligations. As for the rest of the properties, a small group is doing a gap analysis of Diameter =3D> 3GPP (Gx,Gxx,Sd), 3GPP =3D> FPC and then FPC =3D> SDN functio= ns (specifically Openflow versions 1.4.x and 1.5x). The general trend observed so far is that we have a lot in Diameter (such as the options in the IPFilterRule), lose it in Gx (which precludes options in their extended AVPs of IPFilterRule for key use cases), then would map to FPC and then to OpenFlow. Ironically, OpenFlow *can* support the options (OXM has much of this) but we lose it 3GPP. I will see if we can release the information as it is critical to deciding if we actually need this stuff or are fine with current state. As for the SPI Range my question is one of pure curiosity at this point, when do I need a SPI range? I am not married to any solution here but we also need to think about how FPC is extended in terms of properties in both a registry manner and experimental properties/rules. Thank you, again, for the response. Lyle On Thu, Oct 8, 2015 at 8:00 AM, Marco Liebsch wrote: > Hi Lyle, > > thanks for your position and good comments to the current version of the > draft. > > First of all, the draft is not complete and for sure needs feedback on > required > control. So, your proposal is more than welcome. > > > > My understanding of your comment is that you=E2=80=99re looking for contr= ol on a > rule, that > filters traffic. The current spec comprises traffic descriptors, and > properties, that > apply to the described traffic. > > > > I can imagine two types of filters: > > (1) One is a default filter, which applies to all traffic that does not > match any of > the descriptions. An associated property can be drop, or forward to a > particular > IP address as next hop. > > > > (2) Another is that traffic, to which the filter applies, is explicitly > described using the > traffic descriptors. > > > > Both require minor extensions of the spec=E2=80=99s attributes list. It w= ould > require a traffic descriptor > which applies to all other traffic for which no properties have been > configured. > > Also, additional properties may be needed to configure what to do with th= e > filtered traffic. > > > > Such filtering can be implicit and enforced by Data-Plane device > management. > > Or: If we want the Control-Plane to enforce dynamic configuration to > filter particular > traffic and control what to do with the filtered traffic, then we can add > the associated attributes. > > > > I hope that addresses your comments 1 and 2. About comment 3: We added th= e > traffic selector > to have means to describe IP data traffic more accurate, not only per > aggregated or per-host IP addresses. > That does not mean all fields in the Traffic selector, such as the SPI, > need to be used. > > > > But that makes me actually aware of the need of additional traffic > descriptors, which identify traffic on a GRE key or a GTP TEID. > > What do you think? > > > > Thanks, > Marco > > > > > > > > *From:* Lyle Bertz [mailto:lyleb551144@gmail.com] > *Sent:* Montag, 5. Oktober 2015 20:05 > *To:* draft-ietf-dmm-fpc-cpdp@ietf.org; dmm@ietf.org > *Subject:* RE: draft-ietf-dmm-fpc-cpdp-01 > > > > All, > > > > I took a look at the draft and am generally happy with it. I do have a > few questions: > > > > 1. When looking at mapping something as common as an IPFilterRule to thi= s > specification, I understand why the direction value is left out as it is > obvious and the use of the TrafficSelector makes the mappings straight > forward, imo. However, the options portion of the IPFilterRule is left o= ut > of this current specficaiton. This could be added as other data to the > rule with the understanding that it does add complexity and needs some > language on matching beyond longest match for priority. Could the autho= rs > help me understand this design and if such options will not be supported > how does a carrier support an IPFilterRule in mobility (other than never > specifying no options in it)? Could some sort of extension be added to t= he > rule because, imo, it does not belong to the port properties but I can be > wrong here. > > > > 2. Drops are implicit (send packet to a port with no forwarding > configuration) but as an operations person troubleshooting a solution usi= ng > FPC is there something that can be done in this document (specification O= R > noting it as a warning) to make it obvious that a drop configuration was > intentional vs a poor client not following through or some connection err= or > condition? > > > > 3. This is a RFC 6088 question but why would there be a SPI range in a > traffic selector and is that something necessary in FPC? > > > > Lyle > > > --001a114162c2d06618052197ff31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Marco,

Thanks for the response.

In general, I agree with you that the properties is most = likely the way to go. It would be interesting if it is of any value to add = properties per rule. =C2=A0 I would note you already have port properties s= upporting tunnels so I am not sure that adding this information as part of = the traffic selector is ideal.

In general, a port = level property is perfect for common property construction and should remai= n in the specification.=C2=A0 This now becomes a matter of construction.=C2= =A0 Does the community believe that there will be enough single (narrow) tr= affic selectors with properties that we will unintentionally create multipl= e ports?=C2=A0 If so, the properties attached to the rule may be of value.<= /div>

My number one concern is the second e-mail on copy= ing and tunneling packets.=C2=A0 For operators this is a priority given the= ir obligations. =C2=A0

As for the rest of the prop= erties, a small group is doing a gap analysis of Diameter =3D> 3GPP (Gx,= Gxx,Sd), 3GPP =3D> FPC and then FPC =3D> SDN functions (specifically = Openflow versions 1.4.x and 1.5x). =C2=A0 The general trend observed so far= is that we have a lot in Diameter (such as the options in the IPFilterRule= ), lose it in Gx (which precludes options in their extended AVPs of IPFilte= rRule for key use cases), then would map to FPC and then to OpenFlow.=C2=A0= Ironically, OpenFlow *can* support the options (OXM has much of this) but = we lose it 3GPP.=C2=A0 I will see if we can release the information as it i= s critical to deciding if we actually need this stuff or are fine with curr= ent state.

As for the SPI Range my question is one= of pure curiosity at this point, when do I need a SPI range?
I am not married to any solution here but we also need to think= about how FPC is extended in terms of properties in both a registry manner= and experimental properties/rules.=C2=A0

Thank yo= u, again, for the response.

Lyle




On Thu, Oct 8, 2015 at 8:00 AM, Marco Liebsch <Marco.Liebsch@neclab.eu> wrote:

Hi Lyle,

thanks for your position and good comments to the current version of the dr= aft.

First of all, the draft i= s not complete and for sure needs feedback on required
control. So, your proposal is more than welcome.

=C2=A0

My understanding of your = comment is that you=E2=80=99re looking for control on a rule, that
filters traffic. The current spec comprises traffic descriptors, and proper= ties, that
apply to the described traffic.

=C2=A0

I can imagine two types o= f filters:

(1) One is a default filt= er, which applies to all traffic that does not match any of
the descriptions. An associated property can be drop, or forward to a parti= cular
IP address as next hop.

=C2=A0

(2) Another is that traff= ic, to which the filter applies, is explicitly described using the
traffic descriptors.

=C2=A0

Both require minor extens= ions of the spec=E2=80=99s attributes list. It would require a traffic desc= riptor
which applies to all other traffic for which no properties have been config= ured.

Also, additional properti= es may be needed to configure what to do with the filtered traffic.<= u>

=C2=A0

Such filtering can be imp= licit and enforced by Data-Plane device management.

Or: If we want the Contro= l-Plane to enforce dynamic configuration to filter particular
traffic and control what to do with the filtered traffic, then we can add t= he associated attributes.

=C2=A0

I hope that addresses you= r comments 1 and 2. About comment 3: We added the traffic selector
to have means to describe IP data traffic more accurate, not only per aggre= gated or per-host IP addresses.
That does not mean all fields in the Traffic selector, such as the SPI, nee= d to be used.

=C2=A0

But that makes me actuall= y aware of the need of additional traffic descriptors, which identify traff= ic on a GRE key or a GTP TEID.

What do you think?=

=C2=A0

Thanks,
Marco

=C2=A0

=C2=A0

=C2=A0

From: Lyle Ber= tz [mailto:lyleb= 551144@gmail.com]
Sent: Montag, 5. Oktober 2015 20:05
To: draft-ietf-dmm-fpc-cpdp@ietf.org; dmm@ietf.org
Subject: RE: draft-ietf-dmm-fpc-cpdp-01

=C2=A0

All,

=C2=A0

I took a look at the draft and am generally happy wi= th it.=C2=A0 I do have a few questions:

=C2=A0

1.=C2=A0 When looking at mapping something as common= as an IPFilterRule to this specification, I understand why the direction v= alue is left out as it is obvious and the use of the TrafficSelector makes = the mappings straight forward, imo.=C2=A0 However, the options portion of the IPFilterRule is left out of this current specfi= caiton. =C2=A0 This could be added as other data to the rule with the under= standing that it does add complexity and needs some language on matching be= yond longest match for priority. =C2=A0 Could the authors help me understand this design and if such options will not be= supported how does a carrier support an IPFilterRule in mobility (other th= an never specifying no options in it)?=C2=A0 Could some sort of extension b= e added to the rule because, imo, it does not belong to the port properties but I can be wrong here.<= /u>

=C2=A0

2. Drops are implicit (send packet to a port with no= forwarding configuration) but as an operations person troubleshooting a so= lution using FPC is there something that can be done in this document (spec= ification OR noting it as a warning) to make it obvious that a drop configuration was intentional vs a poor cli= ent not following through or some connection error condition? =C2=A0=C2=A0<= u>

=C2=A0

3.=C2=A0 This is a RFC 6088 question but why would t= here be a SPI range in a traffic selector and is that something necessary i= n FPC? =C2=A0=C2=A0

=C2=A0

Lyle

=C2=A0


--001a114162c2d06618052197ff31-- From nobody Thu Oct 8 07:00:55 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 9284D1A005B; Thu, 8 Oct 2015 07:00:53 -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 3d7hFZ07e6p5; Thu, 8 Oct 2015 07:00:51 -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 D26BC1A0052; Thu, 8 Oct 2015 07:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A859D10AB99; Thu, 8 Oct 2015 16:00:49 +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 QFQuTt2DNxvM; Thu, 8 Oct 2015 16:00:49 +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 8781710AB9A; Thu, 8 Oct 2015 16:00:43 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.86]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Thu, 8 Oct 2015 16:00:22 +0200 From: Marco Liebsch To: Lyle Bertz , "draft-ietf-dmm-fpc-cpdp@ietf.org" , "dmm@ietf.org" Thread-Topic: Copying Traffic in FPC Thread-Index: AQHRAE0ATH8jTtwBZ0i7dUzo4kpeKZ5hnGbg Date: Thu, 8 Oct 2015 14:00:21 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DA63B5C53@PALLENE.office.hd> References: In-Reply-To: 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_69756203DDDDE64E987BC4F70B71A26DA63B5C53PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Copying Traffic in FPC 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, 08 Oct 2015 14:00:53 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DA63B5C53PALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IHRoaW5rIGFib3V0IHNvbWV0aGluZyBsaWtlIGZsb3cgc2FtcGxpbmcsIGNvcnJlY3Q/IEZy b20gRlBDIHByb3RvY29sIHBvaW50IG9mIHZpZXcsIEkgZG9u4oCZdCBzZWUNCmlzc3VlcyB3aXRo IGFkZGluZyBzdWNoIHByb3BlcnRpZXMuIEFGQUlLIHRoZXJlIGlzIGV2ZW4gc29tZSBzdXBwb3J0 IGZyb20gZGF0YSBwbGFuZSBub2Rlcywgc28NCmVuZm9yY2VtZW50IG9mIHRoZXNlIHByb3BlcnRp ZXMgc2hvdWxkIHdvcmsuDQoNCk5vdywgSSB1bmRlcnN0YW5kIHlvdeKAmXJlIHJlcXVlc3Rpbmcg Y29udHJvbCBvbiB3aGljaCB0cmFmZmljIHNob3VsZCBiZSBwcm9iZWQuIEluIHRoYXQgY2FzZSBh DQpuZXcgcHJvcGVydHkgc2hvdWxkIGJlIGFkZGVkLiBUaGUgYXNzb2NpYXRlZCBhdHRyaWJ1dGUg c2hvdWxkIHRoZW4gYWxzbyBpbmRpY2F0ZSBob3cgb2Z0ZW4NCnBhY2tldHMgc2hvdWxkIGJlIHBy b2JlZCAoRXZlcnkgMW1pbiwgZXZlciAxMDAwdGggcGFja2V0LCB3aGF0ZXZlcikuDQpTaW5jZSB0 aGUgZm9yd2FyZGluZyBvZiB0aGUgY29weSBwYWNrZXQgaXMgZGlmZmVyZW50IHRoYW4gZm9yIHRo ZSBhY3R1YWwgZGF0YSBwYWNrZXQsIHRoZQ0KcHJvYmUgcHJvcGVydHkgc2hvdWxkIGFsc28gaW5k aWNhdGUgYSBkZXN0aW5hdGlvbiwgd2hlcmUgdGhlIGNvcHkgc2hvdWxkIGJlIHNlbnQgdG8uDQpU aGF04oCZcyB0aGUgcHJvdG9jb2wgcGFydCBhbmQgaXQgc2hvdWxkIGJlIGZlYXNpYmxlIGlmIHdh bnRlZC4NCg0KSXMgaXQgdGhlIEMtUGxhbmUgZnVuY3Rpb24gdGhhdCBpcyBhd2FyZSBvZiBwb2xp Y2llcyBmb3IgcGFja2V0IHByb2Jlcz8gVG8gZXhwbG9pdCBzdWNoIGV4dGVuc2lvbiwNCml0IHNo b3VsZCBiZSwgb3RoZXJ3aXNlIHRoZSBwcm9iZSBjb25maWd1cmF0aW9uIG1heSBiZSBhY2NvbXBs aXNoZWQgdmlhIGEgZGlmZmVyZW50IGludGVyZmFjZS4NCg0KVGhhbmtzLA0KTWFyY28NCg0KDQoN CkZyb206IEx5bGUgQmVydHogW21haWx0bzpseWxlYjU1MTE0NEBnbWFpbC5jb21dDQpTZW50OiBE aWVuc3RhZywgNi4gT2t0b2JlciAyMDE1IDE3OjM4DQpUbzogZHJhZnQtaWV0Zi1kbW0tZnBjLWNw ZHBAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZw0KU3ViamVjdDogQ29weWluZyBUcmFmZmljIGluIEZQ Qw0KDQpXaGVuIGxvb2tpbmcgYXQgdGhlIGxhdGVzdCBkcmFmdCBJIHdhcyBjdXJpb3VzIGFib3V0 IGhvdyBjb3B5aW5nIGZvciB0aGUgcHVycG9zZSBvZiB0cm91Ymxlc2hvb3RpbmcgLyBwcm9iZXMg d291bGQgYmUgc3VwcG9ydGVkPw0KDQpNeSB0aG91Z2h0IHdvdWxkIGJlIHNvbWUgc29ydCBvZiBw cm9wZXJ0eSBvbiBhIHBvcnQgdGhhdCBjb3BpZXMgdGhlIHRyYWZmaWMgYW5kIG5vdGVzIHRoZSBQ UlQgdGhhdCBpdCBjb3VsZCBiZSBmb3J3YXJkZWQgdG8uDQoNCkNvdWxkIHdlIHN1cHBvcnQgdGhp cyB1c2UgY2FzZSAoSSBhbSBub3QgbWFycmllZCB0byB0aGUgc3VnZ2VzdGlvbiBhYm92ZSkgaW4g dGhlIHNwZWNpZmljYXRpb24gZ2l2ZW4gaXRzIGltcG9ydGFuY2UgdG8gdHJvdWJsZSBtYW5hZ2Vt ZW50PyAgIFRoaXMgaXMgZWFzeSBlbm91Z2ggdG8gc3VwcG9ydCBpbiB1bmRlcmx5aW5nIERQTiB0 ZWNobm9sb2dpZXMgc3VjaCBhcyBTRE4gYW5kIEkgc2VlIG5vIHJlYXNvbiB0byBub3Qgc3BlY2lm eSBpdCBpbiBGUEMgYW5kIGF2b2lkIHVzaW5nIHlldCBhbm90aGVyIHByb3RvY29sIGZvciBmb3J3 YXJkaW5nLg0KDQpDb21tZW50cyAvIFRob3VnaHRzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIG9uIHRo aXMgbWF0dGVyLg0KDQpUaGFuayB5b3UuDQoNCkx5bGUNCg== --_000_69756203DDDDE64E987BC4F70B71A26DA63B5C53PALLENEofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSB0aGlu ayBhYm91dCBzb21ldGhpbmcgbGlrZSBmbG93IHNhbXBsaW5nLCBjb3JyZWN0PyBGcm9tIEZQQyBw cm90b2NvbCBwb2ludCBvZiB2aWV3LCBJIGRvbuKAmXQgc2VlPGJyPg0KaXNzdWVzIHdpdGggYWRk aW5nIHN1Y2ggcHJvcGVydGllcy4gQUZBSUsgdGhlcmUgaXMgZXZlbiBzb21lIHN1cHBvcnQgZnJv bSBkYXRhIHBsYW5lIG5vZGVzLCBzbzxicj4NCmVuZm9yY2VtZW50IG9mIHRoZXNlIHByb3BlcnRp ZXMgc2hvdWxkIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3csIEkgdW5kZXJzdGFuZCB5b3XigJlyZSByZXF1 ZXN0aW5nIGNvbnRyb2wgb24gd2hpY2ggdHJhZmZpYyBzaG91bGQgYmUgcHJvYmVkLiBJbiB0aGF0 IGNhc2UgYTxicj4NCm5ldyBwcm9wZXJ0eSBzaG91bGQgYmUgYWRkZWQuIFRoZSBhc3NvY2lhdGVk IGF0dHJpYnV0ZSBzaG91bGQgdGhlbiBhbHNvIGluZGljYXRlIGhvdyBvZnRlbjxicj4NCnBhY2tl dHMgc2hvdWxkIGJlIHByb2JlZCAoRXZlcnkgMW1pbiwgZXZlciAxMDAwPHN1cD50aDwvc3VwPiBw YWNrZXQsIHdoYXRldmVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2luY2UgdGhl IGZvcndhcmRpbmcgb2YgdGhlIGNvcHkgcGFja2V0IGlzIGRpZmZlcmVudCB0aGFuIGZvciB0aGUg YWN0dWFsIGRhdGEgcGFja2V0LCB0aGU8YnI+DQpwcm9iZSBwcm9wZXJ0eSBzaG91bGQgYWxzbyBp bmRpY2F0ZSBhIGRlc3RpbmF0aW9uLCB3aGVyZSB0aGUgY29weSBzaG91bGQgYmUgc2VudCB0by48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgdGhlIHByb3RvY29sIHBhcnQg YW5kIGl0IHNob3VsZCBiZSBmZWFzaWJsZSBpZiB3YW50ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JcyBpdCB0aGUg Qy1QbGFuZSBmdW5jdGlvbiB0aGF0IGlzIGF3YXJlIG9mIHBvbGljaWVzIGZvciBwYWNrZXQgcHJv YmVzPyBUbyBleHBsb2l0IHN1Y2ggZXh0ZW5zaW9uLDxicj4NCml0IHNob3VsZCBiZSwgb3RoZXJ3 aXNlIHRoZSBwcm9iZSBjb25maWd1cmF0aW9uIG1heSBiZSBhY2NvbXBsaXNoZWQgdmlhIGEgZGlm ZmVyZW50IGludGVyZmFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TWFyY288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBMeWxlIEJlcnR6IFttYWlsdG86bHlsZWI1NTExNDRAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IERpZW5zdGFnLCA2LiBPa3RvYmVyIDIwMTUgMTc6Mzg8 YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtZG1tLWZwYy1jcGRwQGlldGYub3JnOyBkbW1AaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gQ29weWluZyBUcmFmZmljIGluIEZQQzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIGxvb2tp bmcgYXQgdGhlIGxhdGVzdCBkcmFmdCBJIHdhcyBjdXJpb3VzIGFib3V0IGhvdyBjb3B5aW5nIGZv ciB0aGUgcHVycG9zZSBvZiB0cm91Ymxlc2hvb3RpbmcgLyBwcm9iZXMgd291bGQgYmUgc3VwcG9y dGVkPyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk15IHRob3VnaHQgd291bGQgYmUgc29tZSBzb3J0IG9mIHByb3BlcnR5IG9uIGEgcG9y dCB0aGF0IGNvcGllcyB0aGUgdHJhZmZpYyBhbmQgbm90ZXMgdGhlIFBSVCB0aGF0IGl0IGNvdWxk IGJlIGZvcndhcmRlZCB0by4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHdlIHN1cHBvcnQgdGhpcyB1c2UgY2Fz ZSAoSSBhbSBub3QgbWFycmllZCB0byB0aGUgc3VnZ2VzdGlvbiBhYm92ZSkgaW4gdGhlIHNwZWNp ZmljYXRpb24gZ2l2ZW4gaXRzIGltcG9ydGFuY2UgdG8gdHJvdWJsZSBtYW5hZ2VtZW50PyAmbmJz cDsgVGhpcyBpcyBlYXN5IGVub3VnaCB0byBzdXBwb3J0IGluIHVuZGVybHlpbmcgRFBOIHRlY2hu b2xvZ2llcyBzdWNoIGFzIFNETiBhbmQgSSBzZWUgbm8gcmVhc29uIHRvDQogbm90IHNwZWNpZnkg aXQgaW4gRlBDIGFuZCBhdm9pZCB1c2luZyB5ZXQgYW5vdGhlciBwcm90b2NvbCBmb3IgZm9yd2Fy ZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q29tbWVudHMgLyBUaG91Z2h0cyB3b3VsZCBiZSBhcHByZWNpYXRlZCBvbiB0aGlzIG1hdHRl ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KTHlsZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_69756203DDDDE64E987BC4F70B71A26DA63B5C53PALLENEofficehd_-- From nobody Thu Oct 8 08:02: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 8119D1A21BA; Thu, 8 Oct 2015 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 B4gjFKvagdIr; Thu, 8 Oct 2015 08:02:30 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CF31A6F59; Thu, 8 Oct 2015 08:02:28 -0700 (PDT) Received: by vkao3 with SMTP id o3so33609915vka.2; Thu, 08 Oct 2015 08:02: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=HsY3Cs4bD5xUROAr9SV84M6lOeNC0v85UKYEstn8azQ=; b=QSpReaJtUcvzGYFr2I4/7WJWnGqxV5ADchlQHRjlRWIW2pvDMjw3nx1G9pMg1Q/piK yt8DFoiAA2OHBLS5H8O57H04qbyww/NNzN9cUxmPnE1Vn0zUCc9eBRhHXoUYT7okx743 x0LEoG5OdajSI1rS1ma/YhWaqXS2MJIblWKfr8DWTA/scVatvj/NkoInTk3GqvPJi+HM CoRb8UgtjHrj2aEAr1+vyOSSSRhuG2x3FCiG3NAkV7stQ3WyiPt7crZsT6V+PdKf8PuO mSEExgAuvLKe8+YXsCynsw+XoLDG0bOkiNGP8KMrXV5xBLh0qjZje/nYpvaPA++PSfdU 77bg== MIME-Version: 1.0 X-Received: by 10.31.130.208 with SMTP id e199mr5381827vkd.78.1444316548000; Thu, 08 Oct 2015 08:02:28 -0700 (PDT) Received: by 10.31.49.134 with HTTP; Thu, 8 Oct 2015 08:02:27 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DA63B5C53@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26DA63B5C53@PALLENE.office.hd> Date: Thu, 8 Oct 2015 10:02:27 -0500 Message-ID: From: Lyle Bertz To: Marco Liebsch Content-Type: multipart/alternative; boundary=001a11466d14c976590521992669 Archived-At: Cc: "draft-ietf-dmm-fpc-cpdp@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Copying Traffic in FPC 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, 08 Oct 2015 15:02:32 -0000 --001a11466d14c976590521992669 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marco, wrt > You think about something like flow sampling, correct? Yes, I am thinking about sampling or trouble management (engineer working directly with a customer to fix 'something' or sampling based upon other OSS data that indicates issues in the area), in such cases a. The customer (and engineer) will not know anything about mobility information so this is initiated through the control plane, e.g. the customer can tell us the phone # of a mobile and we can initiate the trace through the control plane. b. In general sampling is good enough but for direct troubleshooting with a knowledgeable customer we would analyze a direct copy of the traffic (taking all packets) so view the range as sample from whatever the probe / sampling rate should be > Is it the C-Plane function that is aware of policies for packet probes? As I mention above, no one knows their current address - especially when IP mobility is involved. The C-plane can correlate other mobility network Identifiers to an IP address and then send a command. If fully automated, the C-plane can do targeted diagnostics for offload and, because it is the C-plane by sending commands to move users or take other actions - it is, after all the C-plane. < This could be a future possibility - I am not proposing re-homing and AF mobility is a different matter entirely we are addressing in other work in the group Thanks. Lyle On Thu, Oct 8, 2015 at 9:00 AM, Marco Liebsch wrote: > You think about something like flow sampling, correct? From FPC protocol > point of view, I don=E2=80=99t see > issues with adding such properties. AFAIK there is even some support from > data plane nodes, so > enforcement of these properties should work. > > > > Now, I understand you=E2=80=99re requesting control on which traffic shou= ld be > probed. In that case a > new property should be added. The associated attribute should then also > indicate how often > packets should be probed (Every 1min, ever 1000th packet, whatever). > > Since the forwarding of the copy packet is different than for the actual > data packet, the > probe property should also indicate a destination, where the copy should > be sent to. > > That=E2=80=99s the protocol part and it should be feasible if wanted. > > > > Is it the C-Plane function that is aware of policies for packet probes? T= o > exploit such extension, > it should be, otherwise the probe configuration may be accomplished via a > different interface. > > > > Thanks, > > Marco > > > > > > > > *From:* Lyle Bertz [mailto:lyleb551144@gmail.com] > *Sent:* Dienstag, 6. Oktober 2015 17:38 > *To:* draft-ietf-dmm-fpc-cpdp@ietf.org; dmm@ietf.org > *Subject:* Copying Traffic in FPC > > > > When looking at the latest draft I was curious about how copying for the > purpose of troubleshooting / probes would be supported? > > > > My thought would be some sort of property on a port that copies the > traffic and notes the PRT that it could be forwarded to. > > > > Could we support this use case (I am not married to the suggestion above) > in the specification given its importance to trouble management? This i= s > easy enough to support in underlying DPN technologies such as SDN and I s= ee > no reason to not specify it in FPC and avoid using yet another protocol f= or > forwarding. > > > > Comments / Thoughts would be appreciated on this matter. > > > > Thank you. > > > Lyle > --001a11466d14c976590521992669 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Marco,

wrt
> = You think about something like flow sampling, correct?

Yes, I am thinking about sampling or trouble management (en= gineer working directly with a customer to fix 'something' or sampl= ing based upon other OSS data that indicates issues in the area), in such c= ases=C2=A0
a.=C2=A0 The customer (and engineer) will not know any= thing about mobility information so this is initiated through the control p= lane, e.g. the customer can tell us the phone # of a mobile and we can init= iate the trace through the control plane.
b.=C2=A0 In general sam= pling is good enough but for direct troubleshooting with a knowledgeable cu= stomer we would analyze a direct copy of the traffic (taking all packets) s= o view the range as sample from whatever the probe / sampling rate should b= e

>=C2=A0Is it the C-Plane functio= n that is aware of policies for packet probes?
As I mention above, no one knows their current address - especially when= IP mobility is involved. =C2=A0 =C2=A0The C-plane can correlate other mobi= lity network Identifiers to an IP address and then send a command. =C2=A0

If fully automated, the C-plane can d= o targeted diagnostics for offload and, because it is the C-plane by sendin= g commands to move users or take other actions - it is, after all the C-pla= ne. =C2=A0 < This could be a future possibility - I am not proposing re-= homing and AF mobility is a different matter entirely we are addressing in = other work in the group

Thanks.

Lyle


On Thu, Oct 8, 2015 at 9:00 AM, Marco Liebsch <M= arco.Liebsch@neclab.eu> wrote:

You think about something like flow sampling= , correct? From FPC protocol point of view, I don=E2=80=99t see
issues with adding such properties. AFAIK there is even some support from d= ata plane nodes, so
enforcement of these properties should work.

=C2=A0

Now, I understand you=E2=80=99re requesting = control on which traffic should be probed. In that case a
new property should be added. The associated attribute should then also ind= icate how often
packets should be probed (Every 1min, ever 1000th packet, whatev= er).

Since the forwarding of the copy packet is d= ifferent than for the actual data packet, the
probe property should also indicate a destination, where the copy should be= sent to.

That=E2=80=99s the protocol part and it shou= ld be feasible if wanted.

=C2=A0

Is it the C-Plane function that is aware of = policies for packet probes? To exploit such extension,
it should be, otherwise the probe configuration may be accomplished via a d= ifferent interface.

=C2=A0

Thanks,

Marco

=C2=A0

=C2=A0

=C2=A0

From: Lyle Bertz [mailto:lyleb551144@gmail.com]
Sent: Dienstag, 6. Oktober 2015 17:38
To: draft-ietf-dmm-fpc-cpdp@ietf.org; dmm@ietf.org
Subject: Copying Traffic in FPC

=C2=A0

When looking at the latest draft I was curious about= how copying for the purpose of troubleshooting / probes would be supported= ? =C2=A0=C2=A0

=C2=A0

My thought would be some sort of property on a port = that copies the traffic and notes the PRT that it could be forwarded to. = =C2=A0=C2=A0

=C2=A0

Could we support this use case (I am not married to = the suggestion above) in the specification given its importance to trouble = management? =C2=A0 This is easy enough to support in underlying DPN technol= ogies such as SDN and I see no reason to not specify it in FPC and avoid using yet another protocol for forwarding.=

=C2=A0

Comments / Thoughts would be appreciated on this mat= ter.

=C2=A0

Thank you.


Lyle=C2=A0


--001a11466d14c976590521992669-- From nobody Thu Oct 8 08:32:06 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 1027A1A879A; Thu, 8 Oct 2015 08:32:05 -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 PlBvs1OTkMtE; Thu, 8 Oct 2015 08:32: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 AED3A1A9045; Thu, 8 Oct 2015 08:32:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 33ABF10AB9F; Thu, 8 Oct 2015 17:32:00 +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 gcDjOFlwPtVS; Thu, 8 Oct 2015 17:32:00 +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 0D93010AB4D; Thu, 8 Oct 2015 17:31:54 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.86]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 8 Oct 2015 17:31:53 +0200 From: Marco Liebsch To: Lyle Bertz Thread-Topic: Copying Traffic in FPC Thread-Index: AQHRAE0ATH8jTtwBZ0i7dUzo4kpeKZ5hnGbg///2KYCAAChSYA== Date: Thu, 8 Oct 2015 15:31:53 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DA63B5D6C@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26DA63B5C53@PALLENE.office.hd> In-Reply-To: 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_69756203DDDDE64E987BC4F70B71A26DA63B5D6CPALLENEofficehd_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dmm-fpc-cpdp@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Copying Traffic in FPC 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, 08 Oct 2015 15:32:05 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DA63B5D6CPALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIHVuZGVyc3RhbmQuIEl04oCZcyBub3QgZm9yIGNhc2VzIGxpa2UgY2hhcmdpbmcvbW9uaXRv cmluZyBiYXNlZCBvbiBzYW1wbGVzLCBidXQgeW91IHBsYW4gdXNpbmcgaXQNCm9uL29mZiB1bmRl ciBjb250cm9sIG9mIHRoZSBDLVBsYW5lIGFuZCBvbmx5IG9uIGRlbWFuZCBhbmQgb25seSBmb3Ig c2VsZWN0ZWQgdHJhZmZpYy4NCg0KU28gaWYgd2UgYXNzdW1lIHRoaXMgZW5mb3JjZW1lbnQgZ29l cyB2aWEgdGhlIG1vYmlsaXR5IEMtUGxhbmUgZnVuY3Rpb24sIGl0IGNvdWxkIGJlIGEgZmVhdHVy ZSB0aGF0DQpjYW4gYmUgYWRkZWQuDQoNCk90aGVyc+KAmSBvcGluaW9uIG9uIHRoaXM/DQoNCm1h cmNvDQoNCkZyb206IEx5bGUgQmVydHogW21haWx0bzpseWxlYjU1MTE0NEBnbWFpbC5jb21dDQpT ZW50OiBEb25uZXJzdGFnLCA4LiBPa3RvYmVyIDIwMTUgMTc6MDINClRvOiBNYXJjbyBMaWVic2No DQpDYzogZHJhZnQtaWV0Zi1kbW0tZnBjLWNwZHBAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IENvcHlpbmcgVHJhZmZpYyBpbiBGUEMNCg0KTWFyY28sDQoNCndydA0KPiBZb3Ug dGhpbmsgYWJvdXQgc29tZXRoaW5nIGxpa2UgZmxvdyBzYW1wbGluZywgY29ycmVjdD8NCg0KWWVz LCBJIGFtIHRoaW5raW5nIGFib3V0IHNhbXBsaW5nIG9yIHRyb3VibGUgbWFuYWdlbWVudCAoZW5n aW5lZXIgd29ya2luZyBkaXJlY3RseSB3aXRoIGEgY3VzdG9tZXIgdG8gZml4ICdzb21ldGhpbmcn IG9yIHNhbXBsaW5nIGJhc2VkIHVwb24gb3RoZXIgT1NTIGRhdGEgdGhhdCBpbmRpY2F0ZXMgaXNz dWVzIGluIHRoZSBhcmVhKSwgaW4gc3VjaCBjYXNlcw0KYS4gIFRoZSBjdXN0b21lciAoYW5kIGVu Z2luZWVyKSB3aWxsIG5vdCBrbm93IGFueXRoaW5nIGFib3V0IG1vYmlsaXR5IGluZm9ybWF0aW9u IHNvIHRoaXMgaXMgaW5pdGlhdGVkIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxhbmUsIGUuZy4gdGhl IGN1c3RvbWVyIGNhbiB0ZWxsIHVzIHRoZSBwaG9uZSAjIG9mIGEgbW9iaWxlIGFuZCB3ZSBjYW4g aW5pdGlhdGUgdGhlIHRyYWNlIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxhbmUuDQpiLiAgSW4gZ2Vu ZXJhbCBzYW1wbGluZyBpcyBnb29kIGVub3VnaCBidXQgZm9yIGRpcmVjdCB0cm91Ymxlc2hvb3Rp bmcgd2l0aCBhIGtub3dsZWRnZWFibGUgY3VzdG9tZXIgd2Ugd291bGQgYW5hbHl6ZSBhIGRpcmVj dCBjb3B5IG9mIHRoZSB0cmFmZmljICh0YWtpbmcgYWxsIHBhY2tldHMpIHNvIHZpZXcgdGhlIHJh bmdlIGFzIHNhbXBsZSBmcm9tIHdoYXRldmVyIHRoZSBwcm9iZSAvIHNhbXBsaW5nIHJhdGUgc2hv dWxkIGJlDQoNCj4gSXMgaXQgdGhlIEMtUGxhbmUgZnVuY3Rpb24gdGhhdCBpcyBhd2FyZSBvZiBw b2xpY2llcyBmb3IgcGFja2V0IHByb2Jlcz8NCkFzIEkgbWVudGlvbiBhYm92ZSwgbm8gb25lIGtu b3dzIHRoZWlyIGN1cnJlbnQgYWRkcmVzcyAtIGVzcGVjaWFsbHkgd2hlbiBJUCBtb2JpbGl0eSBp cyBpbnZvbHZlZC4gICAgVGhlIEMtcGxhbmUgY2FuIGNvcnJlbGF0ZSBvdGhlciBtb2JpbGl0eSBu ZXR3b3JrIElkZW50aWZpZXJzIHRvIGFuIElQIGFkZHJlc3MgYW5kIHRoZW4gc2VuZCBhIGNvbW1h bmQuDQoNCklmIGZ1bGx5IGF1dG9tYXRlZCwgdGhlIEMtcGxhbmUgY2FuIGRvIHRhcmdldGVkIGRp YWdub3N0aWNzIGZvciBvZmZsb2FkIGFuZCwgYmVjYXVzZSBpdCBpcyB0aGUgQy1wbGFuZSBieSBz ZW5kaW5nIGNvbW1hbmRzIHRvIG1vdmUgdXNlcnMgb3IgdGFrZSBvdGhlciBhY3Rpb25zIC0gaXQg aXMsIGFmdGVyIGFsbCB0aGUgQy1wbGFuZS4gICA8IFRoaXMgY291bGQgYmUgYSBmdXR1cmUgcG9z c2liaWxpdHkgLSBJIGFtIG5vdCBwcm9wb3NpbmcgcmUtaG9taW5nIGFuZCBBRiBtb2JpbGl0eSBp cyBhIGRpZmZlcmVudCBtYXR0ZXIgZW50aXJlbHkgd2UgYXJlIGFkZHJlc3NpbmcgaW4gb3RoZXIg d29yayBpbiB0aGUgZ3JvdXANCg0KVGhhbmtzLg0KDQpMeWxlDQoNCg0KT24gVGh1LCBPY3QgOCwg MjAxNSBhdCA5OjAwIEFNLCBNYXJjbyBMaWVic2NoIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldTxt YWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiB3cm90ZToNCllvdSB0aGluayBhYm91dCBz b21ldGhpbmcgbGlrZSBmbG93IHNhbXBsaW5nLCBjb3JyZWN0PyBGcm9tIEZQQyBwcm90b2NvbCBw b2ludCBvZiB2aWV3LCBJIGRvbuKAmXQgc2VlDQppc3N1ZXMgd2l0aCBhZGRpbmcgc3VjaCBwcm9w ZXJ0aWVzLiBBRkFJSyB0aGVyZSBpcyBldmVuIHNvbWUgc3VwcG9ydCBmcm9tIGRhdGEgcGxhbmUg bm9kZXMsIHNvDQplbmZvcmNlbWVudCBvZiB0aGVzZSBwcm9wZXJ0aWVzIHNob3VsZCB3b3JrLg0K DQpOb3csIEkgdW5kZXJzdGFuZCB5b3XigJlyZSByZXF1ZXN0aW5nIGNvbnRyb2wgb24gd2hpY2gg dHJhZmZpYyBzaG91bGQgYmUgcHJvYmVkLiBJbiB0aGF0IGNhc2UgYQ0KbmV3IHByb3BlcnR5IHNo b3VsZCBiZSBhZGRlZC4gVGhlIGFzc29jaWF0ZWQgYXR0cmlidXRlIHNob3VsZCB0aGVuIGFsc28g aW5kaWNhdGUgaG93IG9mdGVuDQpwYWNrZXRzIHNob3VsZCBiZSBwcm9iZWQgKEV2ZXJ5IDFtaW4s IGV2ZXIgMTAwMHRoIHBhY2tldCwgd2hhdGV2ZXIpLg0KU2luY2UgdGhlIGZvcndhcmRpbmcgb2Yg dGhlIGNvcHkgcGFja2V0IGlzIGRpZmZlcmVudCB0aGFuIGZvciB0aGUgYWN0dWFsIGRhdGEgcGFj a2V0LCB0aGUNCnByb2JlIHByb3BlcnR5IHNob3VsZCBhbHNvIGluZGljYXRlIGEgZGVzdGluYXRp b24sIHdoZXJlIHRoZSBjb3B5IHNob3VsZCBiZSBzZW50IHRvLg0KVGhhdOKAmXMgdGhlIHByb3Rv Y29sIHBhcnQgYW5kIGl0IHNob3VsZCBiZSBmZWFzaWJsZSBpZiB3YW50ZWQuDQoNCklzIGl0IHRo ZSBDLVBsYW5lIGZ1bmN0aW9uIHRoYXQgaXMgYXdhcmUgb2YgcG9saWNpZXMgZm9yIHBhY2tldCBw cm9iZXM/IFRvIGV4cGxvaXQgc3VjaCBleHRlbnNpb24sDQppdCBzaG91bGQgYmUsIG90aGVyd2lz ZSB0aGUgcHJvYmUgY29uZmlndXJhdGlvbiBtYXkgYmUgYWNjb21wbGlzaGVkIHZpYSBhIGRpZmZl cmVudCBpbnRlcmZhY2UuDQoNClRoYW5rcywNCk1hcmNvDQoNCg0KDQpGcm9tOiBMeWxlIEJlcnR6 IFttYWlsdG86bHlsZWI1NTExNDRAZ21haWwuY29tPG1haWx0bzpseWxlYjU1MTE0NEBnbWFpbC5j b20+XQ0KU2VudDogRGllbnN0YWcsIDYuIE9rdG9iZXIgMjAxNSAxNzozOA0KVG86IGRyYWZ0LWll dGYtZG1tLWZwYy1jcGRwQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWRtbS1mcGMtY3BkcEBp ZXRmLm9yZz47IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogQ29w eWluZyBUcmFmZmljIGluIEZQQw0KDQpXaGVuIGxvb2tpbmcgYXQgdGhlIGxhdGVzdCBkcmFmdCBJ IHdhcyBjdXJpb3VzIGFib3V0IGhvdyBjb3B5aW5nIGZvciB0aGUgcHVycG9zZSBvZiB0cm91Ymxl c2hvb3RpbmcgLyBwcm9iZXMgd291bGQgYmUgc3VwcG9ydGVkPw0KDQpNeSB0aG91Z2h0IHdvdWxk IGJlIHNvbWUgc29ydCBvZiBwcm9wZXJ0eSBvbiBhIHBvcnQgdGhhdCBjb3BpZXMgdGhlIHRyYWZm aWMgYW5kIG5vdGVzIHRoZSBQUlQgdGhhdCBpdCBjb3VsZCBiZSBmb3J3YXJkZWQgdG8uDQoNCkNv dWxkIHdlIHN1cHBvcnQgdGhpcyB1c2UgY2FzZSAoSSBhbSBub3QgbWFycmllZCB0byB0aGUgc3Vn Z2VzdGlvbiBhYm92ZSkgaW4gdGhlIHNwZWNpZmljYXRpb24gZ2l2ZW4gaXRzIGltcG9ydGFuY2Ug dG8gdHJvdWJsZSBtYW5hZ2VtZW50PyAgIFRoaXMgaXMgZWFzeSBlbm91Z2ggdG8gc3VwcG9ydCBp biB1bmRlcmx5aW5nIERQTiB0ZWNobm9sb2dpZXMgc3VjaCBhcyBTRE4gYW5kIEkgc2VlIG5vIHJl YXNvbiB0byBub3Qgc3BlY2lmeSBpdCBpbiBGUEMgYW5kIGF2b2lkIHVzaW5nIHlldCBhbm90aGVy IHByb3RvY29sIGZvciBmb3J3YXJkaW5nLg0KDQpDb21tZW50cyAvIFRob3VnaHRzIHdvdWxkIGJl IGFwcHJlY2lhdGVkIG9uIHRoaXMgbWF0dGVyLg0KDQpUaGFuayB5b3UuDQoNCkx5bGUNCg0K --_000_69756203DDDDE64E987BC4F70B71A26DA63B5D6CPALLENEofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+T2ssIHVuZGVyc3RhbmQuIEl04oCZcyBub3QgZm9yIGNhc2VzIGxpa2UgY2hh cmdpbmcvbW9uaXRvcmluZyBiYXNlZCBvbiBzYW1wbGVzLCBidXQgeW91IHBsYW4gdXNpbmcgaXQ8 YnI+DQpvbi9vZmYgdW5kZXIgY29udHJvbCBvZiB0aGUgQy1QbGFuZSBhbmQgb25seSBvbiBkZW1h bmQgYW5kIG9ubHkgZm9yIHNlbGVjdGVkIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBpZiB3ZSBhc3N1 bWUgdGhpcyBlbmZvcmNlbWVudCBnb2VzIHZpYSB0aGUgbW9iaWxpdHkgQy1QbGFuZSBmdW5jdGlv biwgaXQgY291bGQgYmUgYSBmZWF0dXJlIHRoYXQ8YnI+DQpjYW4gYmUgYWRkZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PdGhlcnPigJkgb3BpbmlvbiBvbiB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+bWFyY28NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMeWxlIEJlcnR6IFttYWlsdG86bHls ZWI1NTExNDRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0YWcsIDguIE9r dG9iZXIgMjAxNSAxNzowMjxicj4NCjxiPlRvOjwvYj4gTWFyY28gTGllYnNjaDxicj4NCjxiPkNj OjwvYj4gZHJhZnQtaWV0Zi1kbW0tZnBjLWNwZHBAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogQ29weWluZyBUcmFmZmljIGluIEZQQzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJjbyw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndydDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgWW91IHRoaW5rIGFib3V0IHNvbWV0aGluZyBsaWtl IGZsb3cgc2FtcGxpbmcsIGNvcnJlY3Q/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIEkgYW0gdGhpbmtpbmcgYWJvdXQgc2Ft cGxpbmcgb3IgdHJvdWJsZSBtYW5hZ2VtZW50IChlbmdpbmVlciB3b3JraW5nIGRpcmVjdGx5IHdp dGggYSBjdXN0b21lciB0byBmaXggJ3NvbWV0aGluZycgb3Igc2FtcGxpbmcgYmFzZWQgdXBvbiBv dGhlciBPU1MgZGF0YSB0aGF0IGluZGljYXRlcyBpc3N1ZXMgaW4gdGhlIGFyZWEpLCBpbiBzdWNo IGNhc2VzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5hLiZuYnNwOyBUaGUgY3VzdG9tZXIgKGFuZCBlbmdpbmVlcikgd2lsbCBub3Qga25v dyBhbnl0aGluZyBhYm91dCBtb2JpbGl0eSBpbmZvcm1hdGlvbiBzbyB0aGlzIGlzIGluaXRpYXRl ZCB0aHJvdWdoIHRoZSBjb250cm9sIHBsYW5lLCBlLmcuIHRoZSBjdXN0b21lciBjYW4gdGVsbCB1 cyB0aGUgcGhvbmUgIyBvZiBhIG1vYmlsZSBhbmQgd2UgY2FuIGluaXRpYXRlIHRoZSB0cmFjZSB0 aHJvdWdoIHRoZSBjb250cm9sIHBsYW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Yi4mbmJzcDsgSW4gZ2VuZXJhbCBzYW1wbGluZyBpcyBnb29k IGVub3VnaCBidXQgZm9yIGRpcmVjdCB0cm91Ymxlc2hvb3Rpbmcgd2l0aCBhIGtub3dsZWRnZWFi bGUgY3VzdG9tZXIgd2Ugd291bGQgYW5hbHl6ZSBhIGRpcmVjdCBjb3B5IG9mIHRoZSB0cmFmZmlj ICh0YWtpbmcgYWxsIHBhY2tldHMpIHNvIHZpZXcgdGhlIHJhbmdlIGFzIHNhbXBsZSBmcm9tIHdo YXRldmVyIHRoZSBwcm9iZSAvIHNhbXBsaW5nIHJhdGUgc2hvdWxkDQogYmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JcyBpdCB0aGUgQy1QbGFuZSBm dW5jdGlvbiB0aGF0IGlzIGF3YXJlIG9mIHBvbGljaWVzIGZvciBwYWNrZXQgcHJvYmVzPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBJIG1lbnRpb24gYWJv dmUsIG5vIG9uZSBrbm93cyB0aGVpciBjdXJyZW50IGFkZHJlc3MgLSBlc3BlY2lhbGx5IHdoZW4g SVAgbW9iaWxpdHkgaXMgaW52b2x2ZWQuICZuYnNwOyAmbmJzcDtUaGUgQy1wbGFuZSBjYW4gY29y cmVsYXRlIG90aGVyIG1vYmlsaXR5IG5ldHdvcmsgSWRlbnRpZmllcnMNCiB0byBhbiBJUCBhZGRy ZXNzIGFuZCB0aGVuIHNlbmQgYSBjb21tYW5kLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGZ1bGx5IGF1dG9tYXRl ZCwgdGhlIEMtcGxhbmUgY2FuIGRvIHRhcmdldGVkIGRpYWdub3N0aWNzIGZvciBvZmZsb2FkIGFu ZCwgYmVjYXVzZSBpdCBpcyB0aGUgQy1wbGFuZSBieSBzZW5kaW5nIGNvbW1hbmRzIHRvIG1vdmUg dXNlcnMgb3IgdGFrZSBvdGhlciBhY3Rpb25zIC0gaXQgaXMsIGFmdGVyIGFsbCB0aGUgQy1wbGFu ZS4gJm5ic3A7ICZsdDsgVGhpcyBjb3VsZCBiZSBhIGZ1dHVyZSBwb3NzaWJpbGl0eSAtIEkgYW0N CiBub3QgcHJvcG9zaW5nIHJlLWhvbWluZyBhbmQgQUYgbW9iaWxpdHkgaXMgYSBkaWZmZXJlbnQg bWF0dGVyIGVudGlyZWx5IHdlIGFyZSBhZGRyZXNzaW5nIGluIG90aGVyIHdvcmsgaW4gdGhlIGdy b3VwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+THlsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBPY3QgOCwgMjAxNSBhdCA5OjAwIEFNLCBNYXJjbyBMaWVic2NoICZs dDs8YSBocmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5r Ij5NYXJjby5MaWVic2NoQG5lY2xhYi5ldTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3UgdGhpbmsgYWJvdXQgc29tZXRoaW5nIGxpa2UgZmxv dyBzYW1wbGluZywgY29ycmVjdD8gRnJvbSBGUEMgcHJvdG9jb2wgcG9pbnQgb2YgdmlldywgSSBk b27igJl0IHNlZTxicj4NCmlzc3VlcyB3aXRoIGFkZGluZyBzdWNoIHByb3BlcnRpZXMuIEFGQUlL IHRoZXJlIGlzIGV2ZW4gc29tZSBzdXBwb3J0IGZyb20gZGF0YSBwbGFuZSBub2Rlcywgc288YnI+ DQplbmZvcmNlbWVudCBvZiB0aGVzZSBwcm9wZXJ0aWVzIHNob3VsZCB3b3JrLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk5vdywgSSB1bmRlcnN0YW5kIHlvdeKAmXJlIHJlcXVlc3RpbmcgY29udHJvbCBvbiB3aGlj aCB0cmFmZmljIHNob3VsZCBiZSBwcm9iZWQuIEluIHRoYXQgY2FzZSBhPGJyPg0KbmV3IHByb3Bl cnR5IHNob3VsZCBiZSBhZGRlZC4gVGhlIGFzc29jaWF0ZWQgYXR0cmlidXRlIHNob3VsZCB0aGVu IGFsc28gaW5kaWNhdGUgaG93IG9mdGVuPGJyPg0KcGFja2V0cyBzaG91bGQgYmUgcHJvYmVkIChF dmVyeSAxbWluLCBldmVyIDEwMDA8c3VwPnRoPC9zdXA+IHBhY2tldCwgd2hhdGV2ZXIpLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHRoZSBmb3J3YXJkaW5nIG9mIHRoZSBj b3B5IHBhY2tldCBpcyBkaWZmZXJlbnQgdGhhbiBmb3IgdGhlIGFjdHVhbCBkYXRhIHBhY2tldCwg dGhlPGJyPg0KcHJvYmUgcHJvcGVydHkgc2hvdWxkIGFsc28gaW5kaWNhdGUgYSBkZXN0aW5hdGlv biwgd2hlcmUgdGhlIGNvcHkgc2hvdWxkIGJlIHNlbnQgdG8uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhdOKAmXMgdGhlIHByb3RvY29sIHBhcnQgYW5kIGl0IHNob3VsZCBiZSBm ZWFzaWJsZSBpZiB3YW50ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgaXQgdGhlIEMtUGxhbmUgZnVuY3Rp b24gdGhhdCBpcyBhd2FyZSBvZiBwb2xpY2llcyBmb3IgcGFja2V0IHByb2Jlcz8gVG8gZXhwbG9p dCBzdWNoIGV4dGVuc2lvbiw8YnI+DQppdCBzaG91bGQgYmUsIG90aGVyd2lzZSB0aGUgcHJvYmUg Y29uZmlndXJhdGlvbiBtYXkgYmUgYWNjb21wbGlzaGVkIHZpYSBhIGRpZmZlcmVudCBpbnRlcmZh Y2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1hcmNvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBMeWxlIEJlcnR6IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmx5 bGViNTUxMTQ0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmx5bGViNTUxMTQ0QGdtYWlsLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRGllbnN0YWcsIDYuIE9rdG9iZXIgMjAxNSAxNzoz ODxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZG1tLWZwYy1jcGRw QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1kbW0tZnBjLWNwZHBAaWV0Zi5v cmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRt bUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gQ29weWluZyBUcmFmZmljIGluIEZQ Qzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5XaGVuIGxvb2tpbmcgYXQgdGhlIGxhdGVzdCBkcmFmdCBJIHdhcyBj dXJpb3VzIGFib3V0IGhvdyBjb3B5aW5nIGZvciB0aGUgcHVycG9zZSBvZiB0cm91Ymxlc2hvb3Rp bmcgLyBwcm9iZXMgd291bGQgYmUgc3VwcG9ydGVkPyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSB0aG91Z2h0IHdvdWxkIGJl IHNvbWUgc29ydCBvZiBwcm9wZXJ0eSBvbiBhIHBvcnQgdGhhdCBjb3BpZXMgdGhlIHRyYWZmaWMg YW5kIG5vdGVzIHRoZSBQUlQgdGhhdCBpdCBjb3VsZCBiZSBmb3J3YXJkZWQgdG8uICZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Q291bGQgd2Ugc3VwcG9ydCB0aGlzIHVzZSBjYXNlIChJIGFtIG5vdCBtYXJyaWVkIHRv IHRoZSBzdWdnZXN0aW9uIGFib3ZlKSBpbiB0aGUgc3BlY2lmaWNhdGlvbiBnaXZlbiBpdHMgaW1w b3J0YW5jZSB0byB0cm91YmxlIG1hbmFnZW1lbnQ/ICZuYnNwOyBUaGlzIGlzIGVhc3kgZW5vdWdo IHRvIHN1cHBvcnQgaW4gdW5kZXJseWluZw0KIERQTiB0ZWNobm9sb2dpZXMgc3VjaCBhcyBTRE4g YW5kIEkgc2VlIG5vIHJlYXNvbiB0byBub3Qgc3BlY2lmeSBpdCBpbiBGUEMgYW5kIGF2b2lkIHVz aW5nIHlldCBhbm90aGVyIHByb3RvY29sIGZvciBmb3J3YXJkaW5nLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29tbWVudHMgLyBUaG91 Z2h0cyB3b3VsZCBiZSBhcHByZWNpYXRlZCBvbiB0aGlzIG1hdHRlci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rIHlvdS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K THlsZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_69756203DDDDE64E987BC4F70B71A26DA63B5D6CPALLENEofficehd_-- From nobody Thu Oct 8 09:53: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 E19541A9241 for ; Thu, 8 Oct 2015 09:53:16 -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 0zSLwceoiSsr for ; Thu, 8 Oct 2015 09:53:14 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e: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 C10C51A92FC for ; Thu, 8 Oct 2015 09:53:14 -0700 (PDT) Received: by pablk4 with SMTP id lk4so59668398pab.3 for ; Thu, 08 Oct 2015 09:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:date:subject:references :to; bh=rSi4gMtRaFNLlkvRjIfXauWmdksTBuZ+eOa50VfmGL4=; b=gJQsayz0uaFfyKsVQDKth97uSRyW4KpgCSD5Xty6MJ9ndyVNHB6bYBE4sH17asX4k2 MjtItPT2evBefhEPzf0gDQwoERdzfv2nCxIGV4CLSka3AsGd3EuqougSt49E5FKH5xBO NuUqTmGfRaUcfi0REg9kEg5/SwFfgFVgDhYZw3QSRftZ0Qau/1ow9p/pF3OygKn9KoRY ODohVXNBqxghvooFMEsJs7RkQUQT4KBG/JLwi0kafqmv+94TNZNXOiAI1x7Np5SUa/tt 0Y3pbYbJRYT1B3Hp6wZ+mQVAwQYC8JWNEzSwPBCmmHhYIkRh4vpx5wiegI85gfupq5AM bTjw== X-Received: by 10.68.217.8 with SMTP id ou8mr9352452pbc.164.1444323194463; Thu, 08 Oct 2015 09:53:14 -0700 (PDT) Received: from [10.0.1.6] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id tj2sm46677091pab.4.2015.10.08.09.53.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Oct 2015 09:53:13 -0700 (PDT) From: Jong-Hyouk Lee Content-Type: multipart/alternative; boundary="Apple-Mail=_FA14630A-FE7B-4862-9C1B-90218BFD304C" Message-Id: <6EF6DE93-1269-44A9-B5F9-445DDBA4191D@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Fri, 9 Oct 2015 01:53:09 +0900 References: <20151008161925.6582.68880.idtracker@ietfa.amsl.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-jhlee-dmm-dnpp-00.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: Thu, 08 Oct 2015 16:53:17 -0000 --Apple-Mail=_FA14630A-FE7B-4862-9C1B-90218BFD304C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, For the mobile node moved from a previous network to a new network, the = access router (having a forwarding function) at the new network may need = to obtain the previous network prefix information (i.e., deprecated = network prefix information at the new network) of the mobile node for = data packet forwarding of the mobile node. The draft introduces new = extensions to router advertisement (RA) and router solicitation (RS) = messages. The extension to RS messages is used by the mobile node to = provide the previous network prefix information to an access router. The = extension to RA messages is used by the access router to request the = previous network prefix information in a RS message. Comments on the draft =E2=80=9Cdeprecated network prefix provision" are = welcome. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-jhlee-dmm-dnpp-00.txt > Date: October 9, 2015 at 1:19:25 AM GMT+9 > To: "Jong-Hyouk Lee" , "Zhiwei Yan" = , "Jong-Hyouk Lee" , "Zhiwei = Yan" >=20 >=20 > A new version of I-D, draft-jhlee-dmm-dnpp-00.txt > has been successfully submitted by Jong-Hyouk Lee and posted to the > IETF repository. >=20 > Name: draft-jhlee-dmm-dnpp > Revision: 00 > Title: Deprecated Network Prefix Provision > Document date: 2015-10-08 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-jhlee-dmm-dnpp-00.txt > Status: https://datatracker.ietf.org/doc/draft-jhlee-dmm-dnpp/ > Htmlized: https://tools.ietf.org/html/draft-jhlee-dmm-dnpp-00 >=20 >=20 > Abstract: > This document introduces new extensions to router advertisement and > router solicitation messages. The extensions are used to provide a > mobile node's deprecated network prefix information to an access > router. This document updates [RFC4861]. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 --Apple-Mail=_FA14630A-FE7B-4862-9C1B-90218BFD304C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,

For the mobile node moved from a = previous network to a new network, the access router (having a = forwarding function) at the new network may need to obtain the previous = network prefix information (i.e., deprecated network prefix information = at the new network) of the mobile node for data packet forwarding of the = mobile node. The draft introduces new extensions to router advertisement = (RA) and router solicitation (RS) messages.  The extension to RS = messages is used by the mobile node to provide the previous network = prefix information to an access router. The extension to RA messages is = used by the access router to request the previous network prefix = information in a RS message.

Comments on the draft =E2=80=9Cdeprecated= network prefix provision" are welcome.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-jhlee-dmm-dnpp-00.txt
Date: = October 9, 2015 at 1:19:25 AM = GMT+9
To: = "Jong-Hyouk Lee" <jonghyouk@smu.ac.kr>, "Zhiwei Yan" <yanzhiwei@cnnic.cn>, = "Jong-Hyouk Lee" <jonghyouk@smu.ac.kr>, "Zhiwei Yan" <yanzhiwei@cnnic.cn>


A new version of I-D, = draft-jhlee-dmm-dnpp-00.txt
has been successfully = submitted by Jong-Hyouk Lee and posted to the
IETF = repository.

Name: = draft-jhlee-dmm-dnpp
Revision: 00
Title:= = Deprecated Network Prefix Provision
Document = date: = 2015-10-08
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-jhlee-dmm-dnpp-00.tx= t
Status: =         https://datatracker.ietf.org/doc/draft-jhlee-dmm-dnpp/
Htmlized:       https://tools.ietf.org/html/draft-jhlee-dmm-dnpp-00


Abstract:
=   This document introduces new extensions to router = advertisement and
  router solicitation = messages.  The extensions are used to provide a
=   mobile node's deprecated network prefix information to an = access
  router.  This document updates = [RFC4861].




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




= --Apple-Mail=_FA14630A-FE7B-4862-9C1B-90218BFD304C-- From nobody Thu Oct 8 14:04:58 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 8C3AA1ACE2E for ; Thu, 8 Oct 2015 14:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 W1vIm8VqcFmd for ; Thu, 8 Oct 2015 14:04:53 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e: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 9B37D1ACE20 for ; Thu, 8 Oct 2015 14:04:53 -0700 (PDT) Received: by padhy16 with SMTP id hy16so64708578pad.1 for ; Thu, 08 Oct 2015 14:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nrT+G/QQS7o2oVPKwLMi8sRYDHXn90kDfqxPprybRow=; b=K32ZBbi3Jj1UmcwOR6Lsvei9Df4MzArpfa3UWbJ8H/OYFkL2dePKQcicSPe8WCDqEX NYRnSBMk4c4AmgmKn6ziYETK59wMUAZI1IDSO1TzvXNZ7gIQzPGLT6nzYbYMOth+cxOh ITc5yhOuXUbCyZSB1TyGUnXjsfArXAWU28/G2lF4VL7OvKyxa+tEoYyPi+dwH7/itvXF OEOt9CTXgccWxu8EpibuU4OkttTnbzPLF+eo3Xki6dRp2SugqbnUEUyDGMA7vMu/niE4 TXQZK2XupG0nVn6O+scVsUXUOiIsaWuqL4NG3d8yCz/c54bOIaoOHltKX19wJrwRyZQj fMdQ== X-Received: by 10.68.216.135 with SMTP id oq7mr2388113pbc.9.1444338293288; Thu, 08 Oct 2015 14:04:53 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:a813:c131:d681:f3b? ([2601:647:4204:228b:a813:c131:d681:f3b]) by smtp.gmail.com with ESMTPSA id xu5sm47443292pab.12.2015.10.08.14.04.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Oct 2015 14:04:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: <6EF6DE93-1269-44A9-B5F9-445DDBA4191D@gmail.com> Date: Thu, 8 Oct 2015 14:04:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151008161925.6582.68880.idtracker@ietfa.amsl.com> <6EF6DE93-1269-44A9-B5F9-445DDBA4191D@gmail.com> To: Jong-Hyouk Lee X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-jhlee-dmm-dnpp-00.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: Thu, 08 Oct 2015 21:04:57 -0000 I would love to see the security considerations for this proposal and = more discussion on the reliability of this method. Also what happens if = the access router cannot add filters for the =E2=80=9Cdeprecated network = prefix=E2=80=9D i.e. the prefix does not belong to the new link from = routing point of view? - Jouni > On 08 Oct 2015, at 09:53, Jong-Hyouk Lee wrote: >=20 > Hello, >=20 > For the mobile node moved from a previous network to a new network, = the access router (having a forwarding function) at the new network may = need to obtain the previous network prefix information (i.e., deprecated = network prefix information at the new network) of the mobile node for = data packet forwarding of the mobile node. The draft introduces new = extensions to router advertisement (RA) and router solicitation (RS) = messages. The extension to RS messages is used by the mobile node to = provide the previous network prefix information to an access router. The = extension to RA messages is used by the access router to request the = previous network prefix information in a RS message. >=20 > Comments on the draft =E2=80=9Cdeprecated network prefix provision" = are welcome. >=20 > J. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University >=20 > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-jhlee-dmm-dnpp-00.txt >> Date: October 9, 2015 at 1:19:25 AM GMT+9 >> To: "Jong-Hyouk Lee" , "Zhiwei Yan" = , "Jong-Hyouk Lee" , "Zhiwei = Yan" >>=20 >>=20 >> A new version of I-D, draft-jhlee-dmm-dnpp-00.txt >> has been successfully submitted by Jong-Hyouk Lee and posted to the >> IETF repository. >>=20 >> Name: draft-jhlee-dmm-dnpp >> Revision: 00 >> Title: Deprecated Network Prefix Provision >> Document date: 2015-10-08 >> Group: Individual Submission >> Pages: 5 >> URL: = https://www.ietf.org/internet-drafts/draft-jhlee-dmm-dnpp-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-jhlee-dmm-dnpp/ >> Htmlized: https://tools.ietf.org/html/draft-jhlee-dmm-dnpp-00 >>=20 >>=20 >> Abstract: >> This document introduces new extensions to router advertisement and >> router solicitation messages. The extensions are used to provide a >> mobile node's deprecated network prefix information to an access >> router. This document updates [RFC4861]. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Oct 8 18:43: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 F35BF1B3039 for ; Thu, 8 Oct 2015 18:43:42 -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 dPGesSRLuPcn for ; Thu, 8 Oct 2015 18:43:39 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 A86471B3038 for ; Thu, 8 Oct 2015 18:43:39 -0700 (PDT) Received: by pacex6 with SMTP id ex6so70821104pac.0 for ; Thu, 08 Oct 2015 18:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dB+8ukDPQgMXQW+OPwiqeTfgQuxTNq/bjybcnKPyaQ4=; b=pGsqwfaBiMq3aBUHA1DYgKWb4gYFFVgrONCbnZZzbX0vrqzUtkF4ZnpqAJ0HnDYBnu 9NsR3hKmZcijFQfpEh8GUxbk6GojJLtWJR/nEUcrfdQh54InSAToIpsExz1xC5SAfSW8 B61yiWOGeHuF4FnlEFuccUw4z920C4EMYvtoqEDV62Vsur4TfA/jOAU/iAnB+np0x+as 3TrOEwSRk7hCsKHPIwf3GoH9QGInQ46EFd2xjx0jxnOJZF4IFIDmEwLamxc8umwwMaaR 3mlFMCgMGpwTxe6ObPZAtjAbwMeewiNzNy5vM9cFW2uxVDhvQBELHtGBqh38rU4obN+X NcHg== X-Received: by 10.68.87.161 with SMTP id az1mr11835350pbb.47.1444355019319; Thu, 08 Oct 2015 18:43:39 -0700 (PDT) Received: from [10.0.1.6] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id bs3sm47874664pbd.89.2015.10.08.18.43.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Oct 2015 18:43:38 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Jong-Hyouk Lee In-Reply-To: Date: Fri, 9 Oct 2015 10:43:34 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <36215FF2-8AA5-467D-97D0-FAAC33208526@gmail.com> References: <20151008161925.6582.68880.idtracker@ietfa.amsl.com> <6EF6DE93-1269-44A9-B5F9-445DDBA4191D@gmail.com> To: Jouni X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-jhlee-dmm-dnpp-00.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: Fri, 09 Oct 2015 01:43:43 -0000 Thanks for the comments. Plz see inline. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Oct 9, 2015, at 6:04 AM, Jouni wrote: >=20 > I would love to see the security considerations for this proposal and = more discussion on the reliability of this method. Let me update these aspects later. A short response is that the extended = RS and RA messages can be protected with SEND. Are you concerning about = the deprecated address ownership?=20 > Also what happens if the access router cannot add filters for the = =E2=80=9Cdeprecated network prefix=E2=80=9D i.e. the prefix does not = belong to the new link from routing point of view? The provided deprecated network prefix information will be used by the = new AR. It can be used to establish a tunnel with the previous AR for = the MN=E2=80=99s data forwarding. It can be also used to update = filtering rules (e.g., ingress filtering rules for the MN=E2=80=99s data = packets can be updated directly by the new AR or the relevant = information is transferred). In case that the provided deprecated = network prefix is not relevant to the new link from routing point of = view, the AR simply does nothing with the deprecated network prefix and = informs about it to the MN by sending a RA message. Note that for this = we will update the draft. Is it what you wanted to know? Otherwise, let = me explain in other ways.=20 J.=20 >=20 > - Jouni >=20 >=20 >> On 08 Oct 2015, at 09:53, Jong-Hyouk Lee wrote: >>=20 >> Hello, >>=20 >> For the mobile node moved from a previous network to a new network, = the access router (having a forwarding function) at the new network may = need to obtain the previous network prefix information (i.e., deprecated = network prefix information at the new network) of the mobile node for = data packet forwarding of the mobile node. The draft introduces new = extensions to router advertisement (RA) and router solicitation (RS) = messages. The extension to RS messages is used by the mobile node to = provide the previous network prefix information to an access router. The = extension to RA messages is used by the access router to request the = previous network prefix information in a RS message. >>=20 >> Comments on the draft =E2=80=9Cdeprecated network prefix provision" = are welcome. >>=20 >> J. >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-jhlee-dmm-dnpp-00.txt >>> Date: October 9, 2015 at 1:19:25 AM GMT+9 >>> To: "Jong-Hyouk Lee" , "Zhiwei Yan" = , "Jong-Hyouk Lee" , "Zhiwei = Yan" >>>=20 >>>=20 >>> A new version of I-D, draft-jhlee-dmm-dnpp-00.txt >>> has been successfully submitted by Jong-Hyouk Lee and posted to the >>> IETF repository. >>>=20 >>> Name: draft-jhlee-dmm-dnpp >>> Revision: 00 >>> Title: Deprecated Network Prefix Provision >>> Document date: 2015-10-08 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = https://www.ietf.org/internet-drafts/draft-jhlee-dmm-dnpp-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-jhlee-dmm-dnpp/ >>> Htmlized: https://tools.ietf.org/html/draft-jhlee-dmm-dnpp-00 >>>=20 >>>=20 >>> Abstract: >>> This document introduces new extensions to router advertisement and >>> router solicitation messages. The extensions are used to provide a >>> mobile node's deprecated network prefix information to an access >>> router. This document updates [RFC4861]. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Sun Oct 11 18:17:12 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 EECC01A1B2B for ; Sun, 11 Oct 2015 18:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NgdOsVq2YrfQ for ; Sun, 11 Oct 2015 18:17:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B5B1B2F70 for ; Sun, 11 Oct 2015 18:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37719; q=dns/txt; s=iport; t=1444612626; x=1445822226; h=from:to:cc:subject:date:message-id:mime-version; bh=V2VlwnqARzL2xqpEg0OnRdatR2TWFrdBi7tghyFv2mc=; b=hQ2fju4HmktBPIXUT+DRAkvxMoBdpqQtVGt/5ugwbR0rJQ8QhACdj1dB +8mUvwpYxAlCQm30TTZTrSxZX5okJAM+xH8ZX2enxbkUys7dbZNETJ3NQ 0ZlRzfRU/JPDDZKIakxbIYaelIuKzZmQqvLIojnoGGNjSkb8FesdiO8lQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtBAC+CBtW/5RdJa1UBwOCWU1Ubgasa5BZKwENgVcDFwEJgnKCCn8CgSM4FAEBAQEBAQGBCoQpBBpXCA4EARYEJgEGIhcUAxAEDgWILg28QQEBAQEBAQEBAQEBAQEBAQEBAQEZBIZvhH6EKgYLASUcEAYTghxPgTEFhzyOVwF5hB+FSoI3gVgVM4NyhzCFeYRZg24BEQ4BAUKCER2BVHGGIQkXBB+BBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,670,1437436800"; d="scan'208,217";a="197008825" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 01:17:04 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9C1H4HV015835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2015 01:17:04 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 11 Oct 2015 20:16:52 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Sun, 11 Oct 2015 20:16:52 -0500 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins Thread-Topic: Review comments on draft-ietf-dmm-4283mnids-00.txt Thread-Index: AQHRBIutIaT1hGjEr0Wi1V+KURbHQw== Date: Mon, 12 Oct 2015 01:16:52 +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.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.38.24] Content-Type: multipart/alternative; boundary="_000_D240563D1C167Dsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] Review comments on draft-ietf-dmm-4283mnids-00.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: Mon, 12 Oct 2015 01:17:11 -0000 --_000_D240563D1C167Dsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Charlie, Please see inline for my review comments. Regards Sri Distributed Mobility Management [dmm] C. Perkins Internet-Draft Futurewei Expires: October 24, 2015 V. Devarapalli Vasona Networks April 22, 2015 MN Identifier Types for RFC 4283 Mobile Node Identifier Option draft-ietf-dmm-4283mnids-00.txt Abstract Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 24, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Perkins & Devarapalli Expires October 24, 2015 [Page 1] Internet-Draft MN Identifier Types for RFC 4283 April 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. New Mobile Node Identifier Types . . . . . . . . . . . . . . 2 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to be a popular design tool for providing identifiers for mobile nodes during authentication procedures with AAA protocols such as Diameter [RFC3588]. To date, only a single type of identifier has been specified, namely the MN NAI. Other types of identifiers are in common use, and even referenced in RFC 4283. [Sri] Some text on the motivation for defining new Types may be helpful. Do= cument is not just standardizing the currently in-use/popular identifier ty= pes, its also introducing new types are not in use. The reasons/interest fo= r defining identifiers that are tied to the physical elements of the device= (RFID, MAC address ..etc) and how it helps in deployment of the technology= may be useful. Few lines of text will really help. In this document, we propose adding some basic types that are commonly in use in various telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI, and IEEE MAC-layer addresses. In addition, we include the IPv6 address itself as a legitimate mobile node identifier. [Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003. 2. New Mobile Node Identifier Types The following types of identifiers are commonly used to identify mobile nodes. For each type, references are provided with full details on the format of the type of identifer. EPC supports several encoding systems or schemes including [Sri] EPC? EPC Tag Standards I assume, not the Evolved Packet Core. Refer= ence to [EPC-Tag-Data] will help o RFID-GID (Global Identifier), o RFID-SGTIN (Serialized Global Trade Item = Number), o RFID-SSCC (Serial Shipping Container), o RFID-GLN (Global Locati= on Number), o RFID-GRAI (Global Returnable Asset Identifier), o RFID-DOD (D= epartment of Defense) and o RFID-GIAI (Global Individual Asset Identifier).= For each RFID scheme except GID, there are two variations: a 64-bit scheme= (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a 96-bit = scheme. Within each scheme, an EPC identifier can be represented in a binar= y form or other forms such as URI. The following list includes the above RF= ID types as well as various other common identifiers and several different = types of DUIDs. Perkins & Devarapalli Expires October 24, 2015 [Page 2] Int= ernet-Draft MN Identifier Types for RFC 4283 April 2015 o IPv6 Address [RFC= 2373] o IMSI [ThreeGPP-IDS] o P-TMSI [ThreeGPP-IDS] o GUTI [ThreeGPP-IDS] o= EUI-48 address [IEEE802] o EUI-64 address [IEEE802] o DUID-LLT [RFC3315] o= DUID-EN [RFC3315] o DUID-LL [RFC3315] o DUID-UUID [RFC6355] o 12-15 reserv= ed o 16 reserved o RFID-SGTIN-64 [EPC-Tag-Data] o RFID-SSCC-64 [EPC-Tag-Dat= a] o RFID-GLN-64 [EPC-Tag-Data] o RFID-GRAI-64 [EPC-Tag-Data] o RFID-DOD-64= [RFID-DoD-96] o RFID-GIAI-64 [EPC-Tag-Data] o 23 reserved o RFID-GID-96 [E= PC-Tag-Data] o RFID-SGTIN-96 [EPC-Tag-Data] o RFID-SSCC-96 [EPC-Tag-Data] o= RFID-GLN-96 [EPC-Tag-Data] o RFID-GRAI-96 [EPC-Tag-Data] o RFID-DOD-96 [RF= ID-DoD-96] o RFID-GIAI-96 [EPC-Tag-Data] o 31 reserved o RFID-GID-URI [EPC-= Tag-Data] o RFID-SGTIN-URI [EPC-Tag-Data] o RFID-SSCC-URI [EPC-Tag-Data] o = RFID-GLN-URI [EPC-Tag-Data] o RFID-GRAI-URI [EPC-Tag-Data] o RFID-DOD-URI [= RFID-DoD-96] o RFID-GIAI-URI [EPC-Tag-Data] o 39-255 reserved [Sri] This is a major issue. I was hoping to see a sub-section for each of the types. We cannot standard= ize a identifier type without providing any explanation on the identifier t= ype or the references to the base definitions. This can be painful, but I'd= have a small section for each of the types. It can be 3 line text on the a= .) Definition b.) Format c.) Example format d.) Reference to the base spec = that defines those identifiers. 3. Security Considerations This document does not introduce any security mechanisms, and does not have any impact on existing security mechanisms. Insofar as the selection of a security association may be dependent on the exact form of a mobile node identifier, additional specification may be necessary when the new identifier types are employed with the general AAA mechanisms for mobile node authorizations. Some identifiers (e.g., IMSI) are considered to be private information. If used in the MNID extension as defined in this document, the packet including the MNID extension should be encrypted Sri] Besides the use of IMSI, the document also defines the use of other se= nsitive identifiers such as IPv6. Mention of the available tools for privacy protection may be helpful. So= me thing along these lines, or better text: " This information is considered to be very sensitive, so care must be ta= ken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages when carrying this sub-= option. The base Proxy Mobile IPv6 specification [RFC5213] specifies the use of IPsec for securing the signaling messages, and those mechanisms can be enabled for protecting this information. Operators can potentially apply IPsec Encapsulating Security Payload (ESP) with confidentiality and integrity protection for protecting the location information. " Perkins & Devarapalli Expires October 24, 2015 [Page 3] Internet-Draft MN I= dentifier Types for RFC 4283 April 2015 so that personal information or tra= ckable identifiers would not be inadvertently disclosed to passive observer= s. Moreover, MNIDs containing sensitive identifiers might only be used for = signaling during initial network entry. Subsequent binding update exchanges= would then rely on a temporary identifier allocated during the initial net= work entry. [Sri] The MAG/MN can certainly obtain an temporary identifier as part of he= access authentication and can use the same in the signaling. But, I'M unaw= are of any spec where the MN identifier changes between initial and subsequ= ent binding updates. Clarification may be help 4. IANA Considerations The new mobile node identifier types defined in the document should be assigned values from the "Mobile Node Identifier Option Subtypes" registry. The following values should be assigned. Perkins & Devarapalli Expires October 24, 2015 [Page 4] New Mobile Node Identifier Types +-----------------+------------------------+ | Identifier Type | Identifier Type Number | +-----------------+------------------------+ | IPv6 Address | 2 | | IMSI | 3 | | P-TMSI | 4 | | EUI-48 address | 5 | | EUI-64 address | 6 | | GUTI | 7 | | DUID-LLT | 8 | | DUID-EN | 9 | | DUID-LL | 10 | | DUID-UUID | 11 | | | 12-15 reserved | | | 16 reserved | | RFID-SGTIN-64 | 17 | | RFID-SSCC-64 | 18 | | RFID-GLN-64 | 19 | | RFID-GRAI-64 | 20 | | RFID-DOD-64 | 21 | | RFID-GIAI-64 | 22 | | | 23 reserved | | RFID-GID-96 | 24 | | RFID-SGTIN-96 | 25 | | RFID-SSCC-96 | 26 | | RFID-GLN-96 | 27 | | RFID-GRAI-96 | 28 | | RFID-DOD-96 | 29 | | RFID-GIAI-96 | 30 | | | 31 reserved | | RFID-GID-URI | 32 | | RFID-SGTIN-URI | 33 | | RFID-SSCC-URI | 34 | | RFID-GLN-URI | 35 | | RFID-GRAI-URI | 36 | | RFID-DOD-URI | 37 | | RFID-GIAI-URI | 38 | | | 39-255 reserved | +-----------------+------------------------+ Table 1 See Section 2 for details about the identifer types. [Sri] But, Section 2 has no text on the above types. Perkins & Devarapalli Expires October 24, 2015 [Page 5] Internet-Draft MN I= dentifier Types for RFC 4283 April 2015 5. References 5.1. Normative Refere= nces [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architec= ture", RFC 2373, July 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon= , T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for = IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4122] Leach, P., Mealling, M., and= R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122,= July 2005. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. = Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 428= 3, November 2005. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., a= nd K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, Janua= ry 2006. [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based= DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2011. 5.2. Informa= tive References [EPC-Tag-Data] EPCglobal Inc., , "EPC(TM) Generation 1 Tag = Data Standards Version 1.1 Rev.1.27 http://www.gs1.org/gsmp/kc/epcglobal/td= s/ tds_1_1_rev_1_27-standard-20050510.pdf", January 2005. [IEEE802] IEEE, ,= "IEEE Std 802: IEEE Standards for Local and Metropolitan Networks: Overvie= w and Architecture", 2001. [RFC3588] Calhoun, P., Loughney, J., Guttman, E.= , Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 200= 3. [RFID-DoD-96] Department of Defense, , "United States Department of Defe= nse Suppliers Passive RFID Information Guide (Version 15.0)", January 2010.= Perkins & Devarapalli Expires October 24, 2015 [Page 6] Internet-Draft MN = Identifier Types for RFC 4283 April 2015 [ThreeGPP-IDS] 3rd Generation Part= nership Project, , "3GPP Technical Specification 23.003 V8.4.0: Technical S= pecification Group Core Network and Terminals; Numbering, addressing and id= entification (Release 8)", March 2009. Authors' Addresses Charles E. Perkin= s Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: += 1-408-330-4586 Email: charliep@computer.org V= ijay Devarapalli Vasona Networks 2900 Lakeside Drive, Suite 180 Santa Clara= , CA 95054 USA [Sri] Vijay ? Who is that ? References to people from ancient history and w= ho are currently dormant can be silently omitted :) --_000_D240563D1C167Dsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Charlie,

Please see inline for my review comments. 

Regards
Sri

<=
pre style=3D"font-size: medium; word-wrap: break-word; ">
Distributed Mobi=
lity Management [dmm]                         C. Perkins
Internet-Draft                                                 Futurewei
Expires: October 24, 2015                                 V. Devarapalli
                                                         Vasona Networks
                                                          April 22, 2015


     MN Identifier Types for RFC 4283 Mobile Node Identifier Option
                    draft-ietf-dmm-4283mnids-00.txt

Abstract

   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at htt=
p://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on October 24, 2015.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.or=
g/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Perkins & Devarapalli   Expires October 24, 2015                [Page 1=
]
=0C
Internet-Draft      MN Identifier Types for RFC 4283          April 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  New Mobile Node Identifier Types  . . . . . . . . . . . . . .   2
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to
   be a popular design tool for providing identifiers for mobile nodes
   during authentication procedures with AAA protocols such as Diameter
   [RFC3588].  To date, only a single type of identifier has been
   specified, namely the MN NAI.  Other types of identifiers are in
   common use, and even referenced in RFC 4283. 
[Sri] Some text on the motiv=
ation for defining new Types may be helpful. Document is not just standardizing the currently in=
-use/popular identifier types, its also introducing new types are not in us=
e. The reasons/interest for defining identifiers that are tied to the physi=
cal elements of the device (RFID, MAC address ..etc) and how it helps in de=
ployment of the technology may be useful. Few lines of text will really hel=
p.

 In this documen=
t, we
   propose adding some basic types that are commonly in use in various
   telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI,
   and IEEE MAC-layer addresses.  In addition, we include the IPv6
   address itself as a legitimate mobile node identifier.

[Sri] References for IMSI, P-TMSI, IMEI, GU=
TI; May be 3GPP TS 23.003.
2.  New Mobile Node Identifier Types

   The following types of identifiers are commonly used to identify
   mobile nodes.  For each type, references are provided with full
   details on the format of the type of identifer.

   EPC supports several encoding systems or schemes including
[Sri] EPC?  EPC Tag Standards I assume, not the Evolved Packet C=
ore.  Reference to [EPC-Tag-Dat=
a] will help
=



   o  RFID-GID (Global Identifier),
   o  RFID-SGTIN (Serialized Global Trade Item Number),
   o  RFID-SSCC (Serial Shipping Container),
   o  RFID-GLN (Global Location Number),
   o  RFID-GRAI (Global Returnable Asset Identifier),
   o  RFID-DOD (Department of Defense) and
   o  RFID-GIAI (Global Individual Asset Identifier).

   For each RFID scheme except GID, there are two variations: a 64-bit
   scheme (for example, GLN-64) and a 96-bit scheme (GLN-96).  GID has
   only a 96-bit scheme.  Within each scheme, an EPC identifier can be
   represented in a binary form or other forms such as URI.

   The following list includes the above RFID types as well as various
   other common identifiers and several different types of DUIDs.




Perkins & Devarapalli   Expires October 24, 2015                [Page 2=
]
=0C
Internet-Draft      MN Identifier Types for RFC 4283          April 2015


   o  IPv6 Address [RFC2373]
   o  IMSI [ThreeGPP-IDS]
   o  P-TMSI [ThreeGPP-IDS]
   o  GUTI [ThreeGPP-IDS]
   o  EUI-48 address [IEEE802]
   o  EUI-64 address [IEEE802]
   o  DUID-LLT [RFC3315]
   o  DUID-EN [RFC3315]
   o  DUID-LL [RFC3315]
   o  DUID-UUID [RFC6355]
   o  12-15 reserved
   o  16 reserved
   o  RFID-SGTIN-64 [EPC-Tag-Data]
   o  RFID-SSCC-64 [EPC-Tag-Data]
   o  RFID-GLN-64 [EPC-Tag-Data]
   o  RFID-GRAI-64 [EPC-Tag-Data]
   o  RFID-DOD-64 [RFID-DoD-96]
   o  RFID-GIAI-64 [EPC-Tag-Data]
   o  23 reserved
   o  RFID-GID-96 [EPC-Tag-Data]
   o  RFID-SGTIN-96 [EPC-Tag-Data]
   o  RFID-SSCC-96 [EPC-Tag-Data]
   o  RFID-GLN-96 [EPC-Tag-Data]
   o  RFID-GRAI-96 [EPC-Tag-Data]
   o  RFID-DOD-96 [RFID-DoD-96]
   o  RFID-GIAI-96 [EPC-Tag-Data]
   o  31 reserved
   o  RFID-GID-URI [EPC-Tag-Data]
   o  RFID-SGTIN-URI [EPC-Tag-Data]
   o  RFID-SSCC-URI [EPC-Tag-Data]
   o  RFID-GLN-URI [EPC-Tag-Data]
   o  RFID-GRAI-URI [EPC-Tag-Data]
   o  RFID-DOD-URI [RFID-DoD-96]
   o  RFID-GIAI-URI [EPC-Tag-Data]
   o  39-255 reserved

[Sri] This is =
a major issue. 
I was hoping to see a sub-section for each of the types. We =
cannot standardize a identifier type without providing any explanation on t=
he identifier type or the references to the base definitions. This can be p=
ainful, but I'd have a small section for each of the types. It can be 3 lin=
e text on the a.) Definition b.) Format c.) Example format d.) Reference to=
 the base spec that defines those identifiers.

<=
/pre>
3.  Security Con=
siderations

   This document does not introduce any security mechanisms, and does
   not have any impact on existing security mechanisms.  Insofar as the
   selection of a security association may be dependent on the exact
   form of a mobile node identifier, additional specification may be
   necessary when the new identifier types are employed with the general
   AAA mechanisms for mobile node authorizations.

   Some identifiers (e.g., IMSI) are considered to be private
   information.  If used in the MNID extension as defined in this
   document, the packet including the MNID extension should be encrypted

Sri] Besides the use of IMSI, the d=
ocument also defines the use of other sensitive identifiers such as IP=
v6. 
   =
Mention of the available tools for privacy protection may be helpful. Some =
thing along these lines, or better text:
  " This information is considered t=
o be very sensitive, so care must be taken to secure the
   Mobile IPv6/Proxy Mobile IPv6 signaling messages when carrying this sub-=
option.
   The base Proxy Mobile IPv6 specification [RFC5213] specifies the use
   of IPsec for securing the signaling messages, and those mechanisms
   can be enabled for protecting this information.  Operators can
   potentially apply IPsec Encapsulating Security Payload (ESP) with
   confidentiality and integrity protection for protecting the location
   information. "

=




Perkins & Devarapalli   Expires October 24, 2015                [Page 3=
]
=0C
Internet-Draft      MN Identifier Types for RFC 4283          April 2015


   so that personal information or trackable identifiers would not be
   inadvertently disclosed to passive observers.  Moreover, MNIDs
   containing sensitive identifiers might only be used for signaling
   during initial network entry.  Subsequent binding update exchanges
   would then rely on a temporary identifier allocated during the
   initial network entry.
[Sri] The MAG/MN can certainly ob=
tain an temporary identifier as part of he access authentication and can us=
e the same in the signaling. But, I'M unaware of any spec where the =
MN identifier changes between initial and subsequent binding updates. Clarifi=
cation may be help
4.  IANA Conside=
rations

   The new mobile node identifier types defined in the document should
   be assigned values from the "Mobile Node Identifier Option Subtypes=
"
   registry.  The following values should be assigned.



Perkins & Devarapalli   Expires October 24, 2015                [Page 4=
]
=0C





                     New Mobi=
le Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               | IMSI            | 3                      |
               | P-TMSI          | 4                      |
               | EUI-48 address  | 5                      |
               | EUI-64 address  | 6                      |
               | GUTI            | 7                      |
               | DUID-LLT        | 8                      |
               | DUID-EN         | 9                      |
               | DUID-LL         | 10                     |
               | DUID-UUID       | 11                     |
               |                 | 12-15 reserved         |
               |                 | 16 reserved            |
               | RFID-SGTIN-64   | 17                     |
               | RFID-SSCC-64    | 18                     |
               | RFID-GLN-64     | 19                     |
               | RFID-GRAI-64    | 20                     |
               | RFID-DOD-64     | 21                     |
               | RFID-GIAI-64    | 22                     |
               |                 | 23 reserved            |
               | RFID-GID-96     | 24                     |
               | RFID-SGTIN-96   | 25                     |
               | RFID-SSCC-96    | 26                     |
               | RFID-GLN-96     | 27                     |
               | RFID-GRAI-96    | 28                     |
               | RFID-DOD-96     | 29                     |
               | RFID-GIAI-96    | 30                     |
               |                 | 31 reserved            |
               | RFID-GID-URI    | 32                     |
               | RFID-SGTIN-URI  | 33                     |
               | RFID-SSCC-URI   | 34                     |
               | RFID-GLN-URI    | 35                     |
               | RFID-GRAI-URI   | 36                     |
               | RFID-DOD-URI    | 37                     |
               | RFID-GIAI-URI   | 38                     |
               |                 | 39-255 reserved        |
               +-----------------+------------------------+

                                  Table 1

   See Section 2 for details about the identifer types.


[Sri] But, Section 2 has no text on the above types=
. 
=

=



Perkins & Devarapalli   Expires October 24, 2015                [Page 5=
]
=0C
Internet-Draft      MN Identifier Types for RFC 4283          April 2015


5.  References

5.1.  Normative References

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122, July
              2005.

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv=
6
              (MIPv6)", RFC 4283, November 2005.

   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Authentication Protocol for Mobile IPv6"=
;, RFC
              4285, January 2006.

   [RFC6355]  Narten, T. and J. Johnson, "Definition of the UUID-Based
              DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August
              2011.

5.2.  Informative References

   [EPC-Tag-Data]
              EPCglobal Inc., , "EPC(TM) Generation 1 Tag Data Standar=
ds
              Version 1.1 Rev.1.27
              http://=
www.gs1.org/gsmp/kc/epcglobal/tds/
              tds_1_1_rev_1_27-standard-20050510.pdf", January 2005.

   [IEEE802]  IEEE, , "IEEE Std 802: IEEE Standards for Local and
              Metropolitan Networks: Overview and Architecture", 2001.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, Septembe=
r 2003.

   [RFID-DoD-96]
              Department of Defense, , "United States Department of
              Defense Suppliers Passive RFID Information Guide (Version
              15.0)", January 2010.






Perkins & Devarapalli   Expires October 24, 2015                [Page 6=
]
=0C
Internet-Draft      MN Identifier Types for RFC 4283          April 2015


   [ThreeGPP-IDS]
              3rd Generation Partnership Project, , "3GPP Technical
              Specification 23.003 V8.4.0: Technical Specification Group
              Core Network and Terminals; Numbering, addressing and
              identification (Release 8)", March 2009.

Authors' Addresses

   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1-408-330-4586
   Email: charliep@computer.org


   Vijay Devarapalli
   Vasona Networks
   2900 Lakeside Drive, Suite 180
   Santa Clara, CA 95054
   USA




[Sri] Vijay ? Who is=
 that ? References to people from ancient history and who are currently dor=
mant can be silently omitted :)

--_000_D240563D1C167Dsgundaveciscocom_-- From nobody Mon Oct 12 16:55:29 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 E01241B2C47 for ; Mon, 12 Oct 2015 16:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, 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 PJXmn3FDIbZ6 for ; Mon, 12 Oct 2015 16:55:24 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA81B2C45 for ; Mon, 12 Oct 2015 16:55:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uGxun7ddUNU9aCgIuMW4o7/k03B0RrKPJerHwLjjFKa682qrq/rX/hvxN+XKNf5C; h=Received:From:Subject:To:References:Cc:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.56] (helo=[192.168.1.68]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Zlmvx-0002UN-CA; Mon, 12 Oct 2015 19:55:13 -0400 From: Charlie Perkins To: "Sri Gundavelli (sgundave)" References: Message-ID: <561C485E.5000708@earthlink.net> Date: Mon, 12 Oct 2015 16:55:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080603050306050500040307" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7f162e732b99520206879097f0330e5fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.56 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Review comments on draft-ietf-dmm-4283mnids-00.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: Mon, 12 Oct 2015 23:55:28 -0000 This is a multi-part message in MIME format. --------------080603050306050500040307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Sri, Thanks for that terrific review. Please see my follow-up below and request for additional discussion. On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote: > 1. Introduction > > The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to > be a popular design tool for providing identifiers for mobile nodes > during authentication procedures with AAA protocols such as Diameter > [RFC3588]. To date, only a single type of identifier has been > specified, namely the MN NAI. Other types of identifiers are in > common use, and even referenced in RFC 4283. > *[Sri] Some text on the motivation for defining new Types may be > helpful. Document is not just standardizing the currently > in-use/popular identifier types, its also introducing new types are > not in use. The reasons/interest for defining identifiers that are > tied to the physical elements of the device (RFID, MAC address ..etc) > and how it helps in deployment of the technology may be useful. Few > lines of text will really help.* Here is the paragraph with some new text: In this document, we propose adding some basic types that are commonly in use in various telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI, and IEEE MAC-layer addresses. In addition, we include the IPv6 address itself as a legitimate mobile node identifier. Defining identifiers that are tied to the physical elements of the device (RFID, MAC address etc.) help in deployment of Mobile IP because in many cases such identifiers are the most natural means for uniquely identifying the device, and will avoid additional look-up steps that might be needed if other identifiers were used. > including the IMSI, P-TMSI, IMEI, GUTI, > and IEEE MAC-layer addresses. In addition, we include the IPv6 > address itself as a legitimate mobile node identifier. > *[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.* Will do. > 2. New Mobile Node Identifier Types > > The following types of identifiers are commonly used to identify > mobile nodes. For each type, references are provided with full > details on the format of the type of identifer. > > EPC supports several encoding systems or schemes including > *[Sri] EPC? EPC Tag Standards I assume, not the Evolved Packet Core. > Reference to [EPC-Tag-Data] will help * Will do. > > > o RFID-GID (Global Identifier), > o RFID-SGTIN (Serialized Global Trade Item Number), .......... /many lines deleted/ .............. > o RFID-DOD-URI [RFID-DoD-96] > o RFID-GIAI-URI [EPC-Tag-Data] > o 39-255 reserved > > *[Sri] This is a major issue. > I was hoping to see a sub-section for > each of the types. We cannot > standardize a identifier type without > providing any explanation on the > identifier type or the references > to the base definitions. This can > be painful, but I'd have a small > section for each of the types. It can > be 3 line text on the a.) > Definition b.) Format c.) Example format d.) > Reference to the base > spec that defines those identifiers.* This might be dangerous, because it would be a partial respecification for for identifiers outside the general expertise of this group. But I will try to think of something. Contributed text will be very much appreciated. > 3. Security Considerations > > This document does not introduce any security mechanisms, and does > not have any impact on existing security mechanisms. Insofar as the > selection of a security association may be dependent on the exact > form of a mobile node identifier, additional specification may be > necessary when the new identifier types are employed with the general > AAA mechanisms for mobile node authorizations. > > Some identifiers (e.g., IMSI) are considered to be private > information. If used in the MNID extension as defined in this > document, the packet including the MNID extension should be encrypted > > *[Sri] Besides the use of IMSI, the document also defines the use of > other sensitive identifiers such as IPv6..* Do you think that IPv6 addresses are more sensitive than IPv4 addresses? > *Mention of the available tools for privacy protection may be helpful. > Some thing along these lines, or better text:* > *"This information is considered to be very sensitive, so care must be > taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages > when carrying this sub-option. The base Proxy Mobile IPv6 > specification [RFC5213] specifies the use of IPsec for securing the > signaling messages, and those mechanisms can be enabled for protecting > this information. Operators can potentially apply IPsec Encapsulating > Security Payload (ESP) with confidentiality and integrity protection > for protecting the location information."* > ** I am O.K. with that text. However, the same considerations apply to RFC 4283, so that the initial paragraph is still sort-of correct. Should I make a statement that our understanding of various vulnerabilities has led to the desire for better security surrounding identification features? > so that personal information or trackable identifiers would not be > inadvertently disclosed to passive observers. Moreover, MNIDs > containing sensitive identifiers might only be used for signaling > during initial network entry. Subsequent binding update exchanges > would then rely on a temporary identifier allocated during the > initial network entry. > *[Sri] The MAG/MN can certainly obtain an temporary identifier as part > of he access authentication and can use the same in the signaling. > But, I'M unaware of any spec where the MN identifier changes between > initial and subsequent binding updates. Clarification may behelp* I put in some clarifying text: Subsequent binding update exchanges might then rely on a temporary identifier allocated during the initial network entry, perhaps using mechanisms not standardized within the IETF. Managing the association between long-lived and temporary identifiers is outside the scope of this document. > 4. > New Mobile Node Identifier Types > > +-----------------+------------------------+ > | Identifier Type | Identifier Type Number | > +-----------------+------------------------+ > | IPv6 Address | 2 | .......... /many lines deleted/ .............. > | RFID-GIAI-URI | 38 | > | | 39-255 reserved | > +-----------------+------------------------+ > > Table 1 > > See Section 2 for details about the identifer types. > > *[Sri] But, Section 2 has no text on the above types.* Point noted, although there is a little bit of explanatory text. Section 2 does have citations. How about: See Section 2 for additional information about the identifier types. Plus, if more text is required about the types, then section 2 would indeed have details. > Vijay Devarapalli > Vasona Networks > 2900 Lakeside Drive, Suite 180 > Santa Clara, CA 95054 > USA > > > *[Sri] Vijay ? Who is that ? References to people from ancient history > and who are currently dormant can be silently omitted :) * > Well, I asked Vijay if he wanted to remain as co-author and he told me he did want to remain. Regards, Charlie P. --------------080603050306050500040307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello Sri,

Thanks for that terrific review.  Please see my follow-up below and request for
additional discussion. 

On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote:
1.  Introduction

   The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to
   be a popular design tool for providing identifiers for mobile nodes
   during authentication procedures with AAA protocols such as Diameter
   [RFC3588].  To date, only a single type of identifier has been
   specified, namely the MN NAI.  Other types of identifiers are in
   common use, and even referenced in RFC 4283. 
[Sri] Some text on the motivation for defining new Types may be helpful.
Document is not just standardizing the currently in-use/popular identifier
types, its also introducing new types are not in use. The reasons/interest
for defining identifiers that are tied to the physical elements of the
device (RFID, MAC address ..etc) and how it helps in deployment of the
technology may be useful. Few lines of text will really help.

Here is the paragraph with some new text:

                                                  In this document, we
    propose adding some basic types that are commonly in use in various
    telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI,
    and IEEE MAC-layer addresses.  In addition, we include the IPv6
    address itself as a legitimate mobile node identifier.
    Defining identifiers that are tied to the physical elements of the
    device (RFID, MAC address etc.) help in deployment of Mobile IP
    because in many cases such identifiers are the most natural means
    for uniquely identifying the device, and will avoid additional
    look-up steps that might be needed if other identifiers were used.

 
                             including the IMSI, P-TMSI, IMEI, GUTI,
   and IEEE MAC-layer addresses.  In addition, we include the IPv6
   address itself as a legitimate mobile node identifier.
[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.

Will do.

2.  New Mobile Node Identifier Types

   The following types of identifiers are commonly used to identify
   mobile nodes.  For each type, references are provided with full
   details on the format of the type of identifer.

   EPC supports several encoding systems or schemes including
[Sri] EPC?  EPC Tag Standards I assume, not the Evolved Packet Core.
      Reference to [EPC-Tag-Data] will help

Will do.



   o  RFID-GID (Global Identifier),
   o  RFID-SGTIN (Serialized Global Trade Item Number),
             .......... many lines deleted ..............
 
   o  RFID-DOD-URI [RFID-DoD-96]
   o  RFID-GIAI-URI [EPC-Tag-Data]
   o  39-255 reserved


[Sri] This is a major issue.
> I was hoping to see a sub-section for each of the types. We cannot
> standardize a identifier type without providing any explanation on the
> identifier type or the references to the base definitions. This can
> be painful, but I'd have a small section for each of the types. It can
> be 3 line text on the a.) Definition b.) Format c.) Example format d.)
> Reference to the base spec that defines those identifiers.

This might be dangerous, because it would be a partial respecification for
for identifiers outside the general expertise of this group.  But I will
try to think of something.  Contributed text will be very much appreciated.

3.  Security Considerations

   This document does not introduce any security mechanisms, and does
   not have any impact on existing security mechanisms.  Insofar as the
   selection of a security association may be dependent on the exact
   form of a mobile node identifier, additional specification may be
   necessary when the new identifier types are employed with the general
   AAA mechanisms for mobile node authorizations.

   Some identifiers (e.g., IMSI) are considered to be private
   information.  If used in the MNID extension as defined in this
   document, the packet including the MNID extension should be encrypted


[Sri] Besides the use of IMSI, the document also defines the use of other
      sensitive identifiers such as IPv6..

Do you think that IPv6 addresses are more sensitive than IPv4 addresses?

    Mention of the available tools for
privacy protection may be helpful. Some thing along these lines, or better
text:
  "This information is considered to be very sensitive, so care must be
   taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages
   when carrying this sub-option.

   The base Proxy Mobile IPv6 specification [RFC5213] specifies the use
   of IPsec for securing the signaling messages, and those mechanisms
   can be enabled for protecting this information.  Operators can
   potentially apply IPsec Encapsulating Security Payload (ESP) with
   confidentiality and integrity protection for protecting the location
   information."
I am O.K. with that text.  However, the same considerations apply to
RFC 4283, so that the initial paragraph is still sort-of correct.  Should
I make a statement that our understanding of various vulnerabilities
has led to the desire for better security surrounding identification
features?

   so that personal information or trackable identifiers would not be
   inadvertently disclosed to passive observers.  Moreover, MNIDs
   containing sensitive identifiers might only be used for signaling
   during initial network entry.  Subsequent binding update exchanges
   would then rely on a temporary identifier allocated during the
   initial network entry.
[Sri] The MAG/MN can certainly obtain an temporary identifier as part
      of he access authentication and can use the same in the signaling.
      But, I'M unaware of any spec where the MN identifier changes between
      initial and subsequent binding updates. Clarification may be help

I put in some clarifying text:

    Subsequent binding update exchanges might then rely on
    a temporary identifier allocated during the initial
    network entry, perhaps using mechanisms not standardized
    within the IETF.  Managing the association between
    long-lived and temporary identifiers is outside the scope
    of this document.


4.
                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |

             .......... many lines deleted ..............

               | RFID-GIAI-URI   | 38                     |
               |                 | 39-255 reserved        |
               +-----------------+------------------------+

                                  Table 1

   See Section 2 for details about the identifer types.


[Sri] But, Section 2 has no text on the above types.

Point noted, although there is a little bit of explanatory text.
Section 2 does have citations.  How about:

    See Section 2 for additional information about the identifier types.

Plus, if more text is required about the types, then section 2 would
indeed have details.

   Vijay Devarapalli
   Vasona Networks
   2900 Lakeside Drive, Suite 180
   Santa Clara, CA 95054
   USA



[Sri] Vijay ? Who is that ? References to people from ancient history
      and who are currently dormant can be silently omitted :)

Well, I asked Vijay if he wanted to remain as co-author and he told me
he did want to remain.

Regards,
Charlie P.
--------------080603050306050500040307-- From nobody Mon Oct 12 18:44:34 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 B1A021B2EDE for ; Mon, 12 Oct 2015 18:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, 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 3zCkCqInA0JK for ; Mon, 12 Oct 2015 18:44:30 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E82C51B2EDD for ; Mon, 12 Oct 2015 18:44:29 -0700 (PDT) Received: from Foxmail (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsU34YRxWxSiaBA--.4917S2; Tue, 13 Oct 2015 09:44:24 +0800 (CST) Date: Tue, 13 Oct 2015 09:44:23 +0800 From: "=?utf-8?B?Wi5XLiBZYW4=?=" To: "=?utf-8?B?ZG1t?=" Message-ID: <201510130944230363409@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon557661760760_=====" X-CM-TRANSID: AQAAf0CpsU34YRxWxSiaBA--.4917S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KryDXF18Zr4xGFyUZFWDArb_yoW8ZryDpF WqqF4rJwn7Z3sFk397ZryUWan8uayDWrWDAFy7tr18Aan8J3WvyrW09F45X34Dur1FkF4q qa1IvFs8urWFgrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9jb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24lYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxMxkF7I0E n4kS14v26r126r1DMxkIecxEwVAFwVWkMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1U MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvf C2KfnxnUUI43ZEXa7IU88HUDUUUUU== X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Cc: =?utf-8?B?Sm9uZy1IeW91ayBMZWU=?= , =?utf-8?B?eGw=?= Subject: [DMM] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-yan-dmm-?= =?utf-8?q?hnprenum-03=2Etxt?= 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, 13 Oct 2015 01:44:32 -0000 This is a multi-part message in MIME format. --=====003_Dragon557661760760_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQpXZSBqdXN0IHJldmlzZWQgdGhlIEhOUC1yZW51bWJlcmluZyBkcmFmdCBiYXNl ZCBvbiB0aGUgY29tbWVudHMgb25saW5lIGFuZCBvZmZsaW5lIGFuZCBwb3N0ZWQgdG8gdGhlIERN TSBXRy4NCkFueSBmdXJ0aGVyIGNvbW1lbnRzIGZyb20geW91IGFyZSBhbHdheXMgd2VsY29tZS4N Cg0KQmVzaWRlcywgSm91bmkgYW5kIERhcGVuZywNCldvdWxkIHlvdSBwbGVhc2UgYXNzaWduIG1l IDUtMTAgbWludXRlcyB0byByZS1pbnRyb2R1Y2UgdGhpcyBkcmFmdCBpbiB0aGUgRE1NIG1lZXRp bmc/DQoNCkJSLA0KDQoNCjIwMTUtMTAtMTMNCg0KDQoNClouVy4gWWFuDQoNCg0KDQrlj5Hku7bk urrvvJogaW50ZXJuZXQtZHJhZnRzDQrlj5HpgIHml7bpl7TvvJogMjAxNS0xMC0xMiAxNDozMzow NA0K5pS25Lu25Lq677yaIFpoaXdlaSBZYW47IFhpYW9Eb25nIExlZTsgWGlhb2RvbmcgTGVlOyBK b25nLUh5b3VrIExlZQ0K5oqE6YCB77yaIA0K5Li76aKY77yaIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQteWFuLWRtbS1obnByZW51bS0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFpoaXdlaSBZYW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3Np dG9yeS4NCk5hbWU6IGRyYWZ0LXlhbi1kbW0taG5wcmVudW0NClJldmlzaW9uOiAwMw0KVGl0bGU6 IEhvbWUgTmV0d29yayBQcmVmaXggUmVudW1iZXJpbmcgaW4gUE1JUHY2DQpEb2N1bWVudCBkYXRl OiAyMDE1LTEwLTExDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogOA0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15 YW4tZG1tLWhucHJlbnVtLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0vDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDMNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteWFu LWRtbS1obnByZW51bS0wMw0KQWJzdHJhY3Q6DQogICBJbiB0aGUgYmFzaWMgUHJveHkgTW9iaWxl IElQdjYgKFBNSVB2Nikgc3BlY2lmaWNhdGlvbiwgYSBNb2JpbGUgTm9kZQ0KICAgKE1OKSBpcyBh c3NpZ25lZCB3aXRoIGEgNjQtYml0IEhvbWUgTmV0d29yayBQcmVmaXggKEhOUCkgZHVyaW5nIGl0 cw0KICAgaW5pdGlhbCBhdHRhY2htZW50IGZvciB0aGUgSG9tZSBBZGRyZXNzIChIb0EpIGNvbmZp Z3VyYXRpb24uICBEdXJpbmcNCiAgIHRoZSBtb3ZlbWVudCBvZiB0aGUgTU4sIHRoaXMgcHJlZml4 IHJlbWFpbnMgdW5jaGFuZ2VkIGFuZCBpbiB0aGlzIHdheQ0KICAgaXQgaXMgdW5uZWNlc3Nhcnkg Zm9yIHRoZSBNTiB0byByZWNvbmZpZ3VyZSBpdHMgSG9BIGFuZCByZWNvbm5lY3QgdGhlDQogICBv bmdvaW5nIGNvbW11bmljYXRpb25zLiAgSG93ZXZlciwgdGhlIGN1cnJlbnQgcHJvdG9jb2wgKFJG QzUyMTMpIGRvZXMNCiAgIG5vdCBzcGVjaWZ5IHJlbGF0ZWQgb3BlcmF0aW9ucyB0byBzdXBwb3J0 IHRoZSBNTiB0byB0aW1lbHkgcmVjZWl2ZQ0KICAgYW5kIHVzZSBhIG5ldyBITlAgd2hlbiB0aGUg YWxsb2NhdGVkIEhOUCBjaGFuZ2VzLiAgSW4gdGhpcyBkcmFmdCwgYQ0KICAgc29sdXRpb24gdG8g c3VwcG9ydCB0aGUgSE5QIHJlbnVtYmVyaW5nIGlzIHByb3Bvc2VkLCBhcyBhbiB1cGRhdGUgb2YN CiAgIFJGQzUyMTMuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== --=====003_Dragon557661760760_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE3NDkyIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRh bmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNl Y3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJ R046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6 IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3 IHsNCglGT05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28t c3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsN CglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0K fQ0KT0wgew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJ TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFS R0lOOiAxMHB4Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxE SVY+RGVhciBBbGwsPC9ESVY+DQo8RElWPldlIGp1c3QgcmV2aXNlZCB0aGUgSE5QLXJlbnVtYmVy aW5nIGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50cyBvbmxpbmUgYW5kIA0Kb2ZmbGluZSBhbmQg cG9zdGVkIHRvIHRoZSBETU0gV0cuPC9ESVY+DQo8RElWPkFueSBmdXJ0aGVyIGNvbW1lbnRzIGZy b20geW91IGFyZSBhbHdheXMgd2VsY29tZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PkJlc2lkZXMsIEpvdW5pIGFuZCBEYXBlbmcsPC9ESVY+DQo8RElWPldvdWxkIHlvdSBwbGVhc2Ug YXNzaWduIG1lIDUtMTAgbWludXRlcyB0byByZS1pbnRyb2R1Y2UgdGhpcyBkcmFmdCBpbiB0aGUg DQpETU0gbWVldGluZz88L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJSLDwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNj MGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4yMDE1LTEwLTEzPC9GT05UPjwvRElWPg0KPERJViBh bGlnbj1sZWZ0Pg0KPEhSIHN0eWxlPSJXSURUSDogMTAwcHgiIGNvbG9yPSNiNWM0ZGYgU0laRT0x Pg0KPC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48 U1BBTj5aLlcuIFlhbjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpF PTE+DQoNCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWPkeS7tuS6uu+8 mjwvU1RST05HPiANCmludGVybmV0LWRyYWZ0czwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWPkemAgeaXtumXtO+8mjwvU1RST05HPiANCjIwMTUt MTAtMTImbmJzcDsxNDozMzowNDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9 VmVyZGFuYT48U1RST05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiBaaGl3ZWkgWWFuOyBYaWFvRG9u ZyBMZWU7IA0KWGlhb2RvbmcgTGVlOyBKb25nLUh5b3VrIExlZTwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuaKhOmAge+8mjwvU1RST05HPiA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7kuLvpopjv vJo8L1NUUk9ORz4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXlhbi1kbW0t aG5wcmVudW0tMDMudHh0PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+PC9ESVY+DQo8RElWPkEmbmJzcDtuZXcmbmJz cDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJLUQsJm5ic3A7ZHJhZnQteWFuLWRtbS1obnByZW51bS0w My50eHQ8L0RJVj4NCjxESVY+aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1 Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7Wmhpd2VpJm5ic3A7WWFuJm5ic3A7YW5kJm5ic3A7cG9zdGVk Jm5ic3A7dG8mbmJzcDt0aGU8L0RJVj4NCjxESVY+SUVURiZuYnNwO3JlcG9zaXRvcnkuPC9ESVY+ DQo8RElWPjwvRElWPg0KPERJVj5OYW1lOiBkcmFmdC15YW4tZG1tLWhucHJlbnVtPC9ESVY+DQo8 RElWPlJldmlzaW9uOiAwMzwvRElWPg0KPERJVj5UaXRsZTogDQpIb21lJm5ic3A7TmV0d29yayZu YnNwO1ByZWZpeCZuYnNwO1JlbnVtYmVyaW5nJm5ic3A7aW4mbmJzcDtQTUlQdjY8L0RJVj4NCjxE SVY+RG9jdW1lbnQmbmJzcDtkYXRlOiAyMDE1LTEwLTExPC9ESVY+DQo8RElWPkdyb3VwOiBJbmRp dmlkdWFsJm5ic3A7U3VibWlzc2lvbjwvRElWPg0KPERJVj5QYWdlczogODwvRElWPg0KPERJVj5V Ukw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXlhbi1kbW0taG5wcmVudW0tMDMudHh0PC9ESVY+DQo8RElWPlN0YXR1czombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW4tZG1tLWhucHJlbnVtLzwvRElWPg0KPERJVj5I dG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWRtbS1obnByZW51bS0wMzwvRElWPg0KPERJ Vj5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC15 YW4tZG1tLWhucHJlbnVtLTAzPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5BYnN0cmFjdDo8L0RJ Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4mbmJzcDt0aGUmbmJzcDtiYXNpYyZuYnNwO1By b3h5Jm5ic3A7TW9iaWxlJm5ic3A7SVB2NiZuYnNwOyhQTUlQdjYpJm5ic3A7c3BlY2lmaWNhdGlv biwmbmJzcDthJm5ic3A7TW9iaWxlJm5ic3A7Tm9kZTwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDsoTU4pJm5ic3A7aXMmbmJzcDthc3NpZ25lZCZuYnNwO3dpdGgmbmJzcDthJm5ic3A7NjQt Yml0Jm5ic3A7SG9tZSZuYnNwO05ldHdvcmsmbmJzcDtQcmVmaXgmbmJzcDsoSE5QKSZuYnNwO2R1 cmluZyZuYnNwO2l0czwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtpbml0aWFsJm5ic3A7 YXR0YWNobWVudCZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO0hvbWUmbmJzcDtBZGRyZXNzJm5ic3A7 KEhvQSkmbmJzcDtjb25maWd1cmF0aW9uLiZuYnNwOyZuYnNwO0R1cmluZzwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDsmbmJzcDt0aGUmbmJzcDttb3ZlbWVudCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 TU4sJm5ic3A7dGhpcyZuYnNwO3ByZWZpeCZuYnNwO3JlbWFpbnMmbmJzcDt1bmNoYW5nZWQmbmJz cDthbmQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDt3YXk8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7aXQmbmJzcDtpcyZuYnNwO3VubmVjZXNzYXJ5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 TU4mbmJzcDt0byZuYnNwO3JlY29uZmlndXJlJm5ic3A7aXRzJm5ic3A7SG9BJm5ic3A7YW5kJm5i c3A7cmVjb25uZWN0Jm5ic3A7dGhlPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO29uZ29p bmcmbmJzcDtjb21tdW5pY2F0aW9ucy4mbmJzcDsmbmJzcDtIb3dldmVyLCZuYnNwO3RoZSZuYnNw O2N1cnJlbnQmbmJzcDtwcm90b2NvbCZuYnNwOyhSRkM1MjEzKSZuYnNwO2RvZXM8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7bm90Jm5ic3A7c3BlY2lmeSZuYnNwO3JlbGF0ZWQmbmJzcDtv cGVyYXRpb25zJm5ic3A7dG8mbmJzcDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7TU4mbmJzcDt0byZu YnNwO3RpbWVseSZuYnNwO3JlY2VpdmU8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5k Jm5ic3A7dXNlJm5ic3A7YSZuYnNwO25ldyZuYnNwO0hOUCZuYnNwO3doZW4mbmJzcDt0aGUmbmJz cDthbGxvY2F0ZWQmbmJzcDtITlAmbmJzcDtjaGFuZ2VzLiZuYnNwOyZuYnNwO0luJm5ic3A7dGhp cyZuYnNwO2RyYWZ0LCZuYnNwO2E8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7c29sdXRp b24mbmJzcDt0byZuYnNwO3N1cHBvcnQmbmJzcDt0aGUmbmJzcDtITlAmbmJzcDtyZW51bWJlcmlu ZyZuYnNwO2lzJm5ic3A7cHJvcG9zZWQsJm5ic3A7YXMmbmJzcDthbiZuYnNwO3VwZGF0ZSZuYnNw O29mPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO1JGQzUyMTMuPC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7bm90 ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxl Jm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtv ZiZuYnNwO3N1Ym1pc3Npb248L0RJVj4NCjxESVY+dW50aWwmbmJzcDt0aGUmbmJzcDtodG1saXpl ZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5ic3A7YXJlJm5ic3A7YXZhaWxhYmxl Jm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRo ZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDwvRElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9E SVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon557661760760_=====-- From nobody Wed Oct 14 09:23:02 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 27E701ACDB2 for ; Wed, 14 Oct 2015 09:23:00 -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 AC6oBW2kLOUp for ; Wed, 14 Oct 2015 09:22:55 -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 E3BF71ACDB6 for ; Wed, 14 Oct 2015 09:20:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYU79930; Wed, 14 Oct 2015 16:20:01 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Oct 2015 17:20:00 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 14 Oct 2015 09:19:55 -0700 From: John Kaippallimalil To: "dmm@ietf.org" Thread-Topic: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxA Date: Wed, 14 Oct 2015 16:19:54 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 14 Oct 2015 16:23:00 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5dfweml703chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGhhdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIFByZWZpeCBDb3N0IGRy YWZ0IChwbGVhc2Ugc2VlIHN1Ym1pc3Npb24gYmVsb3cpLg0KDQoNCg0KVGhlIGNvbW1lbnRzIGFk ZHJlc3NlZCBpbmNsdWRlIHRoYXQgZnJvbSB0aGUgbGFzdCBtZWV0aW5nLCBhcyB3ZWxsIGFzIGRp c2N1c3Npb25zIG9uIHRoZSByZWZsZWN0b3IgcmVnYXJkaW5nIGhvdyB0aGlzIGNvc3QgY2FuIGJl IHByb3ZpZGVkIHRvIHRoZSBob3N0Og0KDQoxLiBXaGF0IGlzIHRoZSBtb3RpdmF0aW9uIOKAkyB3 aGF0IGNvc3RzIGFyZSBiZWluZyBvcHRpbWl6ZWQNCiAgIFthZGRlZCBlbnRpcmUgY2hhcHRlciBv biBNb3RpdmF0aW9uXQ0KDQoyLiBEb2VzIHRoaXMgcmVxdWlyZSBhZGRpdGlvbmFsIHNpZ25hbGlu Zz8NCiAgIFtObyBhZGRpdGlvbmFsIHNpZ25hbGluZyBpbmN1cnJlZCBpbiB0aGlzIG1lY2hhbmlz bSAtIHN1YiBvcHRpb24gb2YgUkFdDQoNCjMuIERvZXMgdGhpcyBpbXBhY3QgTDIgZXZlbnRzPw0K ICAgW05vdCByZXNwb25kaW5nIHRvIGxpbmsgbGF5ZXIgL0wyIGV2ZW50c10NCg0KNC4gSXMgdGhp cyBhZGRyZXNzaW5nIGUyZSBhc3BlY3RzIG9mIGZsb3csIGV0Yz8NCiAgIFtObyBlMmUgcHJvcG9z ZWQ7IHRoYXQgaXMgZm9yIE1QVENQIGFuZCBvdGhlcnMuXQ0KDQo1LiBXaGF0IGlzIGhvc3QvYXBw bGljYXRpb24gYmVoYXZpb3Igd2hlbiBwcmVmaXggY29zdCBjaGFuZ2VzPw0KICAgVGhlIHVwZGF0 ZXMgcHJvdmlkZSBzb21lIGRldGFpbHMgb24gd2hhdCBjYW4vc2hvdWxkIGJlIGRvbmUgaW4gdGhl IGhvc3QuIEkgdGhpbmsgdGhhdCBkZXRhaWxlZCBtZWNoYW5pc21zIHNob3VsZCBiZQ0KDQogICBh ZGRyZXNzZWQgaW4gYSBjb21wYW5pb24vb3RoZXIgZHJhZnQgcmVsYXRlZCB0byBBUElzLCBldGMu IEJ1dCwgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBvdGhlciB2aWV3cy4NCg0KDQoN CldvdWxkIGFwcHJlY2lhdGUgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQoNCg0KSm9obg0K DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDEzLCAyMDE1IDI6MzcgUE0NClRvOiBKb2huIEthaXBwYWxsaW1hbGlsOyBQ ZXRlciBNY0Nhbm47IFBldGVyIE1jQ2Fubg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1tY2Nhbm4tZG1tLXByZWZpeGNvc3QtMDIudHh0DQoNCg0KDQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29zdC0wMi50eHQNCg0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIEthaXBwYWxsaW1hbGlsIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgIGRyYWZ0 LW1jY2Fubi1kbW0tcHJlZml4Y29zdA0KDQpSZXZpc2lvbjogICAwMg0KDQpUaXRsZTogICAgICAg ICAgICBDb21tdW5pY2F0aW5nIFByZWZpeCBDb3N0IHRvIE1vYmlsZSBOb2Rlcw0KDQpEb2N1bWVu dCBkYXRlOiAgICAyMDE1LTEwLTEzDQoNCkdyb3VwOiAgICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KDQpQYWdlczogICAgICAgICAgICA5DQoNClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWNjYW5uLWRtbS1wcmVmaXhjb3N0 LTAyLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWNjYW5uLWRtbS1wcmVmaXhjb3N0Lw0KDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29zdC0wMg0KDQpE aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1j Y2Fubi1kbW0tcHJlZml4Y29zdC0wMg0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIEluIGEgbmV0d29y ayBpbXBsZW1lbnRpbmcgRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCwgaXQgaGFzDQoN CiAgIGJlZW4gYWdyZWVkIHRoYXQgTW9iaWxlIE5vZGVzIChNTnMpIHNob3VsZCBleGhpYml0IGFn aWxpdHkgaW4gdGhlaXINCg0KICAgdXNlIG9mIElQIGFkZHJlc3Nlcy4gIEZvciBleGFtcGxlLCBh biBNTiBtaWdodCB1c2UgYW4gb2xkIGFkZHJlc3MgZm9yDQoNCiAgIG9uZ29pbmcgc29ja2V0IGNv bm5lY3Rpb25zIGJ1dCB1c2UgYSBuZXcsIGxvY2FsbHkgYXNzaWduZWQgYWRkcmVzcw0KDQogICBm b3IgbmV3IHNvY2tldCBjb25uZWN0aW9ucy4gIERldGVybWluaW5nIHdoZW4gdG8gYXNzaWduIGEg bmV3DQoNCiAgIGFkZHJlc3MsIGFuZCB3aGVuIHRvIHJlbGVhc2Ugb2xkIGFkZHJlc3NlcywgaXMg Y3VycmVudGx5IGFuIG9wZW4NCg0KICAgcHJvYmxlbS4gIE1ha2luZyBhbiBvcHRpbWFsIGRlY2lz aW9uIGFib3V0IGFkZHJlc3MgYXNzaWdubWVudCBhbmQNCg0KICAgcmVsZWFzZSBtdXN0IGludm9s dmUgYSB0cmFkZW9mZiBpbiB0aGUgYW1vdW50IG9mIHNpZ25hbGluZyB1c2VkIHRvDQoNCiAgIGFs bG9jYXRlIHRoZSBuZXcgYWRkcmVzc2VzLCB0aGUgYW1vdW50IG9mIHV0aWxpdHkgdGhhdCBhcHBs aWNhdGlvbnMNCg0KICAgYXJlIGRlcml2aW5nIGZyb20gdGhlIHVzZSBvZiBhIHByZXZpb3VzbHkg YXNzaWduZWQgYWRkcmVzcywgYW5kIHRoZQ0KDQogICBjb3N0IG9mIG1haW50YWluaW5nIGFuIGFk ZHJlc3MgdGhhdCB3YXMgYXNzaWduZWQgYXQgYSBwcmV2aW91cyBwb2ludA0KDQogICBvZiBhdHRh Y2htZW50LiAgQXMgdGhlIE1OIG1vdmVzIGZhcnRoZXIgYW5kIGZhcnRoZXIgZnJvbSB0aGUgaW5p dGlhbA0KDQogICBwb2ludCB3aGVyZSBhbiBhZGRyZXNzIHdhcyBhc3NpZ25lZCwgbW9yZSBhbmQg bW9yZSByZXNvdXJjZXMgYXJlIHVzZWQNCg0KICAgdG8gcmVkaXJlY3QgcGFja2V0cyBkZXN0aW5l ZCBmb3IgdGhhdCBJUCBhZGRyZXNzIHRvIGl0cyBjdXJyZW50DQoNCiAgIGxvY2F0aW9uLiAgVGhl IE1OIGN1cnJlbnRseSBkb2VzIG5vdCBrbm93IHRoZSBhbW91bnQgb2YgcmVzb3VyY2VzDQoNCiAg IHVzZWQgYXMgdGhpcyBkZXBlbmRzIG9uIG1vYmlsaXR5IHBhdGggYW5kIGludGVybmFsIHJvdXRp bmcgdG9wb2xvZ3kNCg0KICAgb2YgdGhlIG5ldHdvcmsocykgd2hpY2ggYXJlIGtub3duIG9ubHkg dG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IuICBUaGlzDQoNCiAgIGRvY3VtZW50IHByb3ZpZGVzIGEg bWVjaGFuaXNtIHRvIGNvbW11bmljYXRlIHRvIHRoZSBNTiB0aGUgY29zdCBvZg0KDQogICBtYWlu dGFpbmluZyBhIGdpdmVuIHByZWZpeCBhdCB0aGUgTU4ncyBjdXJyZW50IHBvaW50IG9mIGF0dGFj aG1lbnQgc28NCg0KICAgdGhhdCB0aGUgTU4gY2FuIG1ha2UgYmV0dGVyIGRlY2lzaW9ucyBhYm91 dCB3aGVuIHRvIHJlbGVhc2Ugb2xkDQoNCiAgIGFkZHJlc3NlcyBhbmQgYXNzaWduIG5ldyBvbmVz Lg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5dfweml703chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29Q bGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2UgaGF2ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgUHJlZml4IENvc3QgZHJhZnQgKHBsZWFzZSBzZWUgc3VibWlzc2lvbiBiZWxvdykuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBjb21tZW50cyBhZGRyZXNzZWQgaW5jbHVkZSB0 aGF0IGZyb20gdGhlIGxhc3QgbWVldGluZywgYXMgd2VsbCBhcyBkaXNjdXNzaW9ucyBvbiB0aGUg cmVmbGVjdG9yIHJlZ2FyZGluZyBob3cgdGhpcyBjb3N0IGNhbiBiZSBwcm92aWRlZCB0byB0aGUg aG9zdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjEuIFdoYXQgaXMg dGhlIG1vdGl2YXRpb24g4oCTIHdoYXQgY29zdHMgYXJlIGJlaW5nIG9wdGltaXplZDxicj4NCiZu YnNwOyZuYnNwOyBbYWRkZWQgZW50aXJlIGNoYXB0ZXIgb24gTW90aXZhdGlvbl08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjIuIERvZXMgdGhpcyByZXF1aXJlIGFkZGl0 aW9uYWwgc2lnbmFsaW5nPzxicj4NCiZuYnNwOyZuYnNwOyBbTm8gYWRkaXRpb25hbCBzaWduYWxp bmcgaW5jdXJyZWQgaW4gdGhpcyBtZWNoYW5pc20gLSBzdWIgb3B0aW9uIG9mIFJBXTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My4gRG9lcyB0aGlzIGltcGFjdCBMMiBl dmVudHM/PGJyPg0KJm5ic3A7Jm5ic3A7IFtOb3QgcmVzcG9uZGluZyB0byBsaW5rIGxheWVyIC9M MiBldmVudHNdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij40LiBJcyB0 aGlzIGFkZHJlc3NpbmcgZTJlIGFzcGVjdHMgb2YgZmxvdywgZXRjPzxicj4NCiZuYnNwOyZuYnNw OyBbTm8gZTJlIHByb3Bvc2VkOyB0aGF0IGlzIGZvciBNUFRDUCBhbmQgb3RoZXJzLl08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjUuIFdoYXQgaXMgaG9zdC9hcHBsaWNh dGlvbiBiZWhhdmlvciB3aGVuIHByZWZpeCBjb3N0IGNoYW5nZXM/PGJyPg0KJm5ic3A7Jm5ic3A7 IFRoZSB1cGRhdGVzIHByb3ZpZGUgc29tZSBkZXRhaWxzIG9uIHdoYXQgY2FuL3Nob3VsZCBiZSBk b25lIGluIHRoZSBob3N0LiBJIHRoaW5rIHRoYXQgZGV0YWlsZWQgbWVjaGFuaXNtcyBzaG91bGQg YmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7YWRkcmVzc2VkIGluIGEgY29tcGFuaW9uL290aGVyIGRyYWZ0IHJlbGF0ZWQgdG8gQVBJ cywgZXRjLiBCdXQsIGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGhlYXIgb3RoZXIgdmlld3Mu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldvdWxkIGFwcHJlY2lhdGUgY29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2huPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gPGJyPg0KU2VudDogVHVlc2Rh eSwgT2N0b2JlciAxMywgMjAxNSAyOjM3IFBNPGJyPg0KVG86IEpvaG4gS2FpcHBhbGxpbWFsaWw7 IFBldGVyIE1jQ2FubjsgUGV0ZXIgTWNDYW5uPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1tY2Nhbm4tZG1tLXByZWZpeGNvc3QtMDIudHh0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1jY2Fubi1kbW0tcHJlZml4 Y29zdC0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBLYWlwcGFsbGltYWxpbCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LW1jY2Fubi1k bW0tcHJlZml4Y29zdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2 aXNpb246Jm5ic3A7Jm5ic3A7IDAyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29tbXVuaWNhdGluZyBQcmVmaXggQ29zdCB0byBNb2JpbGUg Tm9kZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRvY3VtZW50IGRh dGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMTUtMTAtMTM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBhZ2VzOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tY2Nhbm4tZG1t LXByZWZpeGNvc3QtMDIudHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbWNjYW5uLWRtbS1wcmVmaXhjb3N0LTAyLnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29zdC8iPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29zdC88L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tY2Nhbm4tZG1tLXByZWZpeGNvc3QtMDIiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tY2Nhbm4tZG1tLXByZWZpeGNvc3QtMDI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29zdC0wMiI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1jY2Fubi1kbW0tcHJlZml4Y29z dC0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0Ojxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEluIGEg bmV0d29yayBpbXBsZW1lbnRpbmcgRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCwgaXQg aGFzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg YmVlbiBhZ3JlZWQgdGhhdCBNb2JpbGUgTm9kZXMgKE1Ocykgc2hvdWxkIGV4aGliaXQgYWdpbGl0 eSBpbiB0aGVpcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IHVzZSBvZiBJUCBhZGRyZXNzZXMuJm5ic3A7IEZvciBleGFtcGxlLCBhbiBNTiBtaWdo dCB1c2UgYW4gb2xkIGFkZHJlc3MgZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgb25nb2luZyBzb2NrZXQgY29ubmVjdGlvbnMgYnV0IHVzZSBh IG5ldywgbG9jYWxseSBhc3NpZ25lZCBhZGRyZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZm9yIG5ldyBzb2NrZXQgY29ubmVjdGlvbnMuJm5i c3A7IERldGVybWluaW5nIHdoZW4gdG8gYXNzaWduIGEgbmV3PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcywgYW5kIHdoZW4gdG8gcmVs ZWFzZSBvbGQgYWRkcmVzc2VzLCBpcyBjdXJyZW50bHkgYW4gb3BlbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHByb2JsZW0uJm5ic3A7IE1ha2lu ZyBhbiBvcHRpbWFsIGRlY2lzaW9uIGFib3V0IGFkZHJlc3MgYXNzaWdubWVudCBhbmQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZWxlYXNlIG11 c3QgaW52b2x2ZSBhIHRyYWRlb2ZmIGluIHRoZSBhbW91bnQgb2Ygc2lnbmFsaW5nIHVzZWQgdG88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbGxv Y2F0ZSB0aGUgbmV3IGFkZHJlc3NlcywgdGhlIGFtb3VudCBvZiB1dGlsaXR5IHRoYXQgYXBwbGlj YXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgYXJlIGRlcml2aW5nIGZyb20gdGhlIHVzZSBvZiBhIHByZXZpb3VzbHkgYXNzaWduZWQgYWRk cmVzcywgYW5kIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IGNvc3Qgb2YgbWFpbnRhaW5pbmcgYW4gYWRkcmVzcyB0aGF0IHdhcyBhc3NpZ25l ZCBhdCBhIHByZXZpb3VzIHBvaW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgb2YgYXR0YWNobWVudC4mbmJzcDsgQXMgdGhlIE1OIG1vdmVzIGZh cnRoZXIgYW5kIGZhcnRoZXIgZnJvbSB0aGUgaW5pdGlhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHBvaW50IHdoZXJlIGFuIGFkZHJlc3Mgd2Fz IGFzc2lnbmVkLCBtb3JlIGFuZCBtb3JlIHJlc291cmNlcyBhcmUgdXNlZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRvIHJlZGlyZWN0IHBhY2tl dHMgZGVzdGluZWQgZm9yIHRoYXQgSVAgYWRkcmVzcyB0byBpdHMgY3VycmVudDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGxvY2F0aW9uLiZuYnNw OyBUaGUgTU4gY3VycmVudGx5IGRvZXMgbm90IGtub3cgdGhlIGFtb3VudCBvZiByZXNvdXJjZXM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB1c2Vk IGFzIHRoaXMgZGVwZW5kcyBvbiBtb2JpbGl0eSBwYXRoIGFuZCBpbnRlcm5hbCByb3V0aW5nIHRv cG9sb2d5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgb2YgdGhlIG5ldHdvcmsocykgd2hpY2ggYXJlIGtub3duIG9ubHkgdG8gdGhlIG5ldHdvcmsg b3BlcmF0b3IuJm5ic3A7IFRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBkb2N1bWVudCBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBjb21tdW5p Y2F0ZSB0byB0aGUgTU4gdGhlIGNvc3Qgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBtYWludGFpbmluZyBhIGdpdmVuIHByZWZpeCBhdCB0aGUg TU4ncyBjdXJyZW50IHBvaW50IG9mIGF0dGFjaG1lbnQgc288bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0aGF0IHRoZSBNTiBjYW4gbWFrZSBiZXR0 ZXIgZGVjaXNpb25zIGFib3V0IHdoZW4gdG8gcmVsZWFzZSBvbGQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhZGRyZXNzZXMgYW5kIGFzc2lnbiBu ZXcgb25lcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBJRVRGIFNlY3JldGFy aWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5dfweml703chm_-- From nobody Wed Oct 14 10:38: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 1055F1ACF24 for ; Wed, 14 Oct 2015 10:38:07 -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 cLoISwWzjYDB for ; Wed, 14 Oct 2015 10:38:02 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369FD1ACD81 for ; Wed, 14 Oct 2015 10:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17324; q=dns/txt; s=iport; t=1444844282; x=1446053882; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C9nSmg0s2xk+87ZSaw+S6VSbMNYGpNP1UdLgf/feXhk=; b=eLVl/EX1v8t5BYU+lmcpBDZjoKXgOYpvYJXtAsu5fyGXuEi8h+ULGgTG Y7JQ8V92bu85AgfrNdqthN15lAYGoWbNEi8pJODZthsWD4pwAVazXooGI SbyGplmrcdlfiFwAeDFAkd0JDheP/Sv59TtnC+ZEhiAKYwjo8XECFo0I0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhAgDIkh5W/5tdJa1egllNVG4GvRQBDYFaIYJyggp/AoFIOBQBAQEBAQEBgQqEJgEBAQQtSg4EAgEIEQMBAQEoBzIUCAEIAgQBEoguDcM0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Z2hH6EYgcTDQsGhCgFjQ45hQ6DQAGFGIgCgVhIg3KVdwEfAQFChAJxAYVogQYBAQE X-IronPort-AV: E=Sophos;i="5.17,682,1437436800"; d="scan'208,217";a="198123025" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2015 17:37:45 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9EHbjTi011563 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 17:37:45 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 12:37:31 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 12:37:31 -0500 From: "Sri Gundavelli (sgundave)" To: John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBqcA5R+fbIizSEuT1Rk1eEgRCA== Date: Wed, 14 Oct 2015 17:37:31 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_D243DFE21E9A71sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 14 Oct 2015 17:38:07 -0000 --_000_D243DFE21E9A71sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D243DFE21E9A71sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <34CF785D71409F4DA743259D2AAC85A3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
John:

How would the AR know the cost of a prefix ? Assuming the AR is taking= the role of a access gateway and the projected prefix is from a remote gat= eway, how would it put a cost ? Our earlier discussions, we always talked a= bout presenting capabilities of a prefix and not some arbitrary cost metric; those capabilities in the for= m of attributes allow the MN to pick up a right prefix. So, I’m not s= ure how the AR computes this cost and how the end points make use of this v= alue.


Sri




From: dmm <dmm-bounces@ietf.org> on behalf of John Kaippalli= malil <John.Kaippallim= alil@huawei.com>
Date: Wednesday, October 14, 2015 a= t 9:19 AM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] FW: New Version Noti= fication for draft-mccann-dmm-prefixcost-02.txt

Hi,

We have posted a new version of the Prefix Cost d= raft (please see submission below).

 

The comments addressed include that from the last= meeting, as well as discussions on the reflector regarding how this cost c= an be provided to the host:

1. What is the motivation – what costs are = being optimized
   [added entire chapter on Motivation]

2. Does this require additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing e2e aspects of flow, etc?    [No e2e proposed; that is for MPTCP and others.]

5. What is host/application behavior when prefix = cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   addressed in a companion/other = draft related to APIs, etc. But, it would be interesting to hear other view= s.

 

Would appreciate comments and suggestions.

 

John

 

 

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D, draft-mccann-dmm-prefixcost= -02.txt

has been successfully submitted by John Kaippalli= malil and posted to the IETF repository.

 

Name:       draft-m= ccann-dmm-prefixcost

Revision:   02

Title:       &= nbsp;    Communicating Prefix Cost to Mobile Nodes

Document date:    2015-10-13<= /o:p>

Group:       &= nbsp;    Individual Submission

Pages:       &= nbsp;    9

URL:       &nb= sp;    https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:       =   https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:       https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:       &n= bsp;   https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02

 

Abstract:

   In a network implementing Distribute= d Mobility Management, it has

   been agreed that Mobile Nodes (MNs) = should exhibit agility in their

   use of IP addresses.  For examp= le, an MN might use an old address for

   ongoing socket connections but use a= new, locally assigned address

   for new socket connections.  De= termining when to assign a new

   address, and when to release old add= resses, is currently an open

   problem.  Making an optimal dec= ision about address assignment and

   release must involve a tradeoff in t= he amount of signaling used to

   allocate the new addresses, the amou= nt of utility that applications

   are deriving from the use of a previ= ously assigned address, and the

   cost of maintaining an address that = was assigned at a previous point

   of attachment.  As the MN moves= farther and farther from the initial

   point where an address was assigned,= more and more resources are used

   to redirect packets destined for tha= t IP address to its current

   location.  The MN currently doe= s not know the amount of resources

   used as this depends on mobility pat= h and internal routing topology

   of the network(s) which are known on= ly to the network operator.  This

   document provides a mechanism to com= municate to the MN the cost of

   maintaining a given prefix at the MN= 's current point of attachment so

   that the MN can make better decision= s about when to release old

   addresses and assign new ones.<= /o:p>

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

 

 

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

 

The IETF Secretariat

 

--_000_D243DFE21E9A71sgundaveciscocom_-- From nobody Wed Oct 14 11:51:19 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 BDD101A0204 for ; Wed, 14 Oct 2015 11:51:18 -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 q7gxuMSpJAvT for ; Wed, 14 Oct 2015 11:51:13 -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 ACD4C1B29A6 for ; Wed, 14 Oct 2015 11:51:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYU89356; Wed, 14 Oct 2015 18:51:10 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Oct 2015 19:51:08 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 14 Oct 2015 11:50:56 -0700 From: John Kaippallimalil To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EA== Date: Wed, 14 Oct 2015 18:50:55 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE33dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 14 Oct 2015 18:51:19 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE33dfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE33dfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John=

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

John:

&n= bsp;

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

&n= bsp;

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE33dfweml703chm_-- From nobody Wed Oct 14 12:10:24 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 0EF191A1A3C for ; Wed, 14 Oct 2015 12:10:23 -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 jxTiT3bw64Up for ; Wed, 14 Oct 2015 12:10:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44A11A8831 for ; Wed, 14 Oct 2015 12:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28480; q=dns/txt; s=iport; t=1444849819; x=1446059419; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5eaM3xtqbEfniEC7W+HgrYFSrdFUu8cDk/5NK9ICjQI=; b=DYZVbTIrVmnfcvf5M8uWzwhbo9/Sav6Hv8sPUttEJWhp4EuMJD6MV/ly Dj5BYS1t10Jj8VztOsy+Le089IxajIn/T/D3H+slWcf8PbcHfLu3/RqdZ ANzMYqZA+txTSl7fkkPl9Y2avHR485fXvEH3hGsl+hich+rmRWFhU02EZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiAgBQqB5W/4oNJK1egllNVG4GvRoBDYFaIYJyggp/AoFLOBQBAQEBAQEBgQqEJgEBAQQtRAYOBAIBCBEBAgEBASEHBzIUAwUBCAIEARKILg3DSQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGdoR+hGIHEw0KAQIEhCgFjQ6FR4NAAYUYiAKBWEiDcpIJg24BHwEBQoQCcQGFaIEGAQEB X-IronPort-AV: E=Sophos; i="5.17,682,1437436800"; d="scan'208,217"; a="35726423" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 14 Oct 2015 19:10:18 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9EJAIAI013850 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 19:10:18 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 14:10:04 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 14:10:04 -0500 From: "Sri Gundavelli (sgundave)" To: John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBrPuZwJ+z7HxrEWUOOVOzbXvEg== Date: Wed, 14 Oct 2015 19:10:03 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_D243F3A21E9B16sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 14 Oct 2015 19:10:23 -0000 --_000_D243F3A21E9B16sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D243F3A21E9B16sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4354A1C1E828F0418619EE0A2BA289B3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for your response. Certainly, operators can define their own de= finitions for the cost metric, but it will still break the end point intero= perability. If the industry approach is BYOD, how would you make different = devices from roaming partners interpret this cost metric that they receive from the attached common access network= ? AR needs provisioning interface to the end point and it needs policy int= erface to the respective home networks. Assuming those interface exists, st= ill how would a AR ever provide a cost metric for two different prefixes from two remote gateways. Its the= same backhaul and the conditions/traffic patters are always changing ? &nb= sp;

If we rather acknowledge that metric definition is difficult to specif= y, instead we focus on capability indications.  We spent few years in = IETF discussing this topic of prefix coloring and may the approach is color= ing is what we should look at.

Regards
Sri




From: John Kaippallimalil <John.Kaippallimalil@huawei.com= >
Date: Wednesday, October 14, 2015 a= t 11:50 AM
To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John=

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

John:

&n= bsp;

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

&n= bsp;

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D243F3A21E9B16sgundaveciscocom_-- From nobody Wed Oct 14 13:07: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 9BB461A6F2E for ; Wed, 14 Oct 2015 13:07:36 -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 LC8wC6638s2o for ; Wed, 14 Oct 2015 13:07:29 -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 46C871A6F2B for ; Wed, 14 Oct 2015 13:07:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYU93089; Wed, 14 Oct 2015 20:07:26 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Oct 2015 21:07:25 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 14 Oct 2015 13:07:14 -0700 From: John Kaippallimalil To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4A= Date: Wed, 14 Oct 2015 20:07:14 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE9Adfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 14 Oct 2015 20:07:36 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE9Adfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE9Adfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John=

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Hi John= ,

&n= bsp;

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

&n= bsp;

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= o:p>

&n= bsp;

Regards=

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB1DE9Adfweml703chm_-- From nobody Mon Oct 19 02:14:55 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 882791A8795 for ; Mon, 19 Oct 2015 02:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njdk9ggehTcQ for ; Mon, 19 Oct 2015 02:14:52 -0700 (PDT) Received: from SNT004-OMC2S40.hotmail.com (snt004-omc2s40.hotmail.com [65.54.61.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44C11A8792 for ; Mon, 19 Oct 2015 02:14:51 -0700 (PDT) Received: from SNT146-DS17 ([65.55.90.71]) by SNT004-OMC2S40.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 19 Oct 2015 02:14:50 -0700 X-TMN: [OcoaKgVfI+PGRRYf/PpKVzA4wSYglcmZREMZ06wQgmk=] X-Originating-Email: [fuqiao1@outlook.com] Message-ID: From: Fu Qiao To: Date: Mon, 19 Oct 2015 17:14:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEKTfnKhJ+e9mSISR+XR11A48B+YwAAGyjg Content-Language: zh-cn X-OriginalArrivalTime: 19 Oct 2015 09:14:50.0722 (UTC) FILETIME=[9BBFCC20:01D10A4E] Archived-At: Subject: [DMM] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-fu-dmm-vcpe-models-01=2Etxt?= 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, 19 Oct 2015 09:14:53 -0000 Hi, all. I have updated the VCPE draft according to our discussion on = the last IETF. I have modify the scenario section to mainly focus on the = community WiFi scenario. I also update with some detail discussion of = FPC protocol in the VCPE deployment. Your comments and suggestion are more than welcome! Thank you! -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2015=E5=B9=B410=E6=9C=8819=E6=97=A5 17:10 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qiao Fu; DENG Hui; Qiao Fu; Hui Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-fu-dmm-vcpe-models-01.txt A new version of I-D, draft-fu-dmm-vcpe-models-01.txt has been successfully submitted by Qiao Fu and posted to the IETF repository. Name: draft-fu-dmm-vcpe-models Revision: 01 Title: Motivations, usecases and Models of VCPE Document date: 2015-10-19 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-fu-dmm-vcpe-models-01.txt Status: = https://datatracker.ietf.org/doc/draft-fu-dmm-vcpe-models/ Htmlized: https://tools.ietf.org/html/draft-fu-dmm-vcpe-models-01 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fu-dmm-vcpe-models-01 Abstract: This document introduces the concept of Virtual Customer Premises Equipment (VCPE). Such concept was first proposed in Broadband Forum (BBF) as Network Enhanced Residential Gateway (NERG). The concept is further expanded as not only referring to virtual CPE of residential network, but all the virtual network and service functions shifted from the customer side to the operator side. Deployment of VCPE in some typical DMM (Distributed Mobility Management) scenarios brings specific requirements and even protocol extension in DMM. In this document, we will first explain the motivation and advantages of VCPE. A usecases of VCPE in the community Wi-Fi deployment is further discussed so as to explain the deployment of VCPE in a DMM scenario. Three models of field deployment of VCPE are discussed afterwards to indicate the possible CP/DP decomposition requirement and protocol extension. = =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 Mon Oct 19 04:56:58 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 D98BE1A8FD4 for ; Mon, 19 Oct 2015 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 gKtobELVUVto for ; Mon, 19 Oct 2015 04:56:56 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC9F1A9022 for ; Mon, 19 Oct 2015 04:56:55 -0700 (PDT) Received: from [193.136.93.106] (account seiljeon@av.it.pt HELO reserva02) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 78437520 for dmm@ietf.org; Mon, 19 Oct 2015 12:56:53 +0100 From: "Seil Jeon" To: References: <20151019115145.27391.18482.idtracker@ietfa.amsl.com> In-Reply-To: <20151019115145.27391.18482.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:56:56 +0100 Message-ID: <006501d10a65$40d46110$c27d2330$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFEZ8ThVaok2mXSOEKscdwQiciepZ+L+jdw Content-Language: en-us Archived-At: Subject: [DMM] FW: New Version Notification for draft-sijeon-dmm-use-cases-api-source-02.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: Mon, 19 Oct 2015 11:56:58 -0000 Hi All, We just have posted following draft. Your comments are always welcome, as we have continuously discussed in = the list. Regards, Seil Jeon -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 19, 2015 12:52 PM To: John Kaippallimalil ; John = Kaippallimalil ; 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-02.txt A new version of I-D, draft-sijeon-dmm-use-cases-api-source-02.txt has been successfully submitted by Seil Jeon and posted to the IETF = repository. Name: draft-sijeon-dmm-use-cases-api-source Revision: 02 Title: Use Cases and API Extension for Source IP Address Selection Document date: 2015-10-19 Group: Individual Submission Pages: 7 URL: = https://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-sourc= e-02.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-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sijeon-dmm-use-cases-api-source= -02 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 Mon Oct 19 07:41: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 7FF0A1A914D for ; Mon, 19 Oct 2015 07:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 2Jvr5cvwJ9nP for ; Mon, 19 Oct 2015 07:41:19 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 90BB61A89B3 for ; Mon, 19 Oct 2015 07:41:18 -0700 (PDT) Received: from [193.136.93.106] (account seiljeon@av.it.pt HELO reserva02) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 78438651 for dmm@ietf.org; Mon, 19 Oct 2015 15:41:17 +0100 From: "Seil Jeon" To: References: <20151019124637.1046.37301.idtracker@ietfa.amsl.com> In-Reply-To: <20151019124637.1046.37301.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:41:19 +0100 Message-ID: <00ef01d10a7c$37cd02e0$a76708a0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJgUbt65anJyUQzx4tR+I8XLbWMm51UVIBw Content-Language: en-us Archived-At: Subject: [DMM] FW: New Version Notification for draft-sijeon-dmm-deployment-models-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: Mon, 19 Oct 2015 14:41:20 -0000 Hi All, I have posted the updated version of the deployment models draft, which = was presented in Prague meeting. The comments received during the = meeting were addressed in the updated version. Hope to get your comments. Regards, Seil Jeon -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 19, 2015 1:47 PM To: Seil Jeon ; Younghan Kim ; = Seil Jeon ; Young-Han Kim Subject: New Version Notification for = draft-sijeon-dmm-deployment-models-01.txt A new version of I-D, draft-sijeon-dmm-deployment-models-01.txt has been successfully submitted by Seil Jeon and posted to the IETF = repository. Name: draft-sijeon-dmm-deployment-models Revision: 01 Title: Deployment Models for Distributed Mobility Management Document date: 2015-10-19 Group: Individual Submission Pages: 8 URL: = https://www.ietf.org/internet-drafts/draft-sijeon-dmm-deployment-models-0= 1.txt Status: = https://datatracker.ietf.org/doc/draft-sijeon-dmm-deployment-models/ Htmlized: = https://tools.ietf.org/html/draft-sijeon-dmm-deployment-models-01 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sijeon-dmm-deployment-models-01= Abstract: This document presents available deployment models for distributed mobility management networks, consisted of mobility management functions: anchoring function, location management, and forwarding management functions defined in RFC7429. Some of the functions are modified on a need to allow potential deployment scenarios support. = =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 Mon Oct 19 13:21:56 2015 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48B1A9248; Mon, 19 Oct 2015 13:21:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019202134.18863.90218.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:21:34 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-4283mnids-01.txt 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: Mon, 19 Oct 2015 20:21:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : MN Identifier Types for RFC 4283 Mobile Node Identifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-01.txt Pages : 8 Date : 2015-10-19 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 13:40:02 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 99EED1ACC89 for ; Mon, 19 Oct 2015 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 UCm4txgK7Aeg for ; Mon, 19 Oct 2015 13:39:46 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 388731ACC85 for ; Mon, 19 Oct 2015 13:39:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=F43H3LusQTF4dqDNZlyLheWlHDSRlnMTJdfAbaSfq/d+qdvWCfa+adGo7XDIOxWS; h=Received:Subject:References:To:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.56] (helo=[192.168.1.68]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ZoHDJ-00017O-Fv for dmm@ietf.org; Mon, 19 Oct 2015 16:39:25 -0400 References: <20151019202134.18863.90218.idtracker@ietfa.amsl.com> To: dmm@ietf.org From: Charlie Perkins Message-ID: <562554FB.3040600@earthlink.net> Date: Mon, 19 Oct 2015 13:39:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019202134.18863.90218.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac76c48e0fda96949fc341457e899d936d5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.56 Archived-At: Subject: Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-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: Mon, 19 Oct 2015 20:39:48 -0000 Hello folks, The updated MNIDs draft has been posted. I've incorporated potential resolutions for the recent comments, especially from Sri. I did not make subsections for each type of MNID, because I am hoping that won't be considered necessary. I hope to get some more discussion about it from folks on this mailing list. Or, if I get a sample text for one of the MNIDs, I can attempt to create similar text for the other MNIDs. Notably, doing so would make the short draft about 5 times longer. Regards, Charlie P. On 10/19/2015 1:21 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Distributed Mobility Management Working Group of the IETF. > > Title : MN Identifier Types for RFC 4283 Mobile Node Identifier Option > Authors : Charles E. Perkins > Vijay Devarapalli > Filename : draft-ietf-dmm-4283mnids-01.txt > Pages : 8 > Date : 2015-10-19 > > Abstract: > Additional Identifier Types are proposed for use with the Mobile Node > Identifier Option for MIPv6 (RFC 4283). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Oct 21 13:54: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 842571B3035 for ; Wed, 21 Oct 2015 13:54:49 -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 Tz0zGpCirQ6a for ; Wed, 21 Oct 2015 13:54:47 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B371B3034 for ; Wed, 21 Oct 2015 13:54:46 -0700 (PDT) Received: by lfaz124 with SMTP id z124so27013770lfa.1 for ; Wed, 21 Oct 2015 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZoiqUj3Okix6wSDsBoar7BWFMdQbdCVPOwcO0QuaFho=; b=tJok/HauUJHfPdEYQcOw28016k0IsZ3+MXBAluWqh/r7MN+Ib09kHFgjE1SQUzTfFh 5NbfDiOOkIyynXp85riMPrVz/7fOxRR3JKJ4+Rj4ldQXcmwfySRzfUVN17h2FQ9seS4f MkqMki4yU1ecBdaihXu88jyqKIWMdyVxCcLJoUqp2IhLOvFbiNzMv3xR7FqRkGMVcV8o onjvfOtJyIpG1U8rO7jLEe4eNY0p4OxgIOdBF7qlzW/iE5KtCfacvuyElBDLJ+hOjZyM PNCHjfrixWebT3XClgpSghBzPueWL9xlitK78jvRsIvRuj1xrX99OKwddxISe9GsHIx5 Hcrw== MIME-Version: 1.0 X-Received: by 10.25.80.77 with SMTP id e74mr4200351lfb.11.1445460884706; Wed, 21 Oct 2015 13:54:44 -0700 (PDT) Received: by 10.25.86.21 with HTTP; Wed, 21 Oct 2015 13:54:44 -0700 (PDT) In-Reply-To: <201510130944230363409@cnnic.cn> References: <201510130944230363409@cnnic.cn> Date: Wed, 21 Oct 2015 13:54:44 -0700 Message-ID: From: jouni korhonen To: "Z.W. Yan" Content-Type: multipart/alternative; boundary=001a114066d291e7c80522a396dc Archived-At: Cc: Jong-Hyouk Lee , dmm , xl Subject: Re: [DMM] Fw: New Version Notification for draft-yan-dmm-hnprenum-03.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, 21 Oct 2015 20:54:49 -0000 --001a114066d291e7c80522a396dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Checked the diffs and IDNits. Make always sure to comply with IDNits as it is so easy & cheap tool to use. - Jouni -------------------------------> ** The document seems to lack an IANA Considerations section. (See Secti= on 2.2 of http://www.ietf.org/id-info/checklist for how to handle the cas= e when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to have = RFC 2119 boilerplate text. -- The document date (October 11, 2015) is 10 days in the past. Is this intentional? Checking references for intended status: Proposed Standard -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Experimental RFC: RFC 6058 ** Downref: Normative reference to an Informational RFC: RFC 6879 Summary: 5 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (-= -). Run idnits with the --verbose option for more detailed information abo= ut the items above. On Mon, Oct 12, 2015 at 6:44 PM, Z.W. Yan wrote: > Dear All, > We just revised the HNP-renumbering draft based on the comments online an= d > offline and posted to the DMM WG. > Any further comments from you are always welcome. > > Besides, Jouni and Dapeng, > Would you please assign me 5-10 minutes to re-introduce this draft in the > DMM meeting? > > BR, > > > 2015-10-13 > ------------------------------ > Z.W. Yan > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* internet-drafts > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A* 2015-10-12 14:33:04 > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* Zhiwei Yan; XiaoDong Lee; Xiaodong= Lee; Jong-Hyouk Lee > *=E6=8A=84=E9=80=81=EF=BC=9A* > *=E4=B8=BB=E9=A2=98=EF=BC=9A* New Version Notification for draft-yan-dmm-= hnprenum-03.txt > > A new version of I-D, draft-yan-dmm-hnprenum-03.txt > has been successfully submitted by Zhiwei Yan and posted to the > IETF repository. > Name: draft-yan-dmm-hnprenum > Revision: 03 > Title: Home Network Prefix Renumbering in PMIPv6 > Document date: 2015-10-11 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-yan-dmm-hnprenum-03.txt > Status: https://datatracker.ietf.org/doc/draft-yan-dmm-hnprenum/ > Htmlized: https://tools.ietf.org/html/draft-yan-dmm-hnprenum-03 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-yan-dmm-hnprenum-03 > Abstract: > In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node > (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its > initial attachment for the Home Address (HoA) configuration. During > the movement of the MN, this prefix remains unchanged and in this way > it is unnecessary for the MN to reconfigure its HoA and reconnect the > ongoing communications. However, the current protocol (RFC5213) does > not specify related operations to support the MN to timely receive > and use a new HNP when the allocated HNP changes. In this draft, a > solution to support the HNP renumbering is proposed, as an update of > RFC5213. > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat > --001a114066d291e7c80522a396dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Checked the diffs and IDNits. Make always su= re to comply with IDNits as it is so easy & cheap tool to use.

- Jouni

------------------------------->
  ** The d=
ocument seems to lack an IANA Considerations section.  (See Section
     2.2 of http://www.ie=
tf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.


  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

  =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to h=
ave RFC
     2119 boilerplate text.

  -- The document date (October 11, 2015) is 10 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  -------------------------------------------------------------------------=
---

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861)

  ** Downref: Normative reference to an Experimental RFC: RFC 6058

  ** Downref: Normative reference to an Informational RFC: RFC 6879


     Summary: 5 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (-=
-).

     Run idnits with the --verbose option for more detailed information abo=
ut
     the items above.


On Mon, Oct 12, 2015 at 6:44 PM, Z.W. Yan <yan@cnnic.cn>= ; wrote:
Dear All,
We just revised the HNP-renumbering draft based on the comments online= and=20 offline and posted to the DMM WG.
Any further comments from you are always welcome.
=C2=A0
Besides, Jouni and Dapeng,
Would you please assign me 5-10 minutes to re-introduce this draft in = the=20 DMM meeting?
=C2=A0
BR,
=C2=A0
=C2=A0
2015-10-13<= /div>
Z.W. Yan
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A=20 internet-drafts
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4=EF=BC=9A=20 2015-10-12=C2=A014:33:04
=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A Zhiwei Yan; XiaoDong Lee;=20 Xiaodong Lee; Jong-Hyouk Lee
=E6=8A=84=E9=80=81=EF=BC=9A<= /strong>
=E4=B8=BB=E9=A2=98=EF=BC=9A<= /strong> New Version Notification for=20 draft-yan-dmm-hnprenum-03.txt
=C2=A0
A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-yan-dmm-hnprenum-= 03.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Zhiwei=C2= =A0Yan=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
Name: draft-yan-dmm-hnprenum
Revision: 03
Title:=20 Home=C2=A0Network=C2=A0Prefix=C2=A0Renumbering=C2=A0in=C2=A0PMIPv6
Document=C2=A0date: 2015-10-11
Group: Individual=C2=A0Submission
Pages: 8
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0https://www.ietf.org/internet-drafts/draft-yan-= dmm-hnprenum-03.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-yan-dmm-hnprenum/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://to= ols.ietf.org/html/draft-yan-dmm-hnprenum-03
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0https://www.ietf.org/rfcdiff?url2=3Ddraft-yan-dmm-hnpre= num-03
Abstract:
=C2=A0=C2=A0=C2=A0In=C2=A0the=C2=A0basic=C2=A0Proxy=C2=A0Mobile=C2=A0I= Pv6=C2=A0(PMIPv6)=C2=A0specification,=C2=A0a=C2=A0Mobile=C2=A0Node
=C2=A0=C2=A0=C2=A0(MN)=C2=A0is=C2=A0assigned=C2=A0with=C2=A0a=C2=A064-= bit=C2=A0Home=C2=A0Network=C2=A0Prefix=C2=A0(HNP)=C2=A0during=C2=A0its
=C2=A0=C2=A0=C2=A0initial=C2=A0attachment=C2=A0for=C2=A0the=C2=A0Home= =C2=A0Address=C2=A0(HoA)=C2=A0configuration.=C2=A0=C2=A0During
=C2=A0=C2=A0=C2=A0the=C2=A0movement=C2=A0of=C2=A0the=C2=A0MN,=C2=A0thi= s=C2=A0prefix=C2=A0remains=C2=A0unchanged=C2=A0and=C2=A0in=C2=A0this=C2=A0w= ay
=C2=A0=C2=A0=C2=A0it=C2=A0is=C2=A0unnecessary=C2=A0for=C2=A0the=C2=A0M= N=C2=A0to=C2=A0reconfigure=C2=A0its=C2=A0HoA=C2=A0and=C2=A0reconnect=C2=A0t= he
=C2=A0=C2=A0=C2=A0ongoing=C2=A0communications.=C2=A0=C2=A0However,=C2= =A0the=C2=A0current=C2=A0protocol=C2=A0(RFC5213)=C2=A0does
=C2=A0=C2=A0=C2=A0not=C2=A0specify=C2=A0related=C2=A0operations=C2=A0t= o=C2=A0support=C2=A0the=C2=A0MN=C2=A0to=C2=A0timely=C2=A0receive
=C2=A0=C2=A0=C2=A0and=C2=A0use=C2=A0a=C2=A0new=C2=A0HNP=C2=A0when=C2= =A0the=C2=A0allocated=C2=A0HNP=C2=A0changes.=C2=A0=C2=A0In=C2=A0this=C2=A0d= raft,=C2=A0a
=C2=A0=C2=A0=C2=A0solution=C2=A0to=C2=A0support=C2=A0the=C2=A0HNP=C2= =A0renumbering=C2=A0is=C2=A0proposed,=C2=A0as=C2=A0an=C2=A0update=C2=A0of
=C2=A0=C2=A0=C2=A0RFC5213.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Please=C2=A0note=C2=A0that=C2=A0it=C2=A0may=C2=A0take=C2=A0a=C2=A0coup= le=C2=A0of=C2=A0minutes=C2=A0from=C2=A0the=C2=A0time=C2=A0of=C2=A0submissio= n
until=C2=A0the=C2=A0htmlized=C2=A0version=C2=A0and=C2=A0diff=C2=A0are= =C2=A0available=C2=A0at=C2=A0tools.ietf.org.
The=C2=A0IETF=C2=A0Secretariat

--001a114066d291e7c80522a396dc-- From nobody Wed Oct 21 14:12: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 5DD9B1B307C for ; Wed, 21 Oct 2015 14:12:14 -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 8h1O9c41LgDD for ; Wed, 21 Oct 2015 14:12:04 -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 BD2C81B30B4 for ; Wed, 21 Oct 2015 14:11:56 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so47656166lbc.3 for ; Wed, 21 Oct 2015 14:11:55 -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=Y7wJKBGA8On7JCIyK2qzmZqVf/c6Rzb0+0DGpkXNp6M=; b=DwvUhoFf0XU+WJ8mNzGG6sRH/SNEgMs7v56KokRAdsW+h6RmcPQQU/7zyNxElPoqrx u6yknVffjXew+X6qLaOcf4jozHpyfPMQFGWrr2xX4/ORhqzBx6iV97OIGohVFfahxVJW NFaheasUn3B/QDNFxzpEat18IYmgh6d9xlrC/WUewDB0xPjMUIRfqFtj642EmqaOacdI KzDAKpwkxu0dCddzIQIWqvzmfupyNM4FHjI5Equzfg8T16ol/wlBst+ciErXnXxVRYma TKrrP1VdhmOnQQDlPcObWPTjKYrJzK7XBZayRCmj6sxOyywjslhU2JIqQAJWoQ902Ehc Zi+g== MIME-Version: 1.0 X-Received: by 10.112.160.138 with SMTP id xk10mr6463317lbb.119.1445461914912; Wed, 21 Oct 2015 14:11:54 -0700 (PDT) Received: by 10.25.86.21 with HTTP; Wed, 21 Oct 2015 14:11:54 -0700 (PDT) In-Reply-To: <561C485E.5000708@earthlink.net> References: <561C485E.5000708@earthlink.net> Date: Wed, 21 Oct 2015 14:11:54 -0700 Message-ID: From: jouni korhonen To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a11c38b90f993750522a3d353 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Review comments on draft-ietf-dmm-4283mnids-00.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, 21 Oct 2015 21:12:14 -0000 --001a11c38b90f993750522a3d353 Content-Type: text/plain; charset=UTF-8 Has all concerns been addresses in -01? Myself, I did not find complete proposal for the one below and agree with Sri that such detail would be useful. - Jouni *[Sri] This is a major issue. * *I was hoping to see a sub-section for each of the types. We cannot standardize a identifier type without providing any explanation on the identifier type or the references to the base definitions. This can be painful, but I'd have a small section for each of the types. It can be 3 line text on the a.) Definition b.) Format c.) Example format d.) Reference to the base spec that defines those identifiers.* On Mon, Oct 12, 2015 at 4:55 PM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Sri, > > Thanks for that terrific review. Please see my follow-up below and > request for > additional discussion. > > On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote: > > 1. Introduction > > The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to > be a popular design tool for providing identifiers for mobile nodes > during authentication procedures with AAA protocols such as Diameter > [RFC3588]. To date, only a single type of identifier has been > specified, namely the MN NAI. Other types of identifiers are in > common use, and even referenced in RFC 4283. > > *[Sri] Some text on the motivation for defining new Types may be helpful. > Document is not just standardizing the currently in-use/popular identifier > types, its also introducing new types are not in use. The reasons/interest > for defining identifiers that are tied to the physical elements of the > device (RFID, MAC address ..etc) and how it helps in deployment of the > technology may be useful. Few lines of text will really help.* > > > Here is the paragraph with some new text: > > In this document, we > propose adding some basic types that are commonly in use in various > telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI, > and IEEE MAC-layer addresses. In addition, we include the IPv6 > address itself as a legitimate mobile node identifier. > Defining identifiers that are tied to the physical elements of the > device (RFID, MAC address etc.) help in deployment of Mobile IP > because in many cases such identifiers are the most natural means > for uniquely identifying the device, and will avoid additional > look-up steps that might be needed if other identifiers were used. > > including the IMSI, P-TMSI, IMEI, GUTI, > and IEEE MAC-layer addresses. In addition, we include the IPv6 > address itself as a legitimate mobile node identifier. > > *[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.* > > > Will do. > > 2. New Mobile Node Identifier Types > > The following types of identifiers are commonly used to identify > mobile nodes. For each type, references are provided with full > details on the format of the type of identifer. > > EPC supports several encoding systems or schemes including > > *[Sri] EPC? EPC Tag Standards I assume, not the Evolved Packet Core. > Reference to [EPC-Tag-Data] will help > * > > > Will do. > > o RFID-GID (Global Identifier), o RFID-SGTIN (Serialized Global Trade Item > Number), > > .......... *many lines deleted* .............. > > o RFID-DOD-URI [RFID-DoD-96] > o RFID-GIAI-URI [EPC-Tag-Data] > o 39-255 reserved > > > *[Sri] This is a major issue. > > I was hoping to see a sub-section for each of the types. We cannot > > standardize a identifier type without providing any explanation on the > > identifier type or the references to the base definitions. This can > > be painful, but I'd have a small section for each of the types. It can > > be 3 line text on the a.) Definition b.) Format c.) Example format d.) > > Reference to the base spec that defines those identifiers.* > > > This might be dangerous, because it would be a partial respecification for > for identifiers outside the general expertise of this group. But I will > try to think of something. Contributed text will be very much appreciated. > > 3. Security Considerations > > This document does not introduce any security mechanisms, and does > not have any impact on existing security mechanisms. Insofar as the > selection of a security association may be dependent on the exact > form of a mobile node identifier, additional specification may be > necessary when the new identifier types are employed with the general > AAA mechanisms for mobile node authorizations. > > Some identifiers (e.g., IMSI) are considered to be private > information. If used in the MNID extension as defined in this > document, the packet including the MNID extension should be encrypted > > > *[Sri] Besides the use of IMSI, the document also defines the use of other > sensitive identifiers such as IPv6..* > > > Do you think that IPv6 addresses are more sensitive than IPv4 addresses? > > * Mention of the available tools for > privacy protection may be helpful. Some thing along these lines, or better > text:* > > * "This information is considered to be very sensitive, so care must be > taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages > when carrying this sub-option. > > The base Proxy Mobile IPv6 specification [RFC5213] specifies the use > of IPsec for securing the signaling messages, and those mechanisms > can be enabled for protecting this information. Operators can > potentially apply IPsec Encapsulating Security Payload (ESP) with > confidentiality and integrity protection for protecting the location > information."* > > I am O.K. with that text. However, the same considerations apply to > RFC 4283, so that the initial paragraph is still sort-of correct. Should > I make a statement that our understanding of various vulnerabilities > has led to the desire for better security surrounding identification > features? > > so that personal information or trackable identifiers would not be > inadvertently disclosed to passive observers. Moreover, MNIDs > containing sensitive identifiers might only be used for signaling > during initial network entry. Subsequent binding update exchanges > would then rely on a temporary identifier allocated during the > initial network entry. > > *[Sri] The MAG/MN can certainly obtain an temporary identifier as part > of he access authentication and can use the same in the signaling. > But, I'M unaware of any spec where the MN identifier changes between > initial and subsequent binding updates. Clarification may be help* > > > I put in some clarifying text: > > Subsequent binding update exchanges might then rely on > a temporary identifier allocated during the initial > network entry, perhaps using mechanisms not standardized > within the IETF. Managing the association between > long-lived and temporary identifiers is outside the scope > of this document. > > > 4. > > New Mobile Node Identifier Types > > +-----------------+------------------------+ > | Identifier Type | Identifier Type Number | > +-----------------+------------------------+ > | IPv6 Address | 2 | > > > .......... *many lines deleted* .............. > > | RFID-GIAI-URI | 38 | > | | 39-255 reserved | > +-----------------+------------------------+ > > Table 1 > > See Section 2 for details about the identifer types. > > *[Sri] But, Section 2 has no text on the above types.* > > > Point noted, although there is a little bit of explanatory text. > Section 2 does have citations. How about: > > See Section 2 for additional information about the identifier types. > > Plus, if more text is required about the types, then section 2 would > indeed have details. > > Vijay Devarapalli > Vasona Networks > 2900 Lakeside Drive, Suite 180 > Santa Clara, CA 95054 > USA > > > > *[Sri] Vijay ? Who is that ? References to people from ancient history > and who are currently dormant can be silently omitted :) * > > > Well, I asked Vijay if he wanted to remain as co-author and he told me > he did want to remain. > > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --001a11c38b90f993750522a3d353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Has all concerns been addresses in -01? Myse= lf, I did not find complete proposal for the one below and agree with Sri t= hat such detail would be useful.

- Jouni
[Sri] This is a major issue.=C2=A0
I was hoping to see a sub-section for each of the =
types. We cannot standardize a identifier type without providing any explan=
ation on the identifier type or the references to the base definitions. Thi=
s can be painful, but I'd have a small section for each of the types. I=
t can be 3 line text on the a.) Definition b.) Format c.) Example format d.=
) Reference to the base spec that defines those identifiers.

On Mon, Oc= t 12, 2015 at 4:55 PM, Charlie Perkins <charles.perkins@earthl= ink.net> wrote:
=20 =20 =20
Hello Sri,

Thanks for that terrific review.=C2=A0 Please see my follow-up below an= d request for
additional discussion.=C2=A0

On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote:
=20 
1.  Introduction

   The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to
   be a popular design tool for providing identifiers for mobile nodes
   during authentication procedures with AAA protocols such as Diameter
   [RFC3588].  To date, only a single type of identifier has been
   specified, namely the MN NAI.  Other types of identifiers are in
   common use, and even referenced in RFC 4283.=C2=A0
[Sri] Some text on the motivation for defin=
ing new Types may be helpful.
Document is not just standardizing the currently in-use/popular identifier
types, its also introducing new types are not in use. The reasons/interest
for defining identifiers that are tied to the physical elements of the
device (RFID, MAC address ..etc) and how it helps in deployment of the
technology may be useful. Few lines of text will really help.

Here is the paragraph with some new text:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 In this document, we
 =C2=A0=C2=A0 propose adding some basic types that are commonl= y in use in various
 =C2=A0=C2=A0 telecommunications standards, including the IMSI= , P-TMSI, IMEI, GUTI,
 =C2=A0=C2=A0 and IEEE MAC-layer addresses.=C2=A0 In addition,= we include the IPv6
 =C2=A0=C2=A0 address itself as a legitimate mobile node ident= ifier.
 =C2=A0=C2=A0 Defining identifiers that are tied to the= physical elements of the
 =C2=A0=C2=A0 device (RFID, MAC address etc.) help in deployme= nt of Mobile IP
 =C2=A0=C2=A0 because in many cases such identifiers are the m= ost natural means
 =C2=A0=C2=A0 for uniquely identifying the device, and will av= oid additional
 =C2=A0=C2=A0 look-up steps that might be needed if other iden= tifiers were used.

 
                             including the IMSI, P-TMSI, IMEI,=
 GUTI,
   and IEEE MAC-layer addresses.  In addition, we include the IPv6
   address itself as a legitimate mobile node identifier.
[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be =
3GPP TS 23.003.

 Will do.

2.  New Mobile Node Identifier Types

   The following types of identifiers are commonly used to identify
   mobile nodes.  For each type, references are provided with full
   details on the format of the type of identifer.

   EPC supports several encoding systems or schemes including
[Sri] EPC?  EPC Tag Standards I assume=
, not the Evolved Packet Core.
      Reference to [EPC-Tag-Data] will help

Will do.



   o  RFID-GID (Global Identifier),
   o  RFID-SGTIN (Serialized Global Trade Item Number),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 .......... many lines deleted ..............
   o  RFID-DOD-URI [RFID-DoD-96]
   o  RFID-GIAI-URI [EPC-Tag-Data]
   o  39-255 reserved


[Sri] This is a major issue.
> I was hoping to see a sub-section for each of the types. We cannot
> standardize a identifier type without providing any explanation on the
> identifier type or the references to the base definitions. This can
> be painful, but I'd have a small section for each of the types. It=
 can
> be 3 line text on the a.) Definition b.) Format c.) Example format d.)
> Reference to the base spec that defines those identifiers.<=
/pre>

This might be dangerous, because it would be a partial respecification for
for identifiers outside the general expertise of this group.=C2=A0 But = I will
try to think of something.=C2=A0 Contributed text will be very much appreciated.

3.  Security Considerations

   This document does not introduce any security mechanisms, and does
   not have any impact on existing security mechanisms.  Insofar as the
   selection of a security association may be dependent on the exact
   form of a mobile node identifier, additional specification may be
   necessary when the new identifier types are employed with the general
   AAA mechanisms for mobile node authorizations.

   Some identifiers (e.g., IMSI) are considered to be private
   information.  If used in the MNID extension as defined in this
   document, the packet including the MNID extension should be encrypted


[Sri] Besides the use of IMSI, the documen=
t also defines the use of other
      sensitive identifiers such as IPv6..

Do you think that IPv6 addresses are more sensitive than IPv4 addresses?

    Mention of the available tools for
privacy protection may be helpful. Some thing along these lines, or better
text:
  "This information is considered to be v=
ery sensitive, so care must be
   taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages
   when carrying this sub-option.

   The base Proxy Mobile IPv6 specification [RFC5213] specifies the use
   of IPsec for securing the signaling messages, and those mechanisms
   can be enabled for protecting this information.  Operators can
   potentially apply IPsec Encapsulating Security Payload (ESP) with
   confidentiality and integrity protection for protecting the location
   information."
I am O.K. with that text.=C2=A0 However, the same considerations apply = to
RFC 4283, so that the initial paragraph is still sort-of correct.=C2=A0 Should
I make a statement that our understanding of various vulnerabilities has led to the desire for better security surrounding identification features?

   so that personal information or trackable identifiers would=
 not be
   inadvertently disclosed to passive observers.  Moreover, MNIDs
   containing sensitive identifiers might only be used for signaling
   during initial network entry.  Subsequent binding update exchanges
   would then rely on a temporary identifier allocated during the
   initial network entry.
[Sri] The MAG/MN can certainly obtain an tempora=
ry identifier as part
      of he access authentication and can use the same in the signaling.
      But, I'M unaware of any spec where the MN identifier changes betw=
een
      initial and subsequent binding updates. Clarification may be help

 I put in some clarifying text:

=C2=A0=C2=A0=C2=A0 Subsequent binding update exchanges might then r= ely on
=C2=A0=C2=A0=C2=A0 a temporary identifier allocated during the= initial
=C2=A0=C2=A0=C2=A0 network entry, perhaps using mechani= sms not standardized
=C2=A0=C2=A0=C2=A0 within the IETF.=C2=A0 Managing the associa= tion between
=C2=A0=C2=A0=C2=A0 long-lived and temporary identifiers is out= side the scope
=C2=A0=C2=A0=C2=A0 of this document.


4.
                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 .......... many lines deleted ..............

               | RFID-GIAI-URI   | 38                    =
 |
               |                 | 39-255 reserved        |
               +-----------------+------------------------+

                                  Table 1

   See Section 2 for details about the identifer types.


[Sri] But, Section 2 has no text on the above types.

 Point noted, although there is a little bit of explanatory text.
Section 2 does have citations.=C2=A0 How about:

=C2=A0=C2=A0=C2=A0 See Section 2 for additional information about t= he identifier types.

Plus, if more text is required about the types, then section 2 would indeed have details.

   Vijay Devarapalli
   Vasona Networks
   2900 Lakeside Drive, Suite 180
   Santa Clara, CA 95054
   USA



[Sri] Vijay ? Who is that ? References to people=
 from ancient history
      and who are currently dormant can be silently omitted :)  =

Well, I asked Vijay if he wanted to remain as co-author and he told me
he did want to remain.

Regards,
Charlie P.

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


--001a11c38b90f993750522a3d353-- From nobody Wed Oct 21 14:18: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 B27C71B30DA for ; Wed, 21 Oct 2015 14:18:39 -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 MYNeDnFKNYBZ for ; Wed, 21 Oct 2015 14:18:38 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8251B30D9 for ; Wed, 21 Oct 2015 14:18:38 -0700 (PDT) Received: by lbbes7 with SMTP id es7so47882292lbb.2 for ; Wed, 21 Oct 2015 14:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wACUkDvzAgbwkeRBsGCiEv7jLbnbcSSu+FjtNYIb3ug=; b=wAUNRkNjaCwz3p2n/sUZMZNQ7x8plXQhLHUxdQSXg43HqutPtRrEvJNrO/P4XMRCSV N5/EptDSqSaJW57gK4kQhTuQdJeXpfueE2C8oPfCQ/ao9gHXb9qHlc8teOhWcvLg3HZM kMjsq5l2Ez3oFS1tr0sxhXnmjKSA+nJPRZc/wtARwOh+24KyYRJewhreqdIp833KbQ8X X6Yks3qLhKtSktefIUSAJnbJQ3+75zXqqhqZhfs1Iqsma9n5pf1BMsRX4Yp4BGCUB0pe s/X/xmcq3WUhYhly9e6AlrhlaZ91ViLUt9gE8iyfKXhwPuKgoU2QiUSnkTI1h9Gsn2+t 2GLw== MIME-Version: 1.0 X-Received: by 10.112.61.226 with SMTP id t2mr6456410lbr.11.1445462316527; Wed, 21 Oct 2015 14:18:36 -0700 (PDT) Received: by 10.25.86.21 with HTTP; Wed, 21 Oct 2015 14:18:36 -0700 (PDT) Date: Wed, 21 Oct 2015 14:18:36 -0700 Message-ID: From: jouni korhonen To: "dmm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3eebce9b48f0522a3eb01 Archived-At: Subject: [DMM] Preparations for the IETF94 Yokohama meeting 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, 21 Oct 2015 21:18:39 -0000 --001a11c3eebce9b48f0522a3eb01 Content-Type: text/plain; charset=UTF-8 Folks, There are few documents on the MIP maintenance path that will be dealt in Yokohama meeting. We are also likely to ask for adoption for some of those. So do us a favor and spend some time reading the following I-Ds and preferably provide comments already before the meeting: 1) Home Network Prefix Renumbering in PMIPv6 draft-yan-dmm-hnprenum-03 2) MAG Multipath Binding Option draft-seite-dmm-rg-multihoming-02 3) LMA Controlled MAG Session Parameters draft-gundavelli-dmm-lma-controlled-mag-params-00 - Jouni --001a11c3eebce9b48f0522a3eb01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

There are few documents on the MIP maintenance path that will be deal= t in Yokohama meeting. We are also likely to ask for adoption for some of t= hose. So do us a favor and spend some time reading the following I-Ds and p= referably provide comments already before the meeting:
<= br>
1) =C2=A0Home Network Prefix Renumbering in PMIPv6
=C2=A0 =C2=A0 draft-yan-dmm-hnprenum-03

2) =C2=A0MAG Multipath Binding Option
=C2=A0 =C2=A0 draft-seite-dmm-rg-multihoming-02=C2=A0

3) =C2=A0LMA Controlled MAG Session Param= eters
=C2=A0 =C2=A0 draft-gundavelli-dmm-lma-controlled-= mag-params-00=C2=A0

- Jouni
--001a11c3eebce9b48f0522a3eb01-- From nobody Wed Oct 21 17:42: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 546F11A6FED for ; Wed, 21 Oct 2015 17:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, 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 eN6MDOPMaDtC for ; Wed, 21 Oct 2015 17:42:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 222161A6FE1 for ; Wed, 21 Oct 2015 17:42:45 -0700 (PDT) Received: from Foxmail (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QEz7MChWlZLuBA--.62723S2; Thu, 22 Oct 2015 08:42:35 +0800 (CST) Date: Thu, 22 Oct 2015 08:42:34 +0800 From: "=?utf-8?B?Wi5XLiBZYW4=?=" To: "=?utf-8?B?am91bmkga29yaG9uZW4=?=" References: <201510130944230363409@cnnic.cn>, Message-ID: <201510220842339616412@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon653417884272_=====" X-CM-TRANSID: AQAAf0A5QEz7MChWlZLuBA--.62723S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCrW5uF4xAryfWr1rWw4DArb_yoWrJFW7pF W3JF1xJw1kZ34DC3yxZry7Wr1rZa4DJrWUAFy7Kr18AFs8C3Wktry8KF4rXrWDGryrAFWU Xa1IvFs8WrWFyrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU92b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxMxkF 7I0En4kS14v26r126r1DMxkIecxEwVAFwVWDMxAIw28IcxkI7VAKI48JMxC20s026xCaFV Cjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWl x4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r 1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyU JVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYx BIdaVFxhVjvjDU0xZFpf9x07j4PfdUUUUU= X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Cc: =?utf-8?B?Sm9uZy1IeW91ayBMZWU=?= , =?utf-8?B?ZG1t?= , =?utf-8?B?eGw=?= Subject: Re: [DMM] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-yan-dmm-?= =?utf-8?q?hnprenum-03=2Etxt?= 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, 22 Oct 2015 00:42:51 -0000 This is a multi-part message in MIME format. --=====003_Dragon653417884272_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IHNvIG11Y2gsIEpvdW5pLg0KVGhlc2UgaXNzdWVzIHdpbGwgYmUgZml4ZWQgaW4g dGhlIHJldmlzaW9uLg0KDQoNCjIwMTUtMTAtMjIgDQoNCg0KDQpaLlcuIFlhbiANCg0KDQoNCuWP keS7tuS6uu+8miBqb3VuaSBrb3Job25lbiANCuWPkemAgeaXtumXtO+8miAyMDE1LTEwLTIyICAw NDo1NDo0OCANCuaUtuS7tuS6uu+8miBaLlcuIFlhbiANCuaKhOmAge+8miBkbW07IG1heHBhc3Np b247IEpvbmctSHlvdWsgTGVlOyB4bCANCuS4u+mimO+8miBSZTogRnc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQteWFuLWRtbS1obnByZW51bS0wMy50eHQgDQogDQpDaGVja2Vk IHRoZSBkaWZmcyBhbmQgSUROaXRzLiBNYWtlIGFsd2F5cyBzdXJlIHRvIGNvbXBseSB3aXRoIElE Tml0cyBhcyBpdCBpcyBzbyBlYXN5ICYgY2hlYXAgdG9vbCB0byB1c2UuDQoNCg0KLSBKb3VuaQ0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQogICoqIFRoZSBkb2N1bWVudCBz ZWVtcyB0byBsYWNrIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gIChTZWUgU2VjdGlv bg0KICAgICAyLjIgb2YgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC1pbmZvL2NoZWNrbGlzdCBmb3Ig aG93IHRvIGhhbmRsZSB0aGUgY2FzZQ0KICAgICB3aGVuIHRoZXJlIGFyZSBubyBhY3Rpb25zIGZv ciBJQU5BLikNCg0KICAqKiBUaGVyZSBpcyAxIGluc3RhbmNlIG9mIHRvbyBsb25nIGxpbmVzIGlu IHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qgb25lDQogICAgIGJlaW5nIDEgY2hhcmFjdGVyIGlu IGV4Y2VzcyBvZiA3Mi4NCg0KDQogIE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DQogIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KICA9PSBUaGUgZG9jdW1lbnQgZG9lc24ndCB1c2UgYW55IFJGQyAyMTE5 IGtleXdvcmRzLCB5ZXQgc2VlbXMgdG8gaGF2ZSBSRkMNCiAgICAgMjExOSBib2lsZXJwbGF0ZSB0 ZXh0Lg0KDQogIC0tIFRoZSBkb2N1bWVudCBkYXRlIChPY3RvYmVyIDExLCAyMDE1KSBpcyAxMCBk YXlzIGluIHRoZSBwYXN0LiAgSXMgdGhpcw0KICAgICBpbnRlbnRpb25hbD8NCg0KDQogIENoZWNr aW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQNCiAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgIChTZWUgUkZDcyAzOTY3IGFuZCA0ODk3IGZvciBp bmZvcm1hdGlvbiBhYm91dCB1c2luZyBub3JtYXRpdmUgcmVmZXJlbmNlcw0KICAgICB0byBsb3dl ci1tYXR1cml0eSBkb2N1bWVudHMgaW4gUkZDcykNCg0KICAqKiBPYnNvbGV0ZSBub3JtYXRpdmUg cmVmZXJlbmNlOiBSRkMgMjQ2MSAoT2Jzb2xldGVkIGJ5IFJGQyA0ODYxKQ0KDQogICoqIERvd25y ZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gRXhwZXJpbWVudGFsIFJGQzogUkZDIDYwNTgN Cg0KICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEluZm9ybWF0aW9uYWwg UkZDOiBSRkMgNjg3OQ0KDQoNCiAgICAgU3VtbWFyeTogNSBlcnJvcnMgKCoqKSwgMCBmbGF3cyAo fn4pLCAxIHdhcm5pbmcgKD09KSwgMSBjb21tZW50ICgtLSkuDQoNCiAgICAgUnVuIGlkbml0cyB3 aXRoIHRoZSAtLXZlcmJvc2Ugb3B0aW9uIGZvciBtb3JlIGRldGFpbGVkIGluZm9ybWF0aW9uIGFi b3V0DQogICAgIHRoZSBpdGVtcyBhYm92ZS4NCg0KDQoNCg0KDQpPbiBNb24sIE9jdCAxMiwgMjAx NSBhdCA2OjQ0IFBNLCBaLlcuIFlhbiA8eWFuQGNubmljLmNuPiB3cm90ZToNCg0KRGVhciBBbGws DQpXZSBqdXN0IHJldmlzZWQgdGhlIEhOUC1yZW51bWJlcmluZyBkcmFmdCBiYXNlZCBvbiB0aGUg Y29tbWVudHMgb25saW5lIGFuZCBvZmZsaW5lIGFuZCBwb3N0ZWQgdG8gdGhlIERNTSBXRy4NCkFu eSBmdXJ0aGVyIGNvbW1lbnRzIGZyb20geW91IGFyZSBhbHdheXMgd2VsY29tZS4NCg0KQmVzaWRl cywgSm91bmkgYW5kIERhcGVuZywNCldvdWxkIHlvdSBwbGVhc2UgYXNzaWduIG1lIDUtMTAgbWlu dXRlcyB0byByZS1pbnRyb2R1Y2UgdGhpcyBkcmFmdCBpbiB0aGUgRE1NIG1lZXRpbmc/DQoNCkJS LA0KDQoNCjIwMTUtMTAtMTMNCg0KDQoNClouVy4gWWFuDQoNCg0KDQrlj5Hku7bkurrvvJogaW50 ZXJuZXQtZHJhZnRzDQrlj5HpgIHml7bpl7TvvJogMjAxNS0xMC0xMiAxNDozMzowNA0K5pS25Lu2 5Lq677yaIFpoaXdlaSBZYW47IFhpYW9Eb25nIExlZTsgWGlhb2RvbmcgTGVlOyBKb25nLUh5b3Vr IExlZQ0K5oqE6YCB77yaIA0K5Li76aKY77yaIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQteWFuLWRtbS1obnByZW51bS0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXlhbi1kbW0taG5wcmVudW0tMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFpoaXdlaSBZYW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCk5h bWU6IGRyYWZ0LXlhbi1kbW0taG5wcmVudW0NClJldmlzaW9uOiAwMw0KVGl0bGU6IEhvbWUgTmV0 d29yayBQcmVmaXggUmVudW1iZXJpbmcgaW4gUE1JUHY2DQpEb2N1bWVudCBkYXRlOiAyMDE1LTEw LTExDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogOA0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW4tZG1tLWhu cHJlbnVtLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDMNCkRpZmY6ICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteWFuLWRtbS1obnBy ZW51bS0wMw0KQWJzdHJhY3Q6DQogICBJbiB0aGUgYmFzaWMgUHJveHkgTW9iaWxlIElQdjYgKFBN SVB2Nikgc3BlY2lmaWNhdGlvbiwgYSBNb2JpbGUgTm9kZQ0KICAgKE1OKSBpcyBhc3NpZ25lZCB3 aXRoIGEgNjQtYml0IEhvbWUgTmV0d29yayBQcmVmaXggKEhOUCkgZHVyaW5nIGl0cw0KICAgaW5p dGlhbCBhdHRhY2htZW50IGZvciB0aGUgSG9tZSBBZGRyZXNzIChIb0EpIGNvbmZpZ3VyYXRpb24u ICBEdXJpbmcNCiAgIHRoZSBtb3ZlbWVudCBvZiB0aGUgTU4sIHRoaXMgcHJlZml4IHJlbWFpbnMg dW5jaGFuZ2VkIGFuZCBpbiB0aGlzIHdheQ0KICAgaXQgaXMgdW5uZWNlc3NhcnkgZm9yIHRoZSBN TiB0byByZWNvbmZpZ3VyZSBpdHMgSG9BIGFuZCByZWNvbm5lY3QgdGhlDQogICBvbmdvaW5nIGNv bW11bmljYXRpb25zLiAgSG93ZXZlciwgdGhlIGN1cnJlbnQgcHJvdG9jb2wgKFJGQzUyMTMpIGRv ZXMNCiAgIG5vdCBzcGVjaWZ5IHJlbGF0ZWQgb3BlcmF0aW9ucyB0byBzdXBwb3J0IHRoZSBNTiB0 byB0aW1lbHkgcmVjZWl2ZQ0KICAgYW5kIHVzZSBhIG5ldyBITlAgd2hlbiB0aGUgYWxsb2NhdGVk IEhOUCBjaGFuZ2VzLiAgSW4gdGhpcyBkcmFmdCwgYQ0KICAgc29sdXRpb24gdG8gc3VwcG9ydCB0 aGUgSE5QIHJlbnVtYmVyaW5nIGlzIHByb3Bvc2VkLCBhcyBhbiB1cGRhdGUgb2YNCiAgIFJGQzUy MTMuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== --=====003_Dragon653417884272_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PVVURi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE3NTE5Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRh bmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNl Y3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJ R046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6 IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3 IHsNCglGT05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28t c3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsN CglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0K fQ0KT0wgew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJ TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFS R0lOOiAxMHB4Ij4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5h PlRoYW5rIHlvdSBzbyBtdWNoLCANCkpvdW5pLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDA4MD5UaGVzZSBpc3N1ZXMgd2lsbCBiZSBmaXhlZCBpbiB0aGUgDQpyZXZpc2lvbi48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFu YT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZh Y2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAg c2l6ZT0yIGZhY2U9VmVyZGFuYT4yMDE1LTEwLTIyIDwvRk9OVD48L0RJVj48Rk9OVCANCmNvbG9y PSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEwMHB4IiBh bGlnbj1sZWZ0IGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJVj48Rk9OVCBjb2xv cj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+Wi5XLiBZYW48L1NQQU4+IDwvRk9O VD48L0RJVj4NCjxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Y+R5Lu25Lq677yaPC9TVFJPTkc+IGpvdW5pIGtvcmhvbmVu IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+ 5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IDIwMTUtMTAtMjImbmJzcDsgMDQ6NTQ6NDggDQo8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mlLbku7bk urrvvJo8L1NUUk9ORz4gWi5XLiBZYW4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT1WZXJkYW5hPjxTVFJPTkc+5oqE6YCB77yaPC9TVFJPTkc+IGRtbTsgbWF4cGFzc2lvbjsg Sm9uZy1IeW91ayANCkxlZTsgeGwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPjxTVFJPTkc+5Li76aKY77yaPC9TVFJPTkc+IFJlOiBGdzogTmV3IFZlcnNpb24g DQpOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDMudHh0IDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJViBkaXI9bHRyPg0KPERJViBjbGFzcz1n bWFpbF9kZWZhdWx0IA0Kc3R5bGU9IkZPTlQtU0laRTogeC1zbWFsbDsgRk9OVC1GQU1JTFk6IG1v bm9zcGFjZSxtb25vc3BhY2UiPkNoZWNrZWQgdGhlIGRpZmZzIA0KYW5kIElETml0cy4gTWFrZSBh bHdheXMgc3VyZSB0byBjb21wbHkgd2l0aCBJRE5pdHMgYXMgaXQgaXMgc28gZWFzeSAmYW1wOyBj aGVhcCANCnRvb2wgdG8gdXNlLjwvRElWPg0KPERJViBjbGFzcz1nbWFpbF9kZWZhdWx0IA0Kc3R5 bGU9IkZPTlQtU0laRTogeC1zbWFsbDsgRk9OVC1GQU1JTFk6IG1vbm9zcGFjZSxtb25vc3BhY2Ui PjxCUj48L0RJVj4NCjxESVYgY2xhc3M9Z21haWxfZGVmYXVsdCANCnN0eWxlPSJGT05ULVNJWkU6 IHgtc21hbGw7IEZPTlQtRkFNSUxZOiBtb25vc3BhY2UsbW9ub3NwYWNlIj4tIEpvdW5pPC9ESVY+ DQo8RElWIGNsYXNzPWdtYWlsX2RlZmF1bHQgDQpzdHlsZT0iRk9OVC1TSVpFOiB4LXNtYWxsOyBG T05ULUZBTUlMWTogbW9ub3NwYWNlLG1vbm9zcGFjZSI+PEJSPjwvRElWPg0KPERJViBjbGFzcz1n bWFpbF9kZWZhdWx0IA0Kc3R5bGU9IkZPTlQtU0laRTogeC1zbWFsbDsgRk9OVC1GQU1JTFk6IG1v bm9zcGFjZSxtb25vc3BhY2UiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7PC9E SVY+DQo8RElWIGNsYXNzPWdtYWlsX2RlZmF1bHQgDQpzdHlsZT0iRk9OVC1TSVpFOiB4LXNtYWxs OyBGT05ULUZBTUlMWTogbW9ub3NwYWNlLG1vbm9zcGFjZSI+PFBSRSBzdHlsZT0iV09SRC1XUkFQ OiBicmVhay13b3JkOyBXSElURS1TUEFDRTogcHJlLXdyYXA7IENPTE9SOiByZ2IoMCwwLDApIj4g ICoqIFRoZSBkb2N1bWVudCBzZWVtcyB0byBsYWNrIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbi4gIChTZWUgU2VjdGlvbg0KICAgICAyLjIgb2YgPEEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC1pbmZvL2NoZWNrbGlzdCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC1pbmZvL2NoZWNr bGlzdDwvQT4gZm9yIGhvdyB0byBoYW5kbGUgdGhlIGNhc2UNCiAgICAgd2hlbiB0aGVyZSBhcmUg bm8gYWN0aW9ucyBmb3IgSUFOQS4pDQoNCiAgKiogVGhlcmUgaXMgMSBpbnN0YW5jZSBvZiB0b28g bG9uZyBsaW5lcyBpbiB0aGUgZG9jdW1lbnQsIHRoZSBsb25nZXN0IG9uZQ0KICAgICBiZWluZyAx IGNoYXJhY3RlciBpbiBleGNlc3Mgb2YgNzIuDQoNCg0KICBNaXNjZWxsYW5lb3VzIHdhcm5pbmdz Og0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgPT0gVGhlIGRvY3VtZW50IGRvZXNuJ3QgdXNl IGFueSBSRkMgMjExOSBrZXl3b3JkcywgeWV0IHNlZW1zIHRvIGhhdmUgUkZDDQogICAgIDIxMTkg Ym9pbGVycGxhdGUgdGV4dC4NCg0KICAtLSBUaGUgZG9jdW1lbnQgZGF0ZSAoT2N0b2JlciAxMSwg MjAxNSkgaXMgMTAgZGF5cyBpbiB0aGUgcGFzdC4gIElzIHRoaXMNCiAgICAgaW50ZW50aW9uYWw/ DQoNCg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6IFByb3Bvc2Vk IFN0YW5kYXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAoU2VlIFJGQ3MgMzk2NyBh bmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMN CiAgICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpDQoNCiAgKiogT2Jzb2xl dGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDI0NjEgKE9ic29sZXRlZCBieSBSRkMgNDg2MSkN Cg0KICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEV4cGVyaW1lbnRhbCBS RkM6IFJGQyA2MDU4DQoNCiAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBJ bmZvcm1hdGlvbmFsIFJGQzogUkZDIDY4NzkNCg0KDQogICAgIFN1bW1hcnk6IDUgZXJyb3JzICgq KiksIDAgZmxhd3MgKH5+KSwgMSB3YXJuaW5nICg9PSksIDEgY29tbWVudCAoLS0pLg0KDQogICAg IFJ1biBpZG5pdHMgd2l0aCB0aGUgLS12ZXJib3NlIG9wdGlvbiBmb3IgbW9yZSBkZXRhaWxlZCBp bmZvcm1hdGlvbiBhYm91dA0KICAgICB0aGUgaXRlbXMgYWJvdmUuDQo8L1BSRT4NCjxESVY+PEJS PjwvRElWPjwvRElWPjwvRElWPg0KPERJViBjbGFzcz1nbWFpbF9leHRyYT48QlI+DQo8RElWIGNs YXNzPWdtYWlsX3F1b3RlPk9uIE1vbiwgT2N0IDEyLCAyMDE1IGF0IDY6NDQgUE0sIFouVy4gWWFu IDxTUEFOIA0KZGlyPWx0cj4mbHQ7PEEgaHJlZj0ibWFpbHRvOnlhbkBjbm5pYy5jbiIgDQp0YXJn ZXQ9X2JsYW5rPnlhbkBjbm5pYy5jbjwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+DQo8QkxPQ0tR VU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lO OiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj48VT48L1U+ DQogIDxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7IE1B UkdJTjogMTBweCI+PEZPTlQgDQogIGNvbG9yPSMwMDAwMDAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4N CiAgPERJVj5EZWFyIEFsbCw8L0RJVj4NCiAgPERJVj5XZSBqdXN0IHJldmlzZWQgdGhlIEhOUC1y ZW51bWJlcmluZyBkcmFmdCBiYXNlZCBvbiB0aGUgY29tbWVudHMgb25saW5lIA0KICBhbmQgb2Zm bGluZSBhbmQgcG9zdGVkIHRvIHRoZSBETU0gV0cuPC9ESVY+DQogIDxESVY+QW55IGZ1cnRoZXIg Y29tbWVudHMgZnJvbSB5b3UgYXJlIGFsd2F5cyB3ZWxjb21lLjwvRElWPg0KICA8RElWPiZuYnNw OzwvRElWPg0KICA8RElWPkJlc2lkZXMsIEpvdW5pIGFuZCBEYXBlbmcsPC9ESVY+DQogIDxESVY+ V291bGQgeW91IHBsZWFzZSBhc3NpZ24gbWUgNS0xMCBtaW51dGVzIHRvIHJlLWludHJvZHVjZSB0 aGlzIGRyYWZ0IGluIHRoZSANCiAgRE1NIG1lZXRpbmc/PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9E SVY+DQogIDxESVY+QlIsPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+Jm5ic3A7 PC9ESVY+DQogIDxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjIw MTUtMTAtMTM8L0ZPTlQ+PC9ESVY+DQogIDxESVYgYWxpZ249bGVmdD4NCiAgPEhSIHN0eWxlPSJX SURUSDogMTAwcHgiIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KICA8L0RJVj4NCiAgPERJVj48Rk9O VCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+Wi5XLiANCllhbjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogIDxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KICA8RElWPjxG T05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7lj5Hku7bkurrvvJo8L1NUUk9ORz4gDQog IGludGVybmV0LWRyYWZ0czwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT1W ZXJkYW5hPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IA0KICAyMDE1LTEwLTEyJm5i c3A7MTQ6MzM6MDQ8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT48U1RST05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiBaaGl3ZWkgWWFuOyBYaWFvRG9uZyBMZWU7 IA0KICBYaWFvZG9uZyBMZWU7IEpvbmctSHlvdWsgTGVlPC9GT05UPjwvRElWPg0KICA8RElWPjxG T05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gPC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7kuLvpopjv vJo8L1NUUk9ORz4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KICBmb3IgZHJhZnQteWFuLWRt bS1obnByZW51bS0wMy50eHQ8L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCiAgPERJVj48L0RJVj4NCiAgPERJVj5BJm5i c3A7bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LXlhbi1kbW0t aG5wcmVudW0tMDMudHh0PC9ESVY+DQogIDxESVY+aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3Nm dWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7Wmhpd2VpJm5ic3A7WWFuJm5ic3A7YW5k Jm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8L0RJVj4NCiAgPERJVj5JRVRGJm5ic3A7cmVw b3NpdG9yeS48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj5OYW1lOiBkcmFmdC15YW4tZG1t LWhucHJlbnVtPC9ESVY+DQogIDxESVY+UmV2aXNpb246IDAzPC9ESVY+DQogIDxESVY+VGl0bGU6 IA0KICBIb21lJm5ic3A7TmV0d29yayZuYnNwO1ByZWZpeCZuYnNwO1JlbnVtYmVyaW5nJm5ic3A7 aW4mbmJzcDtQTUlQdjY8L0RJVj4NCiAgPERJVj5Eb2N1bWVudCZuYnNwO2RhdGU6IDIwMTUtMTAt MTE8L0RJVj4NCiAgPERJVj5Hcm91cDogSW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248L0RJVj4N CiAgPERJVj5QYWdlczogODwvRElWPg0KICA8RElWPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QSANCiAg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlhbi1kbW0t aG5wcmVudW0tMDMudHh0IiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQteWFuLWRtbS1obnByZW51bS0wMy50eHQ8L0E+PC9ESVY+DQog IDxESVY+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxBIA0KICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC15YW4tZG1tLWhucHJlbnVtLyIgDQogIHRhcmdldD1fYmxhbms+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWFuLWRtbS1obnByZW51bS88L0E+PC9ESVY+DQogIDxE SVY+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PEEg DQogIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW4tZG1tLWhucHJl bnVtLTAzIiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteWFuLWRtbS1obnByZW51bS0wMzwvQT48L0RJVj4NCiAgPERJVj5EaWZmOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxB IA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteWFuLWRt bS1obnByZW51bS0wMyIgDQogIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDM8L0E+PC9ESVY+DQogIDxESVY+PC9E SVY+DQogIDxESVY+QWJzdHJhY3Q6PC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4m bmJzcDt0aGUmbmJzcDtiYXNpYyZuYnNwO1Byb3h5Jm5ic3A7TW9iaWxlJm5ic3A7SVB2NiZuYnNw OyhQTUlQdjYpJm5ic3A7c3BlY2lmaWNhdGlvbiwmbmJzcDthJm5ic3A7TW9iaWxlJm5ic3A7Tm9k ZTwvRElWPg0KICA8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyhNTikmbmJzcDtpcyZuYnNwO2Fzc2ln bmVkJm5ic3A7d2l0aCZuYnNwO2EmbmJzcDs2NC1iaXQmbmJzcDtIb21lJm5ic3A7TmV0d29yayZu YnNwO1ByZWZpeCZuYnNwOyhITlApJm5ic3A7ZHVyaW5nJm5ic3A7aXRzPC9ESVY+DQogIDxESVY+ Jm5ic3A7Jm5ic3A7Jm5ic3A7aW5pdGlhbCZuYnNwO2F0dGFjaG1lbnQmbmJzcDtmb3ImbmJzcDt0 aGUmbmJzcDtIb21lJm5ic3A7QWRkcmVzcyZuYnNwOyhIb0EpJm5ic3A7Y29uZmlndXJhdGlvbi4m bmJzcDsmbmJzcDtEdXJpbmc8L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUmbmJz cDttb3ZlbWVudCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7TU4sJm5ic3A7dGhpcyZuYnNwO3ByZWZp eCZuYnNwO3JlbWFpbnMmbmJzcDt1bmNoYW5nZWQmbmJzcDthbmQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDt3YXk8L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtpdCZuYnNwO2lzJm5ic3A7 dW5uZWNlc3NhcnkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtNTiZuYnNwO3RvJm5ic3A7cmVjb25m aWd1cmUmbmJzcDtpdHMmbmJzcDtIb0EmbmJzcDthbmQmbmJzcDtyZWNvbm5lY3QmbmJzcDt0aGU8 L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtvbmdvaW5nJm5ic3A7Y29tbXVuaWNhdGlv bnMuJm5ic3A7Jm5ic3A7SG93ZXZlciwmbmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5ic3A7cHJvdG9j b2wmbmJzcDsoUkZDNTIxMykmbmJzcDtkb2VzPC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7Jm5i c3A7bm90Jm5ic3A7c3BlY2lmeSZuYnNwO3JlbGF0ZWQmbmJzcDtvcGVyYXRpb25zJm5ic3A7dG8m bmJzcDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7TU4mbmJzcDt0byZuYnNwO3RpbWVseSZuYnNwO3Jl Y2VpdmU8L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsmbmJzcDthbmQmbmJzcDt1c2UmbmJzcDth Jm5ic3A7bmV3Jm5ic3A7SE5QJm5ic3A7d2hlbiZuYnNwO3RoZSZuYnNwO2FsbG9jYXRlZCZuYnNw O0hOUCZuYnNwO2NoYW5nZXMuJm5ic3A7Jm5ic3A7SW4mbmJzcDt0aGlzJm5ic3A7ZHJhZnQsJm5i c3A7YTwvRElWPg0KICA8RElWPiZuYnNwOyZuYnNwOyZuYnNwO3NvbHV0aW9uJm5ic3A7dG8mbmJz cDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7SE5QJm5ic3A7cmVudW1iZXJpbmcmbmJzcDtpcyZuYnNw O3Byb3Bvc2VkLCZuYnNwO2FzJm5ic3A7YW4mbmJzcDt1cGRhdGUmbmJzcDtvZjwvRElWPg0KICA8 RElWPiZuYnNwOyZuYnNwOyZuYnNwO1JGQzUyMTMuPC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxE SVY+PC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9E SVY+DQogIDxESVY+PC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxESVY+UGxlYXNlJm5ic3A7bm90 ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxl Jm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtv ZiZuYnNwO3N1Ym1pc3Npb248L0RJVj4NCiAgPERJVj51bnRpbCZuYnNwO3RoZSZuYnNwO2h0bWxp emVkJm5ic3A7dmVyc2lvbiZuYnNwO2FuZCZuYnNwO2RpZmYmbmJzcDthcmUmbmJzcDthdmFpbGFi bGUmbmJzcDthdCZuYnNwOzxBIA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD1fYmxhbms+dG9vbHMuaWV0Zi5vcmc8L0E+LjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElW PlRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDwvRElWPg0KICA8RElWPjwvRElWPjwvRk9O VD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj48L0RJVj48L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon653417884272_=====-- From nobody Thu Oct 22 09:46: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 1B6D51AD37C for ; Thu, 22 Oct 2015 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7v4YvRcC84xG for ; Thu, 22 Oct 2015 09:46:50 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360D71AD379 for ; Thu, 22 Oct 2015 09:46:49 -0700 (PDT) Received: by padhk11 with SMTP id hk11so91302857pad.1 for ; Thu, 22 Oct 2015 09:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=1lQtuNd33QHwoJfiM5iEamBMddO43inmQ3xeUg4DA50=; b=cfaxiM6Jtc5K1s/WJdumrpHJju6gQ02lFuzX6P29csh4GnpvHQMnhw7YzyIFq/YLQe XbsjUhvgBaw+rj2tOIeH7StEWklV/dW8f0nqQ+72ameVm3AAgLWf9PAMsjVI6YA14E1/ YQI0OgGNoa9ytc8iBT2NpVCPaV0YtvEtK149mxbTSzS7qb04Dxj51ephkAWoPDq8V6by 42YfVoLbNk/UPeM5Nua+mMDut+pWBs81E9/0qA5oHCUR/4LNu6Y6ArtgzfNkjJaNFdSP 2DjGyQCeujFxqU2MLNJIwCFHooQ2/cXej6/dmUl18DneR1nlSB1hlRCvzXpQnKqNm36O QQkQ== X-Received: by 10.68.204.134 with SMTP id ky6mr18935866pbc.19.1445532408833; Thu, 22 Oct 2015 09:46:48 -0700 (PDT) Received: from [10.16.84.125] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id eg5sm14725510pac.30.2015.10.22.09.46.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Oct 2015 09:46:47 -0700 (PDT) To: "dmm@ietf.org" , Jouni , =?UTF-8?B?5oiQIOm5jw==?= From: Jouni Korhonen Message-ID: <562912F6.5010204@gmail.com> Date: Thu, 22 Oct 2015 09:46:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] Draft IETF94 DMM WG 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: Thu, 22 Oct 2015 16:46:51 -0000 A bit late but here we go. Small adjustments are still possible but not too likely. - Jouni & Dapeng Tuesday November 3, 2015 (JST) 9:00-11:30 Tuesday Morning session I Room: 411/412 9:00 Administrivia & Intro, WG organization & milestones 15 Presenter: Chairs ** DMM track 9:15 AERO, DHCPv6 PD, multi-addressing 15 Presenter: Fred Templin 9:30 Use Cases and API Extension for Source IP 15 Address Selection Presenter: Seil Jeon Draft: draft-sijeon-dmm-use-cases-api-source 9:45 WT#1 Exposing mobility state update 15 Presenter: Danny Moses 10:00 Prefix CostCommunicating Prefix Cost to Mobile Nodes 15 Presenter: John Kaippallimalil Draft: draft-mccann-dmm-prefixcost 10:15 Protocol for Forwarding Policy Configuration 20 Presenter: Marco Liebsch Draft: draft-ietf-dmm-fpc-cpdp 10:35 Title: Distributed mobility management deployment 15 scenario and architecture Presenter: Zhiheng Liu Draft: draft-liu-dmm-deployment-scenario ** MIP maintenance track 10:50 LMA Controlled MAG Session Parameters 10 Presenter: Sri Gundavelli Draft: draft-gundavelli-dmm-lma-controlled-mag-params 11:00 MN Identifier Types for RFC 4283 Mobile Node 10 Identifier Option Presenter: Charlie Perkins Draft: draft-ietf-dmm-4283mnids 11:10 Adoption calls for MIP maintenance drafts 10 Presenter: Chairs Drafts: draft-yan-dmm-hnprenum-03 draft-seite-dmm-rg-multihoming-02 11:20 AOB 10 Adjourn 11:30 ** Overflow queue (if we got time left) Deprecated Network Prefix Provision 5 Presenter: Jong-Hyouk Lee Draft: draft-jhlee-dmm-dnpp Motivations, usecases and Models of VCPE 5 Presenter: Qiao Fu Draft: draft-fu-dmm-vcpe-models From nobody Thu Oct 22 09:54:06 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 944011B29F1 for ; Thu, 22 Oct 2015 09:54:04 -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 R5cVn4isezKO for ; Thu, 22 Oct 2015 09:54:03 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AFB1B29DD for ; Thu, 22 Oct 2015 09:54:03 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so95600540pac.3 for ; Thu, 22 Oct 2015 09:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=m3adxt4n0+LL9GjnC2VkC3bRik3tM429AaxGPcGWuLo=; b=fGw+awRn+uSI0teaJJ8TyLf4SmfQ9pp63sr+m2CoxcFrTShtJHvmXtsibR0P5eTS0x R12ZoKrmrnUafD+TLYIwlw4dDMswJAlAx7gHDJOeYxndk1gGsPCIp0B+o8zIpaZDhOmR GbZ6+t5/Fw3BWkzYn9nc5xqAlJ/TaC+W78fZ8O9NBGVxA65yiIFS64uKXaD9jlbO5qRf UsYYqXcjJEQhh3dkaUZ+MeoG82m2pjgJNz/xlAPlPLybxF7HyayvjZg1V7S6nY84PDWV TvwFKJT+3dQkRdGEMimNSVfhyCrlG5qx/zhuCBgpGQDhB5+5Sl495Msnl/4btKgErCBX +Glw== X-Received: by 10.68.143.4 with SMTP id sa4mr18290007pbb.111.1445532842776; Thu, 22 Oct 2015 09:54:02 -0700 (PDT) Received: from [10.16.84.125] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id fa14sm14748636pac.8.2015.10.22.09.54.01 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Oct 2015 09:54:01 -0700 (PDT) To: "dmm@ietf.org" From: Jouni Korhonen Message-ID: <562914A8.7090301@gmail.com> Date: Thu, 22 Oct 2015 09:54:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] IETF94 DMM meeting logistics 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, 22 Oct 2015 16:54:04 -0000 Folks, Our WG meeting is on Tuesday morning. Send you materials to chairs by Sunday evening. - Jouni & Dapeng From nobody Thu Oct 22 09:56:55 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 DF7D91B399C for ; Thu, 22 Oct 2015 09:56:53 -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 MLC7YdnVCs7j for ; Thu, 22 Oct 2015 09:56:52 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e: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 973B81B3965 for ; Thu, 22 Oct 2015 09:56:52 -0700 (PDT) Received: by pasz6 with SMTP id z6so91352185pas.2 for ; Thu, 22 Oct 2015 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=ktHxDhYlNBJZlk+5X8lobqbpXHJ67f3sqMOwvCo2I4U=; b=PiBb+XIcEFEay5/zibyC0W3YbYVootfmav9vyLeBP5h30INQSJOYIOk6H3c3cgyNqz ss+I/jLs+G5MPOY+T+KYRKMN7IexwZl+ZBPfRlqokWaU2wv86XGLq732rtUBD1iiWGuE /5Q9hZW95qBkuQT6CaXbvMuXjNrCXndguSutKE9hq7pdaZDjH+HsDCXultBXNogK3L4t LgUjEWok3gk5mbhD/Vg1+EDTcc9GRcVXJ9hBS5c7arpNOEKOV/7JkEJBj+Px1BvOhy0F mnPpIfBEQixLquJ4u3X7aZTS9R/MTlhiPZuCSP9svv1ErOJx8CQ/BVoZF9RzzhR9osps 1/Sw== X-Received: by 10.68.215.73 with SMTP id og9mr18669509pbc.122.1445533012302; Thu, 22 Oct 2015 09:56:52 -0700 (PDT) Received: from [10.16.84.125] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id fk8sm14759334pab.33.2015.10.22.09.56.50 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Oct 2015 09:56:51 -0700 (PDT) To: "dmm@ietf.org" From: Jouni Korhonen Message-ID: <56291552.9000408@gmail.com> Date: Thu, 22 Oct 2015 09:56:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] note takers for IETF94 DMM meeting 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, 22 Oct 2015 16:56:54 -0000 You can volunteer in advance before we volunteer someone during the meeting administrivia ;-) - Jouni & Dapeng From nobody Thu Oct 22 13:44:19 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 E46F91AD272 for ; Thu, 22 Oct 2015 13:44:17 -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 4N7Df8PkMk7K for ; Thu, 22 Oct 2015 13:44:10 -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 D778B1AD0C4 for ; Thu, 22 Oct 2015 13:44:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCX36193; Thu, 22 Oct 2015 20:44:06 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Oct 2015 21:44:03 +0100 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 04:43:50 +0800 From: Peter McCann To: John Kaippallimalil , "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YA== Date: Thu, 22 Oct 2015 20:43:49 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C587ESZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 22 Oct 2015 20:44:18 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C587ESZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C587ESZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Prefix coloring in its= current form is not going to work.

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John=

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@ci= sco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Hi John= ,

&n= bsp;

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

&n= bsp;

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= o:p>

&n= bsp;

Regards=

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C587ESZXEML503MBSchi_-- From nobody Thu Oct 22 14:38:29 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 543171B42A4 for ; Thu, 22 Oct 2015 14:38:19 -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 8fSxyRUGqC5W for ; Thu, 22 Oct 2015 14:38:09 -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 A42731B42B8 for ; Thu, 22 Oct 2015 14:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45622; q=dns/txt; s=iport; t=1445549888; x=1446759488; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RcmaI5RfDDcTqP0QRY04v+9lL/cB10ty4Frzb5oFjkY=; b=ImADeZ0AsBTWunThXrwc+bPYeO+Tr0enMwJLwVMR7N/s8S6699Y0PW5G R0uyzD80CcrlFpLk5N7zvdkNpCUmS8onwvZc7T838Rf/Tsc1cO/sPJwtZ WXIK6kQSdSrxD/VJY0qmwQ0qBys1uDbp4fL46cHHT+qIUvFElQeKTbMh4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQAOVilW/4kNJK1egmlNVG8Gvh4BDYFZIYV8AoFMOBQBAQEBAQEBgQqELgEBAQQaE0QGDgQCAQgRAQIBAQEhAQYHMhQDBQEIAgQBEh+IEQ3FOwEBAQEBAQEBAQEBAQEBAQEBAQEBARiGd4N4gQaEYgcTDQoBAgSEKAWNFIVJg04BhRhpggeFFYFYSIN3kh+DbwEfAQFChANyAYU8gQYBAQE X-IronPort-AV: E=Sophos; i="5.20,184,1444694400"; d="scan'208,217"; a="40172636" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2015 21:38:07 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9MLc7Di013711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 21:38:07 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 16:37:46 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 16:37:46 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRDRHk9C08Y0kWM0eq1lV3Y0Kxlg== Date: Thu, 22 Oct 2015 21:37:46 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D24E9D8E1ED3A3sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 22 Oct 2015 21:38:19 -0000 --_000_D24E9D8E1ED3A3sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D24E9D8E1ED3A3sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <814450FE420599488C9737EA8627562D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Pete,

There are no simple way to compute that prefix cost. If we say that it= is just a topological distance, that=92s not simple to measure either. An = overlay tunnel across an IP cloud will be viewed as a single hop with a top= ological distance of 1, but there is an IP cloud  in between. We can certainly say, it can be any algor= ithm that presents two remote gateways/prefixes in some order with some der= ived cost metric, but coming out with that algorithm is the core issue here= . When an access router views two sets of measurements for two distance gateways, each with different jitter, lat= ency and packet loss characteristics, how would the AR make the call ? Woul= d that be based on latency, or will that be based on packet loss ? Why jitt= er and why not loss ? When there is no one definitive way to compute that, exposing the same to the end poi= nt is incorrect as that has an implication on the application that uses tha= t prefix.

Regarding the property meta-data that goes with a prefix, it can certa= inly change.  There is no assumption that property set does not change= . A router R1 hosting a remote prefix may present a different property set,= than a router R2 hosting the same prefix. Updating the same will inform the end-point about the change in network ch= aracteristics. What goes into the meta-data is a set of properties with no = ambiguity associated with it. But, here this prefix cost is about path char= acterization and that is not based on one factor, but its a list of factors that cannot be normalized and pre= sented as a single value.


Sri






From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at= 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@c= isco.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

Prefix coloring in its= current form is not going to work.

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailt= o:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85

 

Some notes inline belo= w.

 

John=

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Hi John= ,

&n= bsp;

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

&n= bsp;

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..=

&n= bsp;

Regards=

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D24E9D8E1ED3A3sgundaveciscocom_-- From nobody Thu Oct 22 15:03: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 0441A1AD0B1 for ; Thu, 22 Oct 2015 15:03:42 -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 TAZxWYL3hw-X for ; Thu, 22 Oct 2015 15:03:32 -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 034181AD0D6 for ; Thu, 22 Oct 2015 15:03:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZE12412; Thu, 22 Oct 2015 22:03:28 +0000 (GMT) Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Oct 2015 23:03:27 +0100 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 06:03:16 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRA= Date: Thu, 22 Oct 2015 22:03:16 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.63] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AFSZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 22 Oct 2015 22:03:42 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AFSZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AFSZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= o:p>

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Pete,

&n= bsp;

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.

&n= bsp;

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AFSZXEML503MBSchi_-- From nobody Thu Oct 22 15:55: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 706B21B2F9B for ; Thu, 22 Oct 2015 15:55:48 -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 90ZroSj6BToT for ; Thu, 22 Oct 2015 15:55:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7221B2F95 for ; Thu, 22 Oct 2015 15:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58376; q=dns/txt; s=iport; t=1445554542; x=1446764142; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=O+da2X+FHDMh3SlYzi+1jvSoT1TyfR31GuNIfS0Mnbs=; b=AKtN22Vg45tAFYOYdFYW+9Pu80sW61Yf9cKiY4ZGNY81ELpeBxJBSUmn PUyh2LecQo/hJR5WS3WAmhsTXFsm0OTvVSDBKM8WPZfLOCA972/8UzV3S ABRegHhXj2dUghPtNguuic4wI/I2QMou5vopXlpouPzpqGUF+s7/LlPs4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQDWaClW/5hdJa1egmlNVG8Gvh4BDYFZI4V6AoFPOBQBAQEBAQEBgQqEMgEBAQMBDA4TQwEBBQcHBAIBCBEBAgEBASEBBgcyFAMFAQgCBAESH4gJCA3FMAEBAQEBAQEBAQEBAQEBAQEBAQEBARiGd4N4gQaEYgcTDQoBAgSEKAWNFIVJg04BhRhpggeFFYFYSIN3kh+DbwEfAQFChANyAYU8gQYBAQE X-IronPort-AV: E=Sophos; i="5.20,184,1444694400"; d="scan'208,217"; a="38251744" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 22 Oct 2015 22:55:40 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9MMte7g010937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 22:55:40 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 17:55:19 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 17:55:19 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRDRy5SqzDLEu4yke85C7GKZR4ow== Date: Thu, 22 Oct 2015 22:55:19 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D24EB1231ED4C6sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 22 Oct 2015 22:55:48 -0000 --_000_D24EB1231ED4C6sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D24EB1231ED4C6sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <014A952A54E24D4D804F242D012763FF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
> &n= bsp;It is = intended as a measure of the amount of state being maintained in the networ= k on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point = of attachment.

This is exactly the point. We cannot represent that =93state=94 and = =93resources=94 associated with the prefix in a single parameter called =93= prefix-cost=94. At the end of the day, the goal is to enable the end-point = to make meaningful use of it. If we say, this value is so local to the operator,  how does my stack on the host mak= e use of it ? I=92m launching two applications and there are two prefixes P= 1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 because it has a bet= ter cost, but my host not know what that cost means as we never published that algorithm. What is the point ? Why not su= ppress all prefixes and give a single prefix that is deemed to meet the app= requirement, from the AR point of view ?  

If we say that, we don=92t specify the algorithm, keep the scope to op= erator=92s end points and domain, then there is truly no need for interop. =  I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-ipv6-nd-vendo= r-spec-options-00.txt . 

Regarding the =93fixed=94 comment, I see where the disconnect is and i= ts my mistake. I meant to say, there are =93n=94 number of properties that = goes with a prefix; each of those prefixes have well defined meaning. As th= e prefix moves in the network from R1 to R2, properties do change. Property bit A can be ON at R1, but may be OFF o= n R2. Your example of =93Tunneled=94 is OFF at home link, but ON on a visit= or link.


Sri




From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at= 3:03 PM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Pete,

&n= bsp;

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.

&n= bsp;

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D24EB1231ED4C6sgundaveciscocom_-- From nobody Thu Oct 22 17:01: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 CFFEC1ACD48 for ; Thu, 22 Oct 2015 17:01:16 -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 4_Z2Xx632wsc for ; Thu, 22 Oct 2015 17:01:04 -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 85F3B1ACD39 for ; Thu, 22 Oct 2015 17:01:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZE18493; Fri, 23 Oct 2015 00:01:01 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 23 Oct 2015 01:01:00 +0100 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 08:00:49 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2Q Date: Fri, 23 Oct 2015 00:00:49 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.63] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Fri, 23 Oct 2015 00:01:17 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.<= /p>

&n= bsp;

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

&n= bsp;

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

&n= bsp;

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1SZXEML503MBSchi_-- From nobody Thu Oct 22 21:59: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 E893F1B31BF for ; Thu, 22 Oct 2015 21:59:49 -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 XYto2SpM_VH5 for ; Thu, 22 Oct 2015 21:59:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E281B31BC for ; Thu, 22 Oct 2015 21:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71384; q=dns/txt; s=iport; t=1445576383; x=1446785983; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XowZ0Q1DX+TVMUL7OMhCvbmIeLSF6ppf9zTkGqz3zd8=; b=NNxcuHXplo8YpRsl0vh4ul0LKIQ8dldzV4qBLeBEeRZ2TzPWL3gW6aE1 zkAVpiVsej7AKbOxNRd3wlFpMpEoFcDCuqadzYKFQDhrid8uq8kg5/q5L 9CAE9oXA+3qboaVR5hz09a/KLulJVvoMubVT4adzibcC5VKsUAhG2jk2+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQB9vSlW/5tdJa1dgmlNVG8Gvh8BDYFZI4V6AoFGOBQBAQEBAQEBgQqEMgEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcU6AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRiBxMNCgECBIQoBYVIgXqFUoVJg04BhRhpggeCXYI4gVhIg3eSH4NvAR8BAUKEA3IBhTyBBgEBAQ X-IronPort-AV: E=Sophos; i="5.20,185,1444694400"; d="scan'208,217"; a="44041260" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2015 04:59:40 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9N4xdSq029162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Oct 2015 04:59:39 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 23:59:18 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 23:59:18 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRDU+Svs5E7mKuvEqxlqMn0++L7A== Date: Fri, 23 Oct 2015 04:59:18 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D24F04321ED663sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Fri, 23 Oct 2015 04:59:50 -0000 --_000_D24F04321ED663sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D24F04321ED663sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I=92ve not payed attention to that discussion on the fixed/sustaining/= nomadic address types. But, I don=92t see much relation to this specific ex= tension around =93prefix-cost=94 and the drafts dealing with colorometry. I= thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as s= ome number or some representation of topological distance; its not dealing = with properties or capabilities and at least the draft does not talk about = that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an addre= ss that has lower prefix-cost value, when there is another prefix with a be= tter prefix-cost value. The prefix-cost has only one implied meaning, bigge= r the better. The same can be achieved by sending a single prefix was my point.

Now, regarding the specific shade of grey that you are looking  i= n my color palette :), I don=92t see an issue there. As long as you can giv= e a property name for each of your fifty shades of grey and have a printed = card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on t= he wire. These properties have well defined meaning that can be used by app= lications for matching the app requirement with the address capabilities. W= e can certainly argue that we can define infinite # number of properties (with the long/short tunnel example= ) and we are back in square one, but thats a name space management issue an= d we will not allow such color definitions. This is different from the pref= ix-cost issue, where the algorithm is unknown and the value has no universal meaning and my point there its n= ot helping the end point in address selection.

Sri




From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at= 5:00 PM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.<= /p>

&n= bsp;

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

&n= bsp;

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

&n= bsp;

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.<= /span>

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D24F04321ED663sgundaveciscocom_-- From nobody Fri Oct 23 05:06:20 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 B3E001B3563 for ; Fri, 23 Oct 2015 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mthrcO2drBs3 for ; Fri, 23 Oct 2015 05:06:18 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D31B355D for ; Fri, 23 Oct 2015 05:06:17 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 23 Oct 2015 05:06:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,186,1444719600"; d="xml'?pptx'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="801080882" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga001.jf.intel.com with ESMTP; 23 Oct 2015 05:06:16 -0700 Received: from fmsmsx122.amr.corp.intel.com (10.18.125.37) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 23 Oct 2015 05:06:16 -0700 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by fmsmsx122.amr.corp.intel.com (10.18.125.37) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 23 Oct 2015 05:06:16 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.216]) by hasmsx109.ger.corp.intel.com ([169.254.3.26]) with mapi id 14.03.0248.002; Fri, 23 Oct 2015 15:06:11 +0300 From: "Moses, Danny" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] IETF94 DMM meeting logistics Thread-Index: AQHRDOpPAgeYYnqZ+0uZvPg/IxJ2W554+9fg Date: Fri, 23 Oct 2015 12:06:11 +0000 Message-ID: References: <562914A8.7090301@gmail.com> In-Reply-To: <562914A8.7090301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/mixed; boundary="_002_F0CF5715D3D1884BAC731EA1103AC28134987CACHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF94 DMM meeting logistics 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, 23 Oct 2015 12:06:19 -0000 --_002_F0CF5715D3D1884BAC731EA1103AC28134987CACHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, This is the slides for the WT1 report. Regards, /Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Thursday, October 22, 2015 19:54 To: dmm@ietf.org Subject: [DMM] IETF94 DMM meeting logistics Folks, Our WG meeting is on Tuesday morning. Send you materials to chairs by Sunda= y evening. - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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. --_002_F0CF5715D3D1884BAC731EA1103AC28134987CACHASMSX106gercor_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="IETF94-DMM-WT1-Report.pptx" Content-Description: IETF94-DMM-WT1-Report.pptx Content-Disposition: attachment; filename="IETF94-DMM-WT1-Report.pptx"; size=66206; creation-date="Tue, 06 Oct 2015 11:44:02 GMT"; modification-date="Tue, 06 Oct 2015 12:34:48 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBKqkPnEAIAAGAQAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM mNty2jAQhu8703fw6LaDBUlD0g4mF216lbSZSfoAir2AWlnSSAuBt+/aHGIYNwZsD9wws8j699OB f70MbuepCmbgvDQ6Yr2wywLQsUmkHkfs9/OPzg0LPAqdCGU0RGwBnt0OP34YPC8s+IBmax+xCaL9 yrmPJ5AKHxoLmkZGxqUCKXRjbkX8V4yBX3S7fR4bjaCxg5kGGw6+w0hMFQZ3c/p6SfLHwpgF35YP ZrkiJtNMIB/gpXMcKL8zR1irZCyQVsdnOtkh66yoQpqZP+Mn0vpPhM7KM2Qj21DFBKt5v2g7nUwg eBQOf4qU0Lm1yK0DT6vOE4XvK5WgmtFIxpCYeJqSSFgUS9VWGKZC6vUi/gfjFRE+CI909LwQ9Jom K2jvxbSiaYfjEIKLVnbiEILLkxN8PjnB1UkItEHw619HIWj8Vha0q27GhEzYTHFNtRU2zrWlXkWW edGjM9Y3fVYb4SqCmYTXVgg2wlUESJUPeP5Z/zBymcqM4kXBEy4UNL7v+CZdRZHb+71Y0M1cOfcy qL8JOxWukOhYpnYcfbneY5na8fh6TO24fj2mdupAPaZ+037XwB2/PkOmmzNk+nKGTL3uOUKd0skL VbW+ee9XVd/qeH1rrsxI7Vz+2kIdsYPDD3/dvmazO5bewMChhE0DW9b7bTJS43p4wp0mFLJ+PYGk JDfP/x8Y/gMAAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsACAJfcmVscy8ucmVscyCi BAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c0z9f8s96 s3ejeKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8VDMzxTsqs B3KYqxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVItIipkCW2 5S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D3jnyPGOCnHZ8 M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAAAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TB AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc4SPwWrDMBBE74X8g9h7 JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vx CwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2q tGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c 9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebN Tn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY 9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOz dMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcB AAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhT LyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGT hokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwxxdlq SGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8D AFBLAwQUAAYACAAAACEAdgVTjF8BAAAbBwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1s LnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACslc1OwzAMx+9IvEOVO8u6 Lz60bheEtAMSgvEAofXaijaJYm+wtycqY8uqyVxyaWU3tX/523Hmy++2SXbgsDY6E+lgKBLQuSlq XWbiff10cycSJKUL1RgNmdgDiuXi+mr+Co0i/xNWtcXER9GYiYrIPkiJeQWtwoGxoP2XjXGtIm+6 UlqVf6oS5Gg4nEkXxhCLs5jJqsiEWxU+/3pvfeb/Y5vNps7h0eTbFjRdSCErvxGzpWeFBM4HVq4E 8qFDN56vSgd+B0JehhvHhMOmLuAE1Zkou9eIg7iNCaENAfb1CZwoA4PVJh3F5CL10cAb7Rvff8e6 BU5OoKggTJV4OWKq0UH0qxQ4D23zu4LFmkXHOpWnAzqgTLkCpWlMCvLDJzhHnSm7J6vENCYD0yUT Vgk/f+ONu10NXy/O2ODIHF0cxSQmBCPFmIO4jwlhHWBPiaPrD0KeXWmLHwAAAP//AwBQSwMEFAAG AAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SP wQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQ N8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpU RPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue5 2MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK /XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvI olA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwd g3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA M6exEMkCAABXDgAAFAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JdRb5swEMffJ+07IL9OLYEQoCik 0jpV6tRpaMk+gAtOQmtsZJs06aff2XGKoXvoB+AN++7+vvtxNmZ5e2yodyBC1pzlKLieIY+wklc1 2+Xo7+b+KkWeVJhVmHJGcnQiEt2uvn5ZtlkriCRMYQWhHsgwmeEc7ZVqM9+X5Z40WF7zljCwbblo sIKh2PmVwK8g31A/nM1iv8E1QzZefCaeb7d1SX7wsmtg+bOIINTkIfd1Ky9q7WfU3CqGKck9f123 pKwxLaj8zTa1omRNqxwBJIkPZN09SaLuOVMS0CEPd4rf8UYryqIuVQcP2nkFsCStfmGpiHioHqUa zXg1iIZBlETpPI6AuMj0DPgGyF8t/f+FM66IHEkO5nqRxIoMzDaLPbxa3qmR0Gi2l0qt1MihL8kt 76E6F7aInYpCrWAKupiTG8c8/2BOgfY7j+ijGcC/mxcfzaFjjrX5TNPNc/3mlccc3QRRNJvBauUp R3G6SM1AnVpoe1kKQlh0tOkZkjbs3VOHXTRMjRXZ4o6qDTmqtTpRslriDOaKQtinP4XwKNY77Rlf /SxMdq4LPdCgBZ8Gi0fTdZjuYJdS5IHMBj+t33IULRLYRlCkosaF4Ef2XbyYhtR7gtkhuMBL28HG KzpWKm13snjpmrrhz7UJkyAbQPXIeyFCnwp6Ae0sOa2r+5pSM9A7nNxR4R0wLK2O514deZkUPA1x i0sA+a1hV1TpSnFG8MhA8NlQypGhlD0bgAYvEWcWjhaCx7DndCEywSJbB5YmZGHNe1jnhoWza+os F5YmZGFFPaxgngSx3hcTrUFraUSW1sKhlYapOUUmWgNaGpGlFfe0wjCF1pp6y3z/nGNLI7K0EodW Es3NZ2/qrUFvaUSWVtrT0qjgajOdW/r65fSWRmRp3Ti04kUynfL6ijWkpRGZ6zNMj+61cKd2/6NW /wAAAP//AwBQSwMEFAAGAAgAAAAhAOc0/hOOBAAA3gwAABUAAABwcHQvc2xpZGVzL3NsaWRlNC54 bWy8V9Fy4jYUfe9M/0HjvrQz62DAsOAJ7AQndNJJskxgp89CFqCNLKmSDKE7O9Ov6Yf1S3ol4yQO tGHTTPNgZFm6uufcc69uTj/c5xytqTZMikHQPIkCRAWRGRPLQfBpNg57ATIWiwxzKegg2FITfBh+ /92pSgzPEOwWJsGDYGWtShoNQ1Y0x+ZEKirg20LqHFt41ctGpvEGrOa80YqibiPHTAS7/fqY/XKx YISeS1LkVNjSiKYcW/DcrJgylTV1jDWlqQEzfnfNpSEgI1OeuV+jZppSNxLrn7Waqon2n2/WE41Y BnwFSOAcaAkauw+7Zf5VwDIYNJ5tX1aWcHK/0PnwFCeADd0PAiB/656wCSf03iJSTpLHWbL6eGAt WV0cWN2oDgAPHg51qEpE+3BaFZwZs5yi5gOqcimGrVeS3BkkJOB08Et45GZdGXOYnXm1QnargBnr TO3WlR89H9V6A5x6suz9SGZbB3wOv34SJ9zYqd1y6gkBt3ECxuEB9N8VOcvlZ+aDwLGTKxXhp2mA MLdX/v0zDn+ZuKNxYoeXluboh/gUSLEQk50lKrIJ1vj2sMHSwKPB8gCHGSfgDQCpvIZhSes/kxtX 5E45yyi6KfI51WjCMaEryTMYt52voL6KzVfxDVkJpiFpfx8EvxVYW6oD0CoIqdl6uzAsIPddAnxJ O71+p92Pw3baTuERj8Je1O6E/XHrYnyWNvvdUfQ12GnBOOQCvKuCeETcnkQMDnUb/8eYdaqYpVJY KBe1cHk6Xx+uMib/HhIH91mNiDvvoX76QtHsRpEbe4VX5aLXavVhPkCuaMSdVqff9bp6Wgxc0jml Veqtcs4dJ6BknxVWLphFC0A9JZhDGvdbHWeUi6kitzQriCu7oKkI/jyGpzbeIm1RxrR9rHt2OCVw qSSolsBlHvpkhAckMV/zXVl6UipKlVkdzm73qsPeMefUEM3mFK3kBl3foIwSEK1Bc2o3lAp0OQk5 3kK2wp2IpF3ByL+Hc2xohnI5Z5zZLTKFUlJb9CM9WZ68Q9eTWTp5h6aX8MBKlTZ+Qla6N75FUiCM lmwNJ2TYYrTgclOD+pLuDxe/GrwaWw+F9JvYmcKNWZik5lnN7NsE4VJkbM2yAnNEQIMQj8LpDeE1 ZhzPOT3CAZ+eeyo4giZ3QUCzsrDhli6ZCJkKq6iGUkODY6zGVuowimpu1CJ0NKs19p4F5Uhnb1zu G0vVfwjMkUdNqbXQxKFCgVx/naE0dRI2LjWRLCyCfKhn6DcHAJncppxiKC67ymaHDO7uGtU10l6Q 3EvIDh2YYs6h+kGSZxlzygMhbqS+++uPP2t+HAj5S8c9dA+7qvWa2+xAVu/3Ir4lqfpXUMiVgb5H +bay0NA2fRmN+t1W2huFo2Y8DuPz/vvwbNzthONOO47TUe8sbV98hataNeOEaOpb5cuq5YfJvTY7 Z0RLIxf2hMi8UfbrDSU3VCvJfMvejHZ9/xpDnY6bcasL91k73t2C4KXvqipvAULVihOur7H6uPYZ Av9hQFuT+ikFcnScwtLHJQ47NAt/AwAA//8DAFBLAwQUAAYACAAAACEAPqhDePcEAAAtDwAAFQAA AHBwdC9zbGlkZXMvc2xpZGUzLnhtbLxX7W7bNhT9P2DvQKjAsAJR/Ckn1uIUsZMU2drUiFP0N0NR ERuJVEnKiVcU2NPswfYkO6Ssxo69Lv3MD0WmyMt7zz338PLg2V2RkznXRig5Cjq77YBwyVQi5PUo eH15Gu4HxFgqE5oryUfBgpvg2eHPPx2UsckTgtXSxHQUZNaWcatlWMYLanZVySW+pUoX1OKnvm4l mt7CapG3uu32oFVQIYPlev2Y9SpNBePHilUFl7Y2onlOLTw3mShNY618jLVScwMzfvWaS4eIjM3y xP035aXm3L3J+XNdzsqp9p/P51NNRAK8AiJpAViC1vLDcpr/KTENL60Hy68bSzS+S3VxeEBjxEbu RgHAX7gnFtGY31nC6kF2P8qyV1vmsuxky+xWswE8+Lipi6qOaDOcbhPOpbA5J52PUdVTKZa+UOzG EKkQpwu/Do+dzxtjLmZnvsyIXZRAxjpTy3n1R49HM98AUw+WvRurZOECv8J/P0jj3NiZXeTcAwK3 aQzjeAD+m6oQhXorfBJy6ujKZfh6FhCa2xf+91sa/j51W9PYHp5ZXpAnXfILLcrfyJPeAdCxSM7S JJfJlGp6sd1ybenecr2TC57GcAsRNe7jtcb3v1HuNyjPcpFwcl4VV1yTaU4Zz1Se4L3nnAYNG1i/ CHiUJ0yjev8cBe8qqi3XAUgLRnW63y4fKUTAVcL7SbQ/jHrDftib9CZ49MfhfrsXhcPT7snp0aQz HIzbH4IlKYyLXMK7JpuPSOBKxrCpW/gDcxY1OZsoaaEba+nycH55uuqcfDolLtwHYtGP9iCkXjE6 g3bbvXuqN7qx3+0OMR4Qpx79qBsNB55Xq6rgqs8xrWFvU3xuOwntPqqsSoUlKaKeMZqjnvfa+AtI Lmclu+BJxZz+jgJsXzsA83UBOxvfon5JIrS9F0B7OGM4XWKyVsB1HfpixANFnM/zpT6taEbNMqvD y4sNmdjY5pgbpsUVJ5m6JWdTQpMEZ4bxDCZC1kcbYifCEKbknC94QlKtCiK5vVX6hlhFXp7v/lA/ KdH8XSU0XHHyS1S66jo8TRY4sARSmS+c16m4rjB5h9xmXBKc8C4aqSykTnOaLAidU5HTK5wGiNRm /NMRfVTnz0J6hmO4MvH3BurNJXJsWGUM0LmiRjBSaiGZKHNuvvfmZzIRc5FUNHewWxCr8o3LPcCP 8MALzQaftx97G3xG/5XasFCGmzApijDJWBkqmaBfkwnGr0Qu7CJsd36MIzdKZ+Cb9L6gG0vFXVhq VLa2Ah62+2turIn9o8m1pgoPuPlI1M6dnBrLy6/g5/9tRUxhJzmnkNGlhtvDCSoUsqvJm+dQHlU6 sqxL3pfyAJLwANrPRGabu9+SXL6r/Ozotnl1gR6fapYRBeXSpADExoNa6zVuI6vq6AVTcp4Y8uvL s+l8sEPO/jiZd3fI+fF0h/zz199Pnz1AbqUD+VQHs1aLa6R8eFR9tcEVA1s65O197Bb3Njta39g2 1yEUxQuD7rn0t5RKowt/Px4PB93J/jgcd/qnYf94uBcenQ6i8DTq9fuT8f7RpHfyIcCaTj9mOFwc o8+aGyQGN25tOKa0Miq1u0wVrfr61yrVLdelEv4G2Gkvr5FzitO+t9fuR9EgGkbLXgpe+t688RYh NDc7luuXtHw199THhRXN8cQPlSCF6+sx9X6Kix0t578AAAD//wMAUEsDBBQABgAIAAAAIQBF9Eja QwUAAFcSAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1svFjdbts2FL4fsHcgtJvtQvF/Ggtxitit ixZpGsQpdk1TdM2GEjWScuIVBfYse7Q9yT5Skh3HiuskbW9kmSIPv/OdH57D45e3iSQLro1Q6SBo HTQDwlOmYpF+GgQfr8bhUUCMpWlMpUr5IFhyE7w8+fWX4ywyMiZYnZqIDoK5tVnUaBg25wk1Byrj Kb7NlE6oxV/9qRFregOpiWy0m83DRkJFGpTr9T7r1WwmGH+lWJ7w1BZCNJfUArmZi8xU0rJ9pGWa G4jxqzcgnUAzNpGx+zXZlebcvaWLNzqbZBfafz5fXGgiYvAVkJQmoCVolB/Kaf5viml4adxb/qmS RKPbmU5OjmkE3cjtIAD5S/fEIhrxW0tYMcjWo2z+oWYum7+umd2oNgCC1aZOq0KjbXXalTpXwkpO WiutiqkUS88UuzYkVdDTqV+ox84XlTCnsxOfzYldZmDGOlHlvOKj56Oab8CpJ8veDlW8dIpP8esH aSSNndil5J4QwKYRhOMB+q/zRCTqs/BGkNS5K0/Dj5OAUGnP/P/PNHx34bamkT15a3lCfmsdgxQL m5SSeBpfUE0v6wUWAtYCiw2czjQCGihSocZrQevD5HYqckcqtXA9ciEp43MlY65J28GE41VEPpJq EcNRKms8hmXHTYogPc2tmglLZsA2YVTCcEe9ZhMOKdNJxi55nDMXaIMAwYvhgoPCUk7G9zAUiYW2 a0+3JxOGNBKRDZMVzHv68YDZ5EKWqt9xjsIfrA6vLrf8YWubV9wwLaaczNUNeXtBaBwjORjvv0QY wlSS5Klg1PKYTLm94Twlds4JzTJDkBrdIuRIdk1U8eH9+cEeoL3Nnwp6onLNAKHEarjk3kBkSg1g Asg9TfYA5B1oC1B9VG2xeM5vkBI5hQvBKCK9DkGJ5USkxSEA5yH8NlMOnVWOu92IEqrPBkGn2+57 LyysDGkxQmcQhOUH53vTfAyv9eaaIaIGwakWVBZxP81Hc6oJw2MQ/PfPv6Xj+kS+pekD/mL+Bg64 fbCl8wQa5ibarcgOB92T2iFMCkY5MRlnm+GwpcO3RBKT2JHkFJFcnjP2JMunUpg5DPP7/fy4Sre7 Mqz3OQcQPPnssCaqbjtjNwj7LioQVBcz69z+XS6XpN1sdf64t8udVL9TmbtZqD7b1AfuU5j3qEPB 7SyMkyRU8O4ECSVM1FRIYZdhs7lp7w1A+xlnpU+dLc5dlXGPqEeKLc9XY3n2A0OhDvyfb85G3we8 y1nPY6EOX2HdZ8rlGpkLdWZN3Dq/eab0GqnhM0XuAAwff6bwn4u3iscfALqK8A3RG9H9jeLmKenG ndFFonQOf7Z5SBenc675T4V0mi5dESNccUklcV0Z1Wz+cgMEmqF1nb5f8r4fLzup3ZL+QCWwSqWr FqAsRO8IqOlL6tuI9SG5kva4hqJbNRQTicKLnOfJFJ3E3a6i87yuomjg0OZDNBIQyqC/cqot1wEq Pddw+IPQt3Ou6fMvT+3rZrhMcB31l1HvqN/r9LthZ9QZ4dEdhkfNTi/sj9uvx6ejVv9w2PwalM2l cZqnQOfqQNcV7nKO8qBqr10Lm7qFT7HeDpv5XrC6OMD5embQcGa+n881+tUvw2H/sD06GobDVncc dl/1X4Sn48NeOO51ut3R8Oh01Hn9FSplrW7ENPd3FG+ruxYMbt1vJIJpZdTMHqBXaRQXJY1M3XCd KeHvSlrN8sJlQdEutbudF/3DF72udxDgBUpvvwothqo7ECb1e5p9WPiqAFc7MP/ID2W4zHEsYOp6 itMdpP4PAAD//wMAUEsDBBQABgAIAAAAIQC0ZNrqaQMAAMUIAAAVAAAAcHB0L3NsaWRlcy9zbGlk ZTEueG1svFZdb9owFH2ftP9g5Xk0AUIGUWEqtFSdSlc1TNUejeOUtI5t2Q4DTfvvu3aSpqO0QnsY DyRx7j2+H+f45vTLtmBoQ5XOBR973ZPAQ5QTkeb8Yex9X847Qw9pg3mKmeB07O2o9r5MPn44lbFm KQJvrmM89tbGyNj3NVnTAusTISmHd5lQBTbwqB78VOGfgFowvxcEkV/gnHu1vzrGX2RZTui5IGVB ualAFGXYQOR6nUvdoMlj0KSiGmCc918hTSAzkrDUXrVcKkrtHd9cKpnIW+Ve32xuFcpTqJeHOC6g LJ5fv6jN3CMHM7jx99wfGiQcbzNVTE5xDLmh7diD4u/sPzjhmG4NItUiaVfJ+tsBW7K+OGDtNxtA BM+b2qyqjF6n02vSWeaGUdR9zqoyxeB6LciTRlxAnjb9Kj1ys2nAbM4WXq6R2UmoDDHKodWm1XtX ksZFQ1ldvcx2KtKdzX0FV4uDYw4MOiuNyHKDMsFNQjAD1FEAPwf50phpk5gdo65+kCWOHYaCbjFs CW1UZ3nnIczMtXt+xJ2vtxYGx2ZydbGco/PFAt1fnkLpDHSuBlgdCwMOta3b/Lh9F2KVs9zs0MVW Cl0qikBuKKGMEsttdL/8r+EkIIpSuxhuLAcTQ6Xei4Dy9BYrfAcJPpVFXojH3ImhqnJV1bbKlHe+ J3WzoCvQ/KbTcFux8W1O9htOJuXKOFr2LBSItCHdP9FSl6uKlqBjEFnD5Dfoabu5p9Vu/3M3Ag5a xYajQb/mY6vbKAyCoTWw6o2GA3sPgb8UpWW+TaUpx0suv0H8qDewmIwnktzRtHQUGXtwpD7Dt+J5 Rw8H2nZYHCjNlWnPHzM5x5zv0EJoqv0zJqlCP+hDzj8hoOqKrjHLkMiQWdN94kLmTpPHC/PV3k6i e1w8SpstEtKFmTGKYdrVB62ZjN6HrPjb8rnm93NhDkGGe5D/opg26Io3B7XjJNSMKdDrtYaDS7rp USpQ5a/pdBT1ZsNpZ9oN553wfPS5czaPBp35oB+Gs+nwbNa/+O2BTzeMiaJuIl41kx0WX03TIidK aJGZEyIKvxrLvhQ/qZIid5O5G9TjfYMZaCsYDaIojAInXIgXonSnQBMtLDUTlzC1wPLbxjUVPiQM VTO3JOHTwVYBTFsTmztM6j8AAAD//wMAUEsDBBQABgAIAAAAIQBsGkx7BAMAAKcGAAAVAAAAcHB0 L3NsaWRlcy9zbGlkZTUueG1srFXbUtswEH3vTP9Bo3djJ77E9hAY7JJOO2lIG/gAYSvEYEuqpISk DP/elRyRUuiUzvTFF1m7e87Zo/Xx6bZr0YZK1XA2xoOjACPKKl437GaMry4nXoqR0oTVpOWMjvGO Knx68v7dschVWyOIZionY7zSWuS+r6oV7Yg64oIy+LbksiMaXuWNX0tyD1m71h8GQeJ3pGF4Hy/f Es+Xy6aiH3i17ijTfRJJW6IBuVo1Qrls4i3ZhKQK0tjoZ5BOgFm1aGtzV+JSUmqe2OajFAsxl/bz bDOXqKlBL4wY6UAW7O8/7LfZVwbb4MH/LfzGZSL5dim7k2OSAze0HWMQf2euEERyutWo6herw2q1 unhlb7U6f2W37woAgqeihlXP6CWd0NEpOdOgDpq3pKIr3tZUouETxz6QQKIpr+4UYhxYGzF6stVs 41IbBUwxsQK5gIvb0q9bYdxWZcV1iJ8kGcaDKAl6YYZZMIqy6Lk8URKlYCiMjEhJGqfwbHC4TFCk Ty1yvS14vTPaXsPd9obkrdILvWup1RyUITkAQR2RU9uPhtUghHm0cesZnII+/R4v8CO5hJC7ddd0 /LaxrmiJOT+UeVcLjEirp/b9lnif5z18ffJ1TZX1LoLThSreGVurU4NcW/w2M2X1nEjy7fUCfcJD gb7gHp91nuNsZTCt+HP3I9f9RdvUFM3W3TW0/VcLhAY7HA/X4H+0gN4JOCowNiA1TJUfY/x9TaSm Eu/dYS1mXWFs88Ietrgj9JcmLmE4mRP6UMZpFodZ5IVlWMIlKrw0CGMvmwzPJ2flIEuK4BEjhw2Y M0DnmvqGPsaHjkFRE/ife2Zb5wYRTIWpAn8IOx/WEuz2UBRZMizTwisG0cSLPmQj72ySxN4kDqOo LNKzMjx/BEpiEOWVpHbmfXKzGxZfzMuuqSRXfKmPwJZ+P3h9we+pFLyxs3cQ7Af4hrRjPBwEYTQa ZaPEHj2LzfbPoQUKbqZWrfxCxMXGuht+FdD+0i4J+DkY58LWwxbDHUT9CQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/ EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2u tiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu +wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6 Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAABwcHQv c2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBQH8PvB3kHO/WKS tukHNb0Zg8KuRvcAEk8+WKKidixvPykMEiiOQsCbgIrn/Pgr5nj6GXryjcZ2SjLIkhQIykqJTjYM Pi9vLzsg1nEpeK8kMhjRwql8fjp+YM+d32TbTlviq0jLoHVOHyi1VYsDt4nSKP1KrczAnR+ahmpe ffEGaZ6mBTXTGlDOapKzYGDOwve/jNp3/r+2quuuwldVXQeU7k4LavtO4Dsf1dX5stw06BgkyXTe Tge7xPOB3petYspWIdk2pmwbkmX5kjTnrxnODvI2Q2/fLORYlPHorcpDsmzJgB6VBTMrYsqKYGZx QwumtomZ2iaYmn/r4z2tWRqyrWPS1iHZPqZs/yejs99v+QsAAP//AwBQSwMEFAAGAAgAAAAhAITM vG4yCAAAjzAAACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsW+9u4zYS/35A 30FQPx60tv5aMtYpYm/c20O6F2zSB6AlOtZGlnQUnSYtCuw79A36Fu19u0fZJ7mZISlbSZxkm2Qv XgQIbImkhuT8fjOcGTmvv7tYFtY5F01elSPbfdW3LV6mVZaXpyP7x5OpE9tWI1mZsaIq+ci+5I39 3d43f3tdD5si+4E1kgsLZJTNkI3shZT1sNdr0gVfsuZVVfMS+uaVWDIJt+K0lwn2E8heFj2v3496 S5aXtn5e3Of5aj7PU/6mSldLXkolRPCCSVh/s8jrxkir7yOtFrwBMfR0Z0l7sL/0uMjwe3aqPt/z uZVnF6Clft+1916zIe2TTwphnbNiZM9OXbu397qHj8BgfYUPN/WJ4ByvyvPvRX1cHwm8Sd+dHwmQ CSJtq2RL0C8KoA49jG5LGKYEdx4/NZLY8GIulrgiUI8FKwQUL/ETHmJDfiGtVDWm69Z08a8bxqaL gxtG98wEsLV2UtyV2tH17XhmOye5LLh1VLCUL6oiA66QimiH6jHQYn1YpWeNVVawZ1SF2iooxwjG /eNU9cKSlzVoSaJYPU51wsrKdnxD+jWLbrUShAMgHanGGwSRH3f1E3teEmE/asl1A78PN7iWtaBa NPJ7Xi0tvBjZgqeSiMDODxuphpohhL5aSD2UF+Mqu0QwZvANmIPFwfOLSvxsW8XbshnZiRsEMLek G1qpbYnNnlmnRxaTCigHT7AyBTkjO5WC1lKCte2vZDXP9YrUlDh50chjeVlwogWAx4agVviABZ2t lvmy+pATFQuG1i+Fc/Ie5BfykO4/MOefR0plcm9S5OmZJSuLZ7m0tB8gWMBdwBSoNUm6oyl4mR0x wd7fPJOSvJ6Jl86Px1r1sEzA1igQLhXrtnPPb7mHxN+knociH0o91Kat/QAtEYmH9PxMBrpANWQj YWFMtEPBIPTCJPK1HoyFG349Iwoihz6LdWCeVnFO9KXtPzILUZtEwqbDQmAkcV59mCWQu3mAIRzz tCozq+DnvLjHdMTBB0x3ssjF/Wcj8jxgtmm1EnJx780Fis1/Gc5pPr9xNjjDvpz/CIz/eMNk9+gi bT7Uf2QSAqqfwfezYq79CHGC3Mdf8CORH8LfFT/iub7fHmV+FLpe+PzdSOckI79gzis6u84LF/0G K04hUC1sbMv4HE8UVKeLvhTbmqrIs2leFHSDgeg6QJMXKm6TeSlVyDYI14d8G83RsbUhBxyHmok6 wHHhQtS1PlBxLnIr8yKjeO6XMHH7g7EfOdPYGzjJm2DqjA+8vhP29/cPpuPYi5P+r3DcUziTAdNk vuR6dXtuvxdBaOuGa4cCgnGSL2gHobGDaVVhkL95kpKhP9QS5hCwEHb/XjEBM2hrUAfe55yqvusF JrC72RziJPyqzcHEfs/PIL4gYSND2GPwANx6t1rOrtCWnOBDaQtpL4i+iblkFZ/lx6Mw9G9n7tfu yFXO8vx42zrySQjOw08Cx5/4E/gIxk7c90MnmXoH0/2Jm0TjtSNvkHklsAN9tdz79PGPbz99/POp vTglRabAAMEv5KKY52AYvBKQ0f0yHieRN4nHztiFcyh4kwyc/WkUOtPQD4LJON6f+Ae/wpprNxim glM55G2myzLQeK2UssxTUTXVXL5Kq2VP1WR6dfUTF3UFZyueXX1d26HKiB8GUZD4SRJRGEJro4zJ rBa2YMotaSF+YLUFxRQ45iUURuDUHtnZGVzNTj1sg+qCvICr7AyuWJpCBQdG6AvTAv2qpR3jmxbI EFUXbExfmJbQtMDpp7oi0wLuZVHk5RkoA79sa14V/1AN5go3R3WxQ3ZZreTbTCMBLsO0UHTgucEg iH1QCeT4Q6z/iLeZLoxsGwsh3nqszmS3jgVdtXJ11Lp1LOinHavP9a1jQXPtWO1Mt46FOLodS7B3 NNPRQwjabscOrmmxOxZwaMdSBecWuYONsckdcqHQ2cp1KZ6+RXAHOFOx2lCFBn4xtxaZoDINRDv0 nUHdR0uXF1SNaZA0VDqhW3QdOsbUwS6e7ha4yBM2O4ZQ15SxhFQFIM4Oy7EAXgLqWAgt9S0QZgGF G6i2Hq3KFKbVRcs6HWNxEgtv6VGqA2FaEgS60KZ7Z6t3UPGlOFy7506NCINuqFjBJGdcYOn4vgE4 SMR5NsN0WjXFwnMoFI7svy8/OIVEvCDiZVc6OFMdaXOlI22wY1uw3lUxlGihjnNN30smDke2H3gJ biwvwZmD3hzTYHKPpwYDVKkqQ1cAmVaQt2DKoNS0L3JWKGXMVpMFE1YKHyP708ffVes23FTM8RS4 ldtwK50tuJXOrbiRLXiY+ClsBoANusIWGy8OIYkDb63zwmePzW+3Y+PFT2VTj4gNAqL9lL/GxtTM N8DxYsq7dgacOwzHezKH94jgICIanGADHF1v3mFw7rIcdJpPcho9IjiIiAYnXIPj9cMBUWvt1nbL cv77nzu82i5gg4BobKINbEI3ICe2q9jcGQ5guPHsDQcR0eAMNsBJBi4dmC/gmF8hYJH7XjH2I3o1 RESDE6/BUWFzJ1jbLa/2dVgOIqLBSTbAieOISo8vlvP/tBxEhCphG/loPazkgos2O4U07khBqBM6 9fuM9vcYKuXVQ0zpQKVLT5IYbUsrlSfeybTS1FQeP1HZaWXdnOfRT5VemHX1rfCWvMsf4E99nqJA sdPUujkRcuHFOMVzL4ZIv22geia49C2pCYVTL9y6aolbcoVBoAqfL9zqcGtL8A7BIZUkXrTV0daW aDoKBy9e/vrLlza83Yxo4WXv+tUXvrw2/0iw9z8AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EK wjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E 63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKa O/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ 3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0 A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+X i+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa /WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWag CVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUz cqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQB8MrCKKwQAAFUNAAAi AAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbLxX3W7bNhS+H7B3ILRrRf+yLcQu LMUaVqSpUbu7ZyU6VkOJHEW79ooCfa3tcfokO6REp0k8zKvb3MiWeHh+vvOdw8PLF7uaoi0RbcWa seVduBYiTcHKqrkdW2+XuT20UCtxU2LKGjK29qS1Xkx+/umSJy0tr/GebSQCHU2b4LG1lpInjtMW a1Lj9oJx0sDaiokaS3gVt04p8AfQXVPHd93YqXHVWP1+ccp+tlpVBblixaYmjeyUCEKxBP/bdcVb o42foo0L0oIavfuhS3LPIVoARi4rScm0KZc7C2l5sYUVz5oABMWClqjBNXz4HUSrAlOk5REghpZk J7VYy5eCELWh2f4q+ILPhd59s50LVJVKW6/FcvqFXky/NiAGf5xH22+NJpzsVqKeXOIE0EG7sQVJ 3KsnbMIJOIGK7mNx/7VYvz4iW6xnR6QdYwA8OBiF/PMuoqfh+CacR6B4h/C6PRh0XLPirkUNg4AV Dl2cxc3WaFXBKzt8jbqcSJUPCzFRQea6FPW7OlENk9ndaqiN/weA4tgfhW4Hkz8I42D4ECvfjQZ6 XSEWDSMv8iNtxGgCI51qnshdysq9Qvod/EJCFWnGFsEq+E4tbeVC7inR+QDUcAIhwQOE7zZ1VbP3 leYAxarqpLCXbyyEqbzW7++x/XLeKZKTjFbFHZIMkbKS6BVuJRFIQwJlCiYuIVkSuNKbIE05xwK/ OW6p03xviTT220UfJ7gJQZrgdLwqDf+e9OBp0hX15hQXZM1oCX76SjdUjcnuN+Vfofwo/VBDQHBD ntNpEEYD6EK6WI6xIHa90VCt/ygWADkR3dJDqX5nVij4NSnaB6wAbmgOdg/jgkbvDGIuSMGg51Gy JfQEc5oKZ5hbritxurWgK59vxjdnGyHXJwcXnmuuWh21Bs38+eo5NPV8hSV5UMYazXPLuJQwWPwJ hzSmK6svYH1i6f6ter7+83Uj183DdCTTbnVPfdpgV3Awq5P1YzjNplfBzLWDNPft0A1n9sgdzmx/ FAVxnOah60WfrP5sKSFUWdVEne6qj3quE8OM4UX3jAbFau0ZExGZROSMqW7/dUfVTDs3FSspulz8 scECLJh0/EdD/T/peEa4YgPXglYlQTeb+t0j0PRRfi5oMP2C6qO46d72nWmcRUMg7Ci0gyzI4BGm 9tANInuU+7N8mnmjOHUPNG5V5A1417H4y+e/fvny+e8fzWE9I5hBF86e6xYGEa7nz42AAedjmo5i PxumduqFuR1ejQb2NI8jO4+CMMzS4TQLZp/AZ+6FSSGInsp/K/vbAXx8MtHXVSFYy1byomC1010N HM4+EMFZpW8HUMDdFWOL4ZgNPH/guYN4EOshR/um+4zxFkJQI70eUqh4hfnrLTQinMBlBuoi0584 XF+A+kr0XkTFbq5Dk38AAAD//wMAUEsDBBQABgAIAAAAIQDNsYJW5AMAAHUMAAAiAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbLxX3W7bNhS+H7B3ILRrRZIt2ZYQu4gda9iQpkbt 7p6l6JgNJWok7dorCvS1tsfpk/SQNJOm8QAvznIj29Th+fm+8+fzV9uaow2ViolmGCRncYBoQ0TF mpth8G5RhoMAKY2bCnPR0GGwoyp4Nfr5p/O2ULy6wjux1gh0NKrAw2CldVtEkSIrWmN1JlrawLul kDXW8FPeRJXEH0F3zaNOHPeiGrMm2N+Xx9wXyyUj9FKQdU0b7ZRIyrEG/9WKtcpra4/R1kqqQI29 /dAlvWshWgBGL7YBsnJyAydJMILQyZxXqME1HCyY5hQBQOgPEGYEc7SgW23FVLuQlJoLzeZX2c7b mbS3rzcziVhltO21BNH+xV7M/mxADL5EP1y/8ZpwsV3KenSOC0AFbYcBkLczT7iEC3ACEXdI7k/J 6s0BWbKaHpCOvAHw4M4o8N66iB6H0/HhOFCSu6icKIarV4LcKtQIiNOE78Ij1xuvzMRs1Lcr5CjQ Bt+9nHtp8fDyCjC1YOntWFQ7E/h7+LSHuOBKz/WOUwsIuI0LUA4PgP92XbNafGCWBI5NumsZLt4G CHN9ZX9/wOHvM2MaF3o04YzcIi0QrZhGr7HSVCLrHNQHmDgHtDSQtTdBm2qGJX572JLTfG+JNuG7 uQ0SF+AmROjDga8O739HvetRf5CAaMYxoSvBK/CzY3RD2nqcn8SEwTVAQjKoGFcaASQxZJin8b/Q Y3oOaKHYOO0wfkwWcIv4ht+l9DOTZyrEcqcekAcU2lRxD++CDfKE/JlTIqBJcLqh/AhzlrETzC1W TB5vresYeDK+pVhLvTo6uPRUc2x50Bo0vZcru9SX3SXW9EG1WTRPrbZKw+D9C4YY5ktfZ7az2/Zn muRJfXAJA8xMoE8XWRx3pnkeDvKLfpgmaRzmebcMyzJN+v1sWpbT5HOwb8YVhKpZTc0UNO0uiaMe zOAku89oUGzevSARmSeiFMI05e8bn820U6lYaum4+HONJVjwdDyl79lp8rjTvSBcPQ/XnLOKout1 /f4H0LLnmBawHYLqg7jZ3vbMaTzJBnnWzdOwO+lO4JGOw0HczcK87EzLi0mS98bxXRorE3kD3rks /vrl71++fvnn/85hO8r9Qgiz50rBvtDaPW0tYQ/5NB7nvc5kMA7HSVqG6WXeDy/KXhaWWTdNJ+PB xaQ7/Qw+t0laEEnt1vpbtd+e4fDRxlszIoUSS31GRB251TlqxUcqW8Hs9gwF7FbwDYYxmySDfieJ 007fZAD4C176T+stHJnV1+4SXL7G7ZsNNCJcwLIPdTGxRy2s9+42uRcxsfu/C6NvAAAA//8DAFBL AwQUAAYACAAAACEAOlaEeckDAAA9DAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQy LnhtbLxW3W6bSBS+X6nvMKLXBDDYARS7MtistkpTq3YfYAJDIBkYdmZM7a0q9bV2H6dPsmcGSJrW ldw6zQ02w5lzzved34tXu4qilnBRsnpqOGe2gUidsqysb6bG+01i+gYSEtcZpqwmU2NPhPFq9uKP iyYUNLvEe7aVCHTUIsRTo5CyCS1LpAWpsDhjDanhW854hSW88hsr4/gD6K6oNbLtiVXhsjb6+/yY +yzPy5QsWLqtSC07JZxQLMF/UZSNGLQ1x2hrOBGgRt9+7JLcN4CWXd8aSAvxFl4dYwa40zXNUI0r ONiUkhIE7KCY1RI0aQHRbDghSrRu/+TNullxfe+qXXFUZkpPf9+w+g+9mH6tQQz+WN9cvxk04XCX 82p2gUMgA+2mBsRsr55wCYdkJ1HaHaYPp2nx9oBsWiwPSFuDAfDg3iiEu+kQfQ9nNMDp6HDuUXWi GK5esvROoJoBTgW/g5detYMyhVmpbwrUMS8Vs71c91HzMcgL4FSTJXcRy/YK+DX86kMcUiHXck+J JgTcxiEohwfQf7etyordljoIFKssl9zcvDMQpvJSv99i8/VKmcahnMW0TO+QZIhkpURvsJCEI+0c lAWYuAC2JASrN0HqbIU5fnfYUqf5wRKpzfdrDRKH4CYgHODA347vH7PuDqz3qYdWFKekYDQDD0dK K6TqwPBPxqDMIIOGMD0B/RAtRFt6n6RPHA6V8zoa4lE4ICg6+N1jcEHDOiEj1iRlUPCUtIQeYU5H 4gRzm6Lkx1tzu7z9ZX4TtuWyOBqcd6q5Mj9oDdrY8xWSNxTSAkvyqIo0m79eRV0nyyRM0H9gGmGa G9D+VWXpXq0bmmp7J3W2HIaRmikf7bmbRHaQmPHCH5tu4sWm7y4WZrR0bH++DJJkvvhk9O01A6iy rIiaaKqBObY1gWHqjB8yGhSrb88YiPEQiIQx1Wa/bmg6004NRS55F4u/t5iDhSEcT9jpnpGuyUDX mpYZQVfb6vob0sanTYEuf2HNA9UHedO97YnTOB77wdgNPNON3RgeXmT6tjs2g2S0TOaxE0wi+z6N hUJeg3ddFn/5/O/LL5//+905rIfzsOLB7LkUsAE0evPactgsPkZRMBnFfmRGjpeY3iI4N+fJZGwm Y9fz4sifx+7yE/jcOF6YcqLXz7+yfg2Gw+9W16pMORMsl2cpq6xuB7Ya9oHwhpV6DYYC7nbpFsOY DRzvfDTxz3UDA3fBSd1mBmfhSG2xekWg/A1u3rbQh3AISzuURayPGljTYYlQog8iCvqw9s/+BwAA //8DAFBLAwQUAAYACAAAACEAuUnXD64EAABsEQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxLnhtbMxY227bRhB9L9B/INhnmvcrbAUSbRUtHMeInA9YkyuL8fLS5UqRGgTIb7Wfky/J zJA05URpjdYJ9CKRy9nZM3Nml2d4+mJbCm3DZVvU1Zlun1i6xquszovq7kx/czM3Il1rFatyJuqK n+k73uovJj//dNokrcgv2a5eKw18VG3CzvSVUk1imm224iVrT+qGV/BsWcuSKbiVd2Yu2TvwXQrT sazALFlR6f18+ZT59XJZZPy8ztYlr1TnRHLBFOBvV0XTDt6ap3hrJG/BDc1+DEntGohWFUpwXSMz uYEBW59A5NlC5FrFShi4QQttIYqc06O2uZGco1G1+VU2i+Za0oyrzbXUihw99DN1s3/Qm9FtBWZw YX4x/W7wxJLtUpaTU5ZAIrTtmQ587fAXJrGEb5WWdYPZOJqtXh2wzVYXB6zNYQFA8LAoUN10EX0d jjOE0yXCfoiqM2Uw9bLO7lutqiFODL8LL7vaDM4wZnTfrLQu65mS5K037Z5TSoYpLaV1wPqQjCDy I6vLiGO7luf4j/MShqHjoQFmx/ZCy+os9qPuXDeJ2s7qfIdZvYV/YoUlolULtROcsg05YQkghx/g 9n5dFmX9tiCGBcPto6Rx81rXmFCXdP+WGb9fd4jUJBVFdq+pWuN5obSXrFVcaoqqqcUlTgGUgkro l+BVfs0ke314pc7zuBKvjDcLSh9LACbkbggHLjsyv02pO1C6WN92gBx0BWU/cPafWG3Xtx2rsA2g RodCeDq7thvaQU+vG0UBHCCP6Q2AW+Kf6A19B62x3IZCoeC7YhvycZBe5FRshA1VppVMXtI2K6oc jgq6ZOIODksoU9jy4GB9BUcjlUTOl8AQDrY1HAnzQgi6wfOQp0JqGyagLrZ4jAC9RaW6kdC3HqDS 4YnGBHzPD4Qx+IfLHh/6gUtnhOr5IWZGOz68CLLH6454Y9ujPXl8eBFkj9cb8T6U4fEBRpQ9YH8P cOREtC2ODzCi7AEHI2DHiWDnHmUJI8oecLgHOPTcI91ziLIHHI2AEe2RbjpE2QOO9wAHfkhn//HV MKKko3oQB4j+O2gDeH8ehTzwBnlwzhTXrgXL+KoWOagX9zlkQq6g4fgTxDsTS3iJkVTo3uKoiSnV eLGgrKOYIWk2CpyDL/RRry1BuaMMf+/OPGvqxrERzOaxAWIxNabhhWU409Sb+n4U+7H1Qe8VaQ6h qqLk/Xt7YltmAL2H7Y8qDRwj8T9Qp/kDEfO6RvG4T4X3HFQsQeAQF3+smYQVBjr+RbqRVvxHfTXS 8QPTFQzpomZNu1qXt18kjbqF/y1zRQ6uD+aNZDT1Mc9XxilWqht7hpu6Kfx4MyOyXN+I587FfJra cTAby7jFNrUCdFipavLp41+/fPr49/euYVLdQ1cMLeplC31NQ83qWkK/9H42iwMnjWbGzPbmhnce h8Z0HvjG3Hc9L51F09S9+ACYG9tLMsmpW/8t778awOBXnX5ZZLJu66U6yerS7D4ZmE39jsumBs2N O9fqPz2QII/CIHQt36YDDOACSGqaBrAwhC0/9UBCvmTNqw29o+AbB2wLkOow1MBXDahrNB1NMPTh K8nkMwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54 bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrF kxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZI vjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSw mHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQCVfkih/QQAAKMRAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDMueG1szFhdcts2EH7vTO/AYZ9pEvyXxlLGkq02HcfxRM4BYBKyGIMEC0KK1Exmcq32 ODlJdgFSP44zVRJX4xeJBBe73+5+Cyxw+mJVcmvJZFOIamCTE8+2WJWJvKjuBvbbm4mT2lajaJVT Lio2sNessV8Mf/3ltO43PL+ka7FQFuiomj4d2HOl6r7rNtmclbQ5ETWr4NtMyJIqeJV3bi7pe9Bd ctf3vNgtaVHZ7Xx5yHwxmxUZOxfZomSVMkok41QB/mZe1E2nrT5EWy1ZA2r07H1Ial2Dtw3L/mA0 ty0tKJcwROwh+J5NeW5VtISBKcvQuIWCTOqvTX0jGUO5avm7rKf1tdSTrpbX0ipyVNJOtt32Qyum XysQgwf3wfS7ThPtr2ayHJ7SPkTDWg1sSNoaf2ES7bOVsjIzmG1Hs/nrR2Sz+cUj0m5nABBsjEK+ a+PR1+74nTs3heLMIhuvjCiFqZciu2+sSoCf6L5xL7tadsrQZ1Rfzy0TeoWqWjnzUcejk290TDug m0gkvh+QQIcjDL245z0ISpIkfgiDFoaGBLHvJZE20mkCI0Z13VerkcjXGNJb+IfM0SqbC2Cpwhm0 zxs1VWsOeYbnJSeAyKL8DsqIAwtoP2ezNzDU/D2wwSTYvNWJzyhEgHLemm1nQrr3NUKwaR9CAj+g 5H5RFqV4V2gNnGJxKuncvLHBorrU7++o8+e1QaaGY15k95YSFssLZb2ijWLS0iGFagbMaE1pm9oE q/JrKinCfcSS0by1xCrn7bSFDzAhZF2odPQwjd/mCiTH1M0NEvWa04zNBYfKsXxUCaXVkeKHaIOp sqHGoAA6lv0Qe/yeFyfApL2S2mdP5HkkTdo4mIo8hD23Rudj7CmpvNTVXFQ5LEv4iAS4XVzB2quR 7HAK1k/zuRG8yCcF5yirl1425tJaUg4kWeF6BbkuKmVGEoCtiwIYsBHWTNjRA9+MJUNLQ27UA2z1 kecGaRglgALCfQBckh4RLmJs4QZbuD0Ca8KhcOMjwkWMLdxwC5cECUEUh4UXPUMdO1ncSfDTsgFB tnijHbypn2KSnx9eBNnijbd4fT+F8D5HvAiyxZvs4E3C4PByOyYfEGSLN93iRbCH19sx8SLIFm9v B28cJc+z3hCkWYl3Wg7dICB6WJM3zZ926+kaBtyidb/Q7DUMsD18974fdvv+OVVsb9/Xm+zP7vu5 gnMKdFpzymfd/m+2OeyidfjwYaojaXo83W10nUvX5Oldttub9YuO8wzafWzcP5z7yeg8IcQh4cXE CSZh4KTj0ZlDCDlLJqlPLrzwo932sDm4qoqStXvwkHhuDEcWEm2jCYqRiUdswKIuERMhsCvcbcHC p2jBZkqaXPy1oBIsdOn4j37se9JxxHDFXbim0GUx62pR3j4Imj5A/Cx/4TANqh+Nm+6LobN8ShqP o7QXBb3QCcbBGH7CkZN6QeT0Jv7F5GxMevHI29C4Qc8rQIdMVcPPn/757fOnf/9vDuteujtHw0J0 2cCBpdbH24WEg9CH0agX++N05IxIOHHC817inE3iyJlEQRiOR+nZOLj4CJhrEvYzyfQh/2XeXjbA 4FcXBGWRSdGImTrJROmamwa3Fu+ZrAX0z1i5XntjoZvrKIhSP/Yjc4LU0PRpqAMLHuA9gT7UcPmK 1q+Xen2GqxEoC+jRYaiGyxBgPopuRdD17nJl+AUAAP//AwBQSwMEFAAGAAgAAAAhAKpBdwiTBAAA exMAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzsWNtu2zgQfV9g/4FQnxVd LMmSkKSwlWixizQJavcDGImOlVCilqSdeIsC/a3dz+mXdEiJuTp1bpunvNgSdTj3Gc5w++NlTdGS cFGxZsfytlwLkaZgZdWc7lhfprkdW0hI3JSYsobsWCsirI+7v/+23aaClgd4xRYSAY1GpHjHmkvZ po4jijmpsdhiLWng24zxGkt45adOyfEF0K6p47tu5NS4aqx+P3/MfjabVQXZY8WiJo3siHBCsQT5 xbxqhaHWPoZay4kAMnr3bZHkqgVt5QU7OjmzkMbxJax41i6oXkxoiRpcw8L0gqGMNRLI6E+inXJC FKhZ/sHbSXvM9Y7D5TFHVako9Dstp//Qw/RrAzB4cO5sPzWUcHo54/XuNk7BEuhyxwKHrdQvbMIp uZSo6BaL69VifrQGW8z316AdwwAkuGIKvm47je6r4xt1ppWkBHlXWnVQDFsPWHEuUMNAT6V+p15x uDTElM6KfDtHvdkVqR7XfdT2MHgBNtXGkpdjVq6U4ifwrxdxSoWcyBUl2iAgNk6BOPyA+c8XdVWz s0o7gWIV4pLb088WwlQe6PczbP91rFjjVO5mtCrOkWSIlJVEn7CQhCOp9RSKxTZYS4KzehakKY8x x5/Xc+ooX3Mijf1lopXEKYgJGhp14LGz98NWHxir96GHjikuyJzREiT0FVUIUmPhJ/pA/AOpg+nM gnCFWDIOe8ARylJ3QjIIh5DcOi69yHXVszaoic7AHcSwbiEVo0Hoh0k06A3RUdIG6GLC2GStixVv uqSezjGclmSmbK/k9+OOKbjmBgAe/TXY4CbWAAA7WIN1b2INALDBfax3SwYDAGy4CWsAgI02YQ0A sMNNWAMAbLwJawCATTZhO4CydZ97yjE69WAnAgpXBeqVU1FFlM5EcSsVQZKOu5bDiKAD+QXVYEIK 1pSIkiWhj2Cns/AF7Kbzij+em06gF3DL2YLL+aOVC7qMfrY782q2lhscYW9XRINfFVFt0FcrojoY 9CGmypp+uHmarSuiURC/V1E4ft6raPpeRZ9daN6r6Jqm91Vb0dBU0T0sya0+VB8Szy+h3SxQShhA 73Skup98uJrq7veXjaNuR3WLMINBTk1lX5PEH+17w8xORiPXHvpBZI9Gw9z243zs73t5Mor8b1Y/ oJSgqqxqoqZBNQJ4rhPBLOqF130BEFbf3vA4i4wjcsbUoHJzJAhfNhJ0rphJ3vni7wXmwMEMCBsm hKe44w3NNTTmmtCqJOhwUZ/cMVr0GkaDWxIgvdZuG5qCp9jtKoyzME7CQRLYg2yQwU8wtmN3ENpJ 7u/no8xLorF7FcZCad6AdF0U//j+74cf3//7v2NYT3fmkgQ6+AMBM3Sr7y4WHGbzr+NxEvlZPLbH XpDbwV4ytEd5FNp5OAiCbByPssH+N5C59YK04ETf3vxZ9rdIsHjv5qeuCs4Em8mtgtVOd4XktOyC 8JZV+hYJEri7ilpiGFb8OBpC+5XooVRLpns2IysooC6A9IxN+SfcHi31+QRXXpAVmV5q4ZILHKig 1xClubk02/0JAAD//wMAUEsDBBQABgAIAAAAIQDhcRu46wUAAGwdAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDUueG1s7FnbbttGEH0v0H8g2GdG4l0SLAeRbBUtHMeIlA9Yk6uICcll lyvZbhAgv9V+Tr6kM0OuRN0cWU6DAtWLxMvw7FwPhztnL++z1FhwWSYi75v2i7Zp8DwScZK/75vv JiOrYxqlYnnMUpHzvvnAS/Pl+c8/nRW9Mo2v2IOYKwMw8rLH+uZMqaLXapXRjGesfCEKnsO9qZAZ U3Aq37diye4AO0tbTrsdtDKW5Gb9vDzkeTGdJhG/ENE847mqQCRPmQL9y1lSlBqtOAStkLwEGHp6 XSX1UIC16k5M7id34s3tB9MgYbmAy7Z5DvZH4zQ2cpbBhaHICiaTUuR0pywmknOUyRe/ymJc3Eh6 4HpxI40kRoD6QbNV36jF6DQHMThobTz+XiOx3v1UZudnrAfeMO77JgTtAX/hIdbj98qIqovR6mo0 e7NDNppd7pBu6QVAg+WiEO+ismjbHEebM0lUyg17aVUlyuDRKxF9LI1cgJ1ofmVedL3QYGgzwhcz o3Y9QtVy1U3yh5YvwafkLHU/EPEDGn4L/3SR9dJSjdVDCiGA40VqUwBYL+bTt5VrG5fB2qY4GMl6 oAr8QLA+zrMkEx8SClnKsCiUtCZvTYOl6orOPzDr9xtUlPXU+TBNoo+GEgaPE2W8ZqXi0lDklRIV OoPVFIS2XoLn8Q2TDJTatVKFvFqJ59a7MbmE9UBN8Ic2Hg6r6OyPkbuMESbITcoiPhNpDOo5CAnp rINxVLjQ+SbkNiSeju6eqKGjNvLX80NgA0pi23d923Yrf+pU9tpe2+4AE2FCB243DEjnZp5iPqAV 2iM6HQyWRzMB1HJbQTZDXWeGkTF5RUWU5DGwAR6ikrfza6A8CmyVOEb5Z990PNT0VpvZSCQ6dECP GlBbdRBqexsVoVAPUNNdoXZtjzQ4BNXubKMiVI3qrVBtN7QDFD4IliTXXYBYNazfgO04HdLhWFjE qmGDFazjdECFZ2iLWDVs2IANPZfy8FhtEauG7axgEfPwkO3wLWLVsN0GbOCHzwoZYhEVNWuC6A8X gaxbvlJo9e9Hh1jWxIblGh1COT+Z1TzNakORK6jdNWIjFjme2LDaZyyd1rRWUQ6+k8lteDAmDyL3 VgHaT2uOHXqd0H+E1tyub0OxoMQhvEa01Azc1mtuxVYVZEMADjW5NJkNS2opqwVAVlNGQ5aYZSmr BUBW80BTFrN0KasFQFYX915ZLQCyumL3ymoBkNVluFdWC4Csrq29sloAZKuC0W0E+ZdIc2nbf7Oi qKzgRxc1vZ+f0eOMeSTy2Ej5gqc7CnhzOaqbZyw3mSXy8NXqzuFoxhqJuVSzg43zqoo+frlkunM1 aON/XGvoaxKdbLaGZN7xDFp18lVriGz6x5xJaIhrQqVQUVN/MKEGnt92QF1oA/c1inYINHtqFPvm qVGEZv3UKPZN99Qowlej5rhdjSL1ZcfT3Da1EW8eTW37msUVtZ2aRfT5evN1ahZxd+qA3ahHP782 u7dTs/jIbt//sVkMNZFeMMXXPrcD7IWPZ9GqWYwVzBvWP7zt6utx75c3rbq57wcXV/u6dEI7G1PY sscN+E++N3Q83760LpzAtS47XtcaDPzQctzQDQe+E4bO4LNZ70XHYKpKMo77/rh/a7dbAYwebH/1 +QPAeO8Hdu2wHVoNH0ZC4C5zc0s3/B6hmCro1LffbfY39nefEo4f6K6udtc4TWJuXM+z2w2n0d7L c/MXhmIAvdNv39hAeorflmk89Dtd3+16ljt0h/DjDaxO2/Wt7si5HL0a2t1g0F6mcYmW56BdlcVf v/z1y9cvf//bOUyzCT0Pg3fPVQkDkILGVHMJg5VPg0E3cIadgTWwvZHlXXRD69Uo8K2R73recNB5 NXQvP4POhe31IslpWPdbXA8N4eLWoC9LIilKMVUvIpG1qolhqxB3XBYioaEhFHA1eVww2OW0gQLc wLNdHSHQksYrWlswAYd9xG6pfM2KNwv64ocZJ1TekC4VMNWEEKLoSgRt11PS838AAAD//wMAUEsD BBQABgAIAAAAIQDUWPs2HQUAAJkSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDku eG1svFjbcts2EH3vTP+Bwz4zFO+XsZyxaKnTjONoYuUDYBKyGPNWEJKlZjKT32o/J1/SXZAQRVtu ZEX1i0SCwMHu4uzBAmdv13mmrCir07IYqsabgarQIi6TtLgbqp9mE81XlZqTIiFZWdChuqG1+vb8 11/OqrDOkiuyKZdcAYyiDslQXXBehbpexwuak/pNWdECvs1LlhMOr+xOTxh5AOw8083BwNVzkhZq O54dMr6cz9OYXpbxMqcFb0AYzQgH++tFWtUSrToErWK0Bhgxum8S31TgbZXGs7WqiG5sBQ2Geg6e xzdZohQkh4ZpGvMlo8pDyhdKRCq0Q/SpqxmjFHsXq99ZdVNNmRh6vZoyJU0QqoVQ9fZD2028FtAN HvRHw+8kEgnXc5afn5EQIqKshyos3AZ/YRAJ6ZorcdMYd63x4sOevvFivKe3LicAC7aTwppXjUdP 3TGlO7OUZ1Qxtl41XQkMvSrj+1opSvAT3W/ci69XEgx9RvhqoTTh5wjV9ms+injI/rWIqTR0GwnD C0zTB96C57YPLBs8iopj+64NjQrGxnFdz/LFJBIJJmmgq5CvR2WywZDewj+sHCniRQlMvcURJMxq fsM3GawzPK8yAyxSSHYHqZQBC0iY0PlHaKr/GqrAd5jyVnq+7Q+L3MeBEJMQAgE/MPR+mad5+TkV hMkIpiVn2uyjCvPwK/H+mWjvpo09/DzK0vhe4aVCk5Qr70nNKVNEICGPwVKcjYs5xRS0SKaEETRy z0wNcjcTLbRPN22swEwIlAyQiBku3vMMsSRDZM5MMxLTRZklYKGJqJBZkg1H8QXSVYXcAuJLdh3H GtcwPc9pIipTqUca2zCQWW0kmkz8D9Y8S5WcsCuRummRgA7hI6777fIaxFaM2iGQBQxqZ2yphn3h 0UTWNVC242Ev5RA8s/OgBWnxrA4vMGyRKQfhYU8wGum8yhCkxbM7PMPyDMzHwwzEjNkCIkoL6OwA +pDqxwEiSgvodoAgHWDgURYiSgvo7QB6tli5I1xGlBbQ7wAR7fBF6cUQUVrAYAfQdbwjFwVR9gvY KwqLLYVlhsm6qyoW0udnVQWVH4ogkPAFyeatwAi9gpQ/TmAcCzadZtfpNuuewvgD2KSaSQ7YloRU 7NuLXiQwRi+BcS9ruXKkwBg9wUKQFu9IgTF6XD6BwAQn1pce3gnkpYd3AnXp4Z1AXHp4J9CWHt7z 0oLKBTvMttoVtDpdrYQiIkqlulcrwbb24pLHkcp0STjtKZN9CmVK+BNdMpod81lhEnooizZZ1fbk Q7yIGnQOpxw8qXyB3SHwJ5ajjS5sTxv4tqNdBOOJdjm23fEIqm0zGnxV26I9AVd5mlM8KmGpaQx0 F85phtNFE4Dx2ytuEa5ciElZYkG8u0mIQu9nN4k5Z81a/LkkDGaQdegPCtGXLMcrhsuT4brJ0oQq 18v89lHQ3FPwF24QAHpv3H6wv74kblsaR44fOFZga1ZkRfBjjzR/AKwOJuZ4chEZgTvqaFyj5wVY 17D4+7e/f/v+7Z//m8PiECEvDkCIrmo4q1XiPL9kcAb8MhoFrhn5I21k2BPNvgw87WLiOtrEsWw7 GvkXkTX+CjZXhh3GjIqbjT+S9oYFGp/ciuRpzMq6nPM3cZnrzfWKXpUPlFVlKm5YIIGba5oVAc2F g4/jBYHtSqEBK8VJUFoLLuD9iKi7MvaeVB9WQqDhQgjyIhJNFVwBwRJi164L+i6vlM7/BQAA//8D AFBLAwQUAAYACAAAACEAoAmJl20FAAB6EwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ4LnhtbMxY627bNhT+P2DvQGi/FYu6WRbiFLESDxvSNKjdB6AlOlYiiRpFO/aKAn2t7XH6JDuk RN+izk7cBftjy/LHj+d+Dnn+bplnaEF5lbKib+Azy0C0iFmSFvd949N4aAYGqgQpEpKxgvaNFa2M dxc//3RehlWW3JAVmwsEHEUVkr4xE6IMO50qntGcVGespAX8N2U8JwJ+8vtOwskTcOdZx7Ysv5OT tDCa9fyY9Ww6TWN6xeJ5TgtRk3CaEQHyV7O0rDRbeQxbyWkFNGr1rkhiVYK2bPIwXhpIwfgCXmDj AjSPR1mCCpLDi4gVAhjQUypmKCKllENhqnLMKZXoYvErL0flHVdLbxd3HKWJpGoojE7zRwNTPwuA wUNnb/m9ZiLhcsrzi3MSgkXQsm+A41byExaRkC4FiuuX8eZtPPvQgo1n1y3ojt4AJFhvCj4va42e q2NrdcapyCjCa61qKIGlNyx+rFDBQE+pfq1efLvQZFJnSV/OUG1+IakaXP2nsofGV8qmWtC1JVyv C7GlzGF3Hcvbs4ljWYGDHQNJy2Ds2w1iW+OauQzFcsCSlbToBL7BcaSIZwwCdVLbOavESKwycDMJ s0WGQSBEsnvIpAyCgIQJnX6EV9WffQNEApkmWvE1HnwMz1s8YGESgh3gA5Y+zvM0Zw+pipeMyKwU 3Bx/NGAfcaN+PxDz97taHnERZWn8iARDNEkFek8qQTlSdoQ0BknlbkLtqbagRXJHOJFCtuxUM292 ooX5aaT8QUIQE5yhDQSPdWh8P0DA4rspc5eRmM5YloCEtmSFxNLB8MJwSRMIdh1Rx0eK43U96X2Z OW2h4mGMAVGHihd4Doa4kWGrY06pXQettoQOFZWH235t4mMvLBwZqjXlFgAe7Sa4t0Mo2MZqAGCd Fqy7jdUAwLotWBmaaxk0ALDeIawGANY/hNUAwHYPYTUAsMEhrAYAtncIWwPaEg5WImBYV9AfnICy IKv8q3YSECRR6V5/aBFUIJ9QA0Y0ZkWCMrqg2RHbqdw7YbvxLOXH76YS6ITdhmzOodUeq5wrA/uU 7dJp627QY9+udLq6dI5lHG3XTWXN19fNus3K3gZTHjSpGcmmBkwnUE1VVKh2K+ubehip9JKVXr7S NbCt72LX8XBdVDbDyE7jdf0etvyTqynKCb9Rw09aJDCHyUcp2mR+C+Oqcv1WAcU7RVF2a4mFtJe1 tKHS08NRfDvFe68gN3w97Mpd0VF8O4V4r2g3fNjpYv9Ywt6/FHbNF9iB7CtHCbjDt1f8Gz7bDkC8 1/DtNQjN13VVj3y5fHtNpOGTZEc7ZEffvUaj+Xyv+zp//D+bEWS6HmXUdCPHsu8PdZ6uTFdE0J3K pArvqZUpEc/qEq5HFXkuai1MkPMbDVqHMVUVVMedwjFOHsU++9bw+hIPHNMPcGB6vnttXlrOtel5 g6gXOL7rDYZfjOZUkoCqIs2pPAvKYRpbHR8Ootjb9Foglv+9YYvwtSOGjMmRf7tJeLIHnuqKqeC1 L/6YEw47NG0CH5i6X+KONzRXV5trlKUJRbfzfLJnNP9HGA2uSIC61W4H+utL7LYO48gLep7Tc00n ciL4cAdmYDme2Rva18PLCPf8gbUO40pqXoB0dRR/+/rXL9++/v1fx7CqKfpmBKaZmwpOo6W6sJhz OOV+Hgx6vh0FA3OA3aHpXvW65uXQ98yh57huNAguI+f6C8hcYjeMOVVXN78lzRUSvHx27ZOnMWcV m4qzmOWd+v6oU7InykuWqiskSOD6HmpB4ADgYMvGtttthhMlmxqAtLSggrwAUimV8fek/LBQcwTc eEFeROpVCXdc4EIJ3UCk7vrO7OIfAAAA//8DAFBLAwQUAAYACAAAACEAt+/XSRADAAB1BwAAIQAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbLxV/26bMBD+f9LeAbG/KeFnADWpAgnT pqyNlvYBXDANK9ie7aTJqkp9re1x+iQ7m9BubSdVWrd/wBx35/u+73w+PNq2jbHBXNSUjEznYGAa mBS0rMnFyDw7za3INIREpEQNJXhk7rAwj8Zv3xyyRDTlHO3oWhqQg4gEjcyVlCyxbVGscIvEAWWY wL+K8hZJ+OQXdsnRFeRuG9sdDEK7RTUx9/H8JfG0quoCT2mxbjGRXRKOGyShfrGqmeizsZdkYxwL SKOjfy9J7higPW8QuTQN7cY3YHDMMSAvlk1pENSCIdUeyijYKcdYrcjmPWdLtuDa93iz4EZdqth9 jGnvf+zd9CcBN1jYj8Iv+kwo2Va8HR+iBCgwtiMTlNqpJwShBG+lUXTG4sFarE6e8S1Ws2e87X4D qOB+U4WqQ/QUjtvDmSKJjUWDCryiTYm54dwD7KIQZJnT4lIYhAJkxUSHtDje9HkVfLUTWxkd9aWE xvsGIqKmMoE/AOdosJoh5awXfbwAujWPcpvScqc4OYe3NqKkEXIpdw3WXAEilFSgoBLlOnT96TCY ZdY0dSNr4vkTKw5S3womUTaL3cEwn4Q3Zl8UQJV1i1UboESOnYEdQg86wSHQJ6EknVgLQsoF4ugz aH+5buuWfql1B0C7wMH6gqyPC9NAjZzrb0yss6UmBSVQHiDrYcCyk+DPQni9EDmlEuj/VQr3NaSo JO+0+LpGHHbo5ehl7LT7Kznw/6PL7+laNnWJjeN1e/6INO81SIPpCKmf5U2Loul6vTbOgigOvNi3 vMzL4OGnVjTwAivO3Vk+yZw4TAf3bSwUcgLVdV18d/v93d3tj3/dw7qV+xkJA2su4MQwPbrWHE7H dZrGoZtFqZU6fm7503hoTfIwsPLA8/0sjSaZN7uBmpnjJwXHemp/KPe3BxifTPy2LjgVtJIHBW3t 7uqwGb3CnNFa3x5wgLsraIMaNWDcIAjjMBrqs6hr06exrxYgqNmvyi4a/gmxkw0MIpTAZQfnItMm Btfbfrw9uCjs/XU5/gkAAP//AwBQSwMEFAAGAAgAAAAhANfRM/ZXAwAA9AgAACEAAABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWy8VutO2zAU/j9p72Blv0OSJr1FtFMTyLSJS0XhAUzi 0oBje7bbtZuQeK3tcXiSHTs1MGDStDH+5GKfc3y+79y8+37dULQiUtWcjbxoJ/QQYSWvanYx8s5O C3/gIaUxqzDljIy8DVHe+/HbN7siVbQ6wBu+1AhsMJXikbfQWqRBoMoFabDa4YIw2Jtz2WANv/Ii qCT+ArYbGnTCsBc0uGbeVl/+iT6fz+uS7PFy2RCmWyOSUKzBf7WohXLWxJ9YE5IoMGO1f3VJbwSg 1bWm5JjRjYesqFzBYuSNAX05oxViuIGFUyOFrJjZUeJUEmK+2OqDFDMxlVbhaDWVqK6Mga2iF2w3 tmL2l4EYfASP1C+cJZyu57IZ7+IUuEDrkQch25gnKOGUrDUq28XyfrVcHD8jWy72n5EO3AHgwd2h BlWL6CmcjoPT8hDdoWpFMage8PJKIcYBp4HfwiuPVs6YwWzMiwV6QPxWrt20fDh5BZxasvQ649XG AD+Ht13EKVV6pjeUWELAbZyCcXgA/VfLpm74ZW2DQLFJci390xMPYaoP7P8l9j9NzdE41eOc1uUV 0hyRqtboECtNJLJZAVUBR+wCWxqCtT2CsGqKJT55/qTW8v1JhPlnMwsSp+AmIHRw4LPl+/esx471 PawJmlJckgWnFbjXMSYhQR29fxWASkPdf4UawnTuQdZCSkU2xWwcTLT+KSBzKB5TCt/CKJzke9HQ 38+Krl9ESeQPsm7mF5Nhvz+AzayfXXvbrKgAqq4bYirQ8B6FQQ9aQNS9DwMYNnuvGIjEBaLg3GTH w1DELxGKuZZtLD4vsYQTXDhcHb1AfbwiXV1H14zWFUFHy+b8EWnJS5AGwwlMP8ubrY8XTuO8Oxh2 42Hix3mcwyPJ/EEYd/1h0dkvJnk07GXhXRorg5yBd20W3958f3d78+N/57DtKW4ywZg4UNC4hB0Y SwkN8VuWDXudfJD5WZQUfrI37PuTogdF2Y2TJM8GkzzevwafRZSkpSR2aH6stsMbFp8M3KYuJVd8 rndK3gTt5A4E/0Kk4LUd3lDA7Q1ghenIi8NOJ4r6SeIyG7y0fcZ5CxDM2LXdjcpDLI5X0IhwCncN qIvcLgm4XUD/M6L3Iga7u62MfwIAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc4SPwQrCMBBE74L/EPZu 0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4 o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A 9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEA AP//AwBQSwMEFAAGAAgAAAAhACOPTBo6BAAAxw0AACUAAABwcHQvaGFuZG91dE1hc3RlcnMvaGFu ZG91dE1hc3RlcjEueG1s5FfvjtM4EP9+0r2Dlfuczf80jbZFbbcFTgtUFB7ATZwm1IlzjltaEBKv dTwOT8LYjnfbZQ/BwZ3E3Zd4PPaMZ8a/GU8uHxxqivaEdxVrRpZ34VqINBnLq2Yzsl6+WNiJhTqB mxxT1pCRdSSd9WD86y+XbVoCl+3EE9wJwhHoaboUj6xSiDZ1nC4rSY27C9aSBtYKxmssYMo3Ts7x a9BfU8d33dipcdVYvTz/GnlWFFVGrli2q0kjtBJOKBbgQ1dWbWe0tV+jreWkAzVK+sykMfiYrWgu x/VGf5+TAlX5ASLlup41vsSp8pPMKEd7TEfWeuNZzvjSkSKwuaekcNe+4IRIqtk/5O2qXXI5yZ7u lxx0gkoLNbiGGEsFaqHfpqYNbNOKz8Q3RhNODwWvpUUQHgQWwk0e5ReEcEoOAmWamd1ys/LZPXuz cn7PbsccAK7dHCq90h597o5v3HlEcA4AWVKckZJRSasYKRe1HISxvWbZtkMNA6dlLLSvEB2jWQZA ntWWSBxbCFOZc8Dmm5H1xw5zgGAvoveBlc2NaKdibRz4coT84cBLXAiejFMYDQCiSvGtdMs78ZCw GkliZHGSCYUEvL/uhDQbp2aLun59epuKw5TlR3kbaxjh0iHtQL5k/I2F6OOmG1lDLwzhaKEm6nAL 8dOV9dmKoDMGmOvvmHZiJY4UIIZTuqceOI0w3UBaU2VfTornwJIR82696ncqs081wL0CbJp8iTmW YttdXdXsVaVwSrEsD6+w/fvSgjPEtZqTxn656oMF4nAFxmUgNVD+Gi6BgcsVFuQMLL5U+b1gycU5 Vvos/mbMBEkSxh4Ye5tFJrf+i8jhfxc5Bc1VUXvrTecD318s7Ch257afhJGdDGaePfGC0J8N/GE8 n7wDyKuUzuHuRVWTRbXZcfJspxNLjD3XiaHOe5FMLqGwCgf8ywgNDUIXjMkX77SgBT8Co4W4U9A0 SBX+VT2TBVARpiZ+sbAlcRL5ANWzB+CnBCnCTQZlEl5X7cxpnfr5Kl1kcLSiVU7Q0129voOm8Eeg qaM5qL6v6ilIfBOgTqve/xFW318GF5E7ncWDoT0curEd+OGVPYm9gR0tZlPPnV/NYt+9KYOdBEYD lycrnBh/fP/nbx/ff/ina596pE2PCo8adDPy3ZXP247Du/92Oh3G/iyZ2lMvXNjh1XBgTxZxZC+i IAxn02QyC+bvwObWC9OME9VRP877zh6Yn3XjdZVx1rFCXGSsdnRb77TsNeEtq1RnD4Vf/x6o5noQ xoGfBEks8wPMBdPMqIwFlmnYM8qf4BZBOw7tj4DWWhyAyrdArTe+5EF/Kg5A5VugcJbBPwDs6AnD gXXNudkTGA70AHoJ/OoJw4kMB1JdL8WGE1uopFWzhVjIwUIFo480w1A6+csCQYOr2nh4F9SYQ7eo m9E7P1/jTwAAAP//AwBQSwMEFAAGAAgAAAAhALTPWBm7AAAAJAEAACwAAABwcHQvbm90ZXNNYXN0 ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0vYgIk16EaFXqR8Q 0m0abJOQRLF/b6AXC4KXhZll38zWzXueyAtDNM5yKGkBBK1yvbGaw727Hk5AYpK2l5OzyGHBCI3Y 7+obTjLlozgaH0mm2MhhTMmfGYtqxFlG6jzavBlcmGXKMmjmpXpIjawqiiML3wwQGyZpew6h7Usg 3eJz8n+2Gwaj8OLUc0abfkSwlHthBsqgMXGgdHXWWdHcFZio2eY38QEAAP//AwBQSwMEFAAGAAgA AAAhAJMKbXUTBwAA5x0AABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZzW8bRRS/I/E/jPbexk6c NInqVLFjt9CmjWK3qMfx7tg7zezOamacxDfUHpGQEAVxQeLGAQGVWolL+WsCRVCk/gu8mdld78Tj xinhQ9AcWu/s77157/c+5mOvXjtOGDokQlKeNoP65VqASBryiKajZnC33720HiCpcBphxlPSDCZE Bte23n3nKt5UMUkIAvlUbuJmECuVbS4tyRCGsbzMM5LCuyEXCVbwKEZLkcBHoDdhS8u12tpSgmka oBQnoPbOcEhDgvpaZbBVKO8weEyV1AMhEz2tmjgSBhsd1DVCTmSbCXSIWTOAeSJ+1CfHKkAMSwUv mkHN/AVLW1eX8GYuxNQc2Ypc1/zlcrlAdLBs5hSjQTlpvdvYuLJT6jcApmZxnU6n3amX+gwAhyF4 am2p6mx01+utQmcFZH/O6m7XVmsNF1/RvzJj80ar1VrdyG2xSg3I/mzM4Ndra43tZQdvQBa/OoNv tLbb7TUHb0AWvzaD717ZWGu4eAOKGU0PZtA6oN1urr2EDDm74YWvA3y9lsOnKMiGMrv0FEOeqnm5 luAHXHQBoIEMK5oiNcnIEIeQxW3M6EBQPQHeJLjyxg6FcmZIz4VkKGimmsH7GYaKmOp79fzbV8+f olfPn5w8fHby8IeTR49OHn5vdTmCN3A6qgq+/PqT37/8EP329KuXjz/z42UV//N3H/3046d+IFTQ 1KIXnz/55dmTF198/Os3jz3wbYEHVXifJkSi2+QI7fMEfDPEuJaTgTifRD/GtCqxnY4kTrGexaO/ o2IHfXuCGfbgWsRl8J6ADuIDXh8/cAzuxWKs8pA7nt2MEwe4yzlrceFl4aaeq0Jzf5yO/JOLcRW3 j/Ghb+42Tp34dsYZtE7qU9mOiWPmHsOpwiOSEoX0O35AiIev+5Q6vO7SUHDJhwrdp6iFqZeSPh04 2TQVukETiMvEZyDE2+Fm9x5qcebzeoccukioCsw8xvcJc2i8jscKJz6VfZywKuG3sIp9RvYmIqzi OlJBpEeEcdSJiJQ+mTsC/K0E/SZ0D3/Yd9kkcZFC0QOfzluY8ypyhx+0Y5xkPmyPpnEV+548gBTF aI8rH3yXuxWinyEOOJ0b7nuUOOE+uxvcpSPHpGmC6Ddj4YnldcKd/O1N2BAT02qgrzvtOqHp2969 cO/eFtRbPDdOdex5uNN9us1FRP/9bXoHj9M9ApUxu1a97dJvu3Twn+/S8+r54nvztB1Dp9Z7J7vp NlvwZO4OfEgZ66kJI7ek2YRLWISiLgxqOXP6JOWJLIvhp65kmMDBjQQ2Mkhw9QFVcS/GGWzg64FW MpK56pFEGZdwcDTDXt0aD4cAZY+dq/pAYjuHxGqXR3Z4RQ8X545SjbFqZA63xUQrWsGik61cyZWC b28yWV0btfBsdWOaaYrObKXLmmJzQAfKS9dgsGQTdjcI9kTA8hqc//XUcPDBjESadxujIiwmCn9N iHKvrSMxjogNkTNcYbNuYlek0Ix/2j2bI+djs2QNSDvbCJMW8/NnQZILBVOSQfB0NbG0WlssRUfN YGN1eTVAIc6awRCOvPAzySBoUu8HMRvBvVGohM3aM2vRFOnU4w1/VtXhFmNOwThlnAmpdrCMbQzN qzxULNUzWfuXVxs62S7GAU8zWcyKlXVIkX/MCgi1G1oyHJJQVYNdGdHc2ce8E/KxIqIXR0dowMZi H0P4gVPtT0Ql3FyYgtYPcM2m2Tav3N6ad5rq5ZbB2XHMshjn3VJf0xQVZ+Gmn5Q2mKeKeeCb13bj 3Pld0RV/Ua5U0/h/5opeDuAWYSXSEQjhlldgpCulGXChYg5dKItp2BWw7pveAdkCV7XwGsiHu2bz vyCH+n9bc1aHKWs4DKp9OkKCwnKiYkHIHrQlk31nKKvnS49VyXJFJqMq5srMmj0gh4T1dQ9c0z04 QDGkuukmeRswuNP55z7nFTQY6T1Ktd6cTlYunbYG/u6Niy1mcOrUXkLnb8F/aWK5uk9XPytvxIs1 suqIfjHdJTWKqnAWv42NfKo3NGGRBbiy1tqONePx8mphHERx1mMYLPczGdwFIf0PrH9UhMx+uNAL ap/vQ29F8B3C8ocgqy/prgYZpBuk/TWAfY8dtMmkVVlq852PZq1YrC94o1rOe4psbdki8T4n2eUm yp3OqcWLJDtn2OHajs2lGiJ7ukRhaFicQ0xgzBev6kcpPngAgd6B6/8xs5+pZAZPpg6yPWGya8Cj Sf6TSbvg2qzTZxiNZOk+GSIaHRfnj5IJW0L2U0mxRTZoLaYTrRRc8R0aXMEcr0XtalkKL58tXEqY maFll8LmUs2nAD6U5Y1bH+0Ab5us9VoXV8EUS/8MZQsY76fMe/JZlDJ7UHxtoN6AMnX8espypoC8 2cSDT50Cw9GrZ/ovLDo2003Kbv0BAAD//wMAUEsDBBQABgAIAAAAIQCTCm11EwcAAOcdAAAUAAAA cHB0L3RoZW1lL3RoZW1lMi54bWzsWc1vG0UUvyPxP4z23sZOnDSJ6lSxY7fQpo1it6jH8e7YO83s zmpmnMQ31B6RkBAFcUHixgEBlVqJS/lrAkVQpP4LvJnZXe/E48Yp4UPQHFrv7O+9ee/3PuZjr147 Thg6JEJSnjaD+uVagEga8oimo2Zwt9+9tB4gqXAaYcZT0gwmRAbXtt595yreVDFJCAL5VG7iZhAr lW0uLckQhrG8zDOSwrshFwlW8ChGS5HAR6A3YUvLtdraUoJpGqAUJ6D2znBIQ4L6WmWwVSjvMHhM ldQDIRM9rZo4EgYbHdQ1Qk5kmwl0iFkzgHkiftQnxypADEsFL5pBzfwFS1tXl/BmLsTUHNmKXNf8 5XK5QHSwbOYUo0E5ab3b2LiyU+o3AKZmcZ1Op92pl/oMAIcheGptqepsdNfrrUJnBWR/zupu11Zr DRdf0b8yY/NGq9Va3chtsUoNyP5szODXa2uN7WUHb0AWvzqDb7S22+01B29AFr82g+9e2VhruHgD ihlND2bQOqDdbq69hAw5u+GFrwN8vZbDpyjIhjK79BRDnqp5uZbgB1x0AaCBDCuaIjXJyBCHkMVt zOhAUD0B3iS48sYOhXJmSM+FZChopprB+xmGipjqe/X821fPn6JXz5+cPHx28vCHk0ePTh5+b3U5 gjdwOqoKvvz6k9+//BD99vSrl48/8+NlFf/zdx/99OOnfiBU0NSiF58/+eXZkxdffPzrN4898G2B B1V4nyZEotvkCO3zBHwzxLiWk4E4n0Q/xrQqsZ2OJE6xnsWjv6NiB317ghn24FrEZfCegA7iA14f P3AM7sVirPKQO57djBMHuMs5a3HhZeGmnqtCc3+cjvyTi3EVt4/xoW/uNk6d+HbGGbRO6lPZjolj 5h7DqcIjkhKF9Dt+QIiHr/uUOrzu0lBwyYcK3aeohamXkj4dONk0FbpBE4jLxGcgxNvhZvceanHm 83qHHLpIqArMPMb3CXNovI7HCic+lX2csCrht7CKfUb2JiKs4jpSQaRHhHHUiYiUPpk7AvytBP0m dA9/2HfZJHGRQtEDn85bmPMqcocftGOcZD5sj6ZxFfuePIAUxWiPKx98l7sVop8hDjidG+57lDjh Prsb3KUjx6Rpgug3Y+GJ5XXCnfztTdgQE9NqoK877Tqh6dvevXDv3hbUWzw3TnXsebjTfbrNRUT/ /W16B4/TPQKVMbtWve3Sb7t08J/v0vPq+eJ787QdQ6fWeye76TZb8GTuDnxIGeupCSO3pNmES1iE oi4Majlz+iTliSyL4aeuZJjAwY0ENjJIcPUBVXEvxhls4OuBVjKSueqRRBmXcHA0w17dGg+HAGWP nav6QGI7h8Rql0d2eEUPF+eOUo2xamQOt8VEK1rBopOtXMmVgm9vMlldG7XwbHVjmmmKzmyly5pi c0AHykvXYLBkE3Y3CPZEwPIanP/11HDwwYxEmncboyIsJgp/TYhyr60jMY6IDZEzXGGzbmJXpNCM f9o9myPnY7NkDUg72wiTFvPzZ0GSCwVTkkHwdDWxtFpbLEVHzWBjdXk1QCHOmsEQjrzwM8kgaFLv BzEbwb1RqITN2jNr0RTp1OMNf1bV4RZjTsE4ZZwJqXawjG0Mzas8VCzVM1n7l1cbOtkuxgFPM1nM ipV1SJF/zAoItRtaMhySUFWDXRnR3NnHvBPysSKiF0dHaMDGYh9D+IFT7U9EJdxcmILWD3DNptk2 r9zemnea6uWWwdlxzLIY591SX9MUFWfhpp+UNpininngm9d249z5XdEVf1GuVNP4f+aKXg7gFmEl 0hEI4ZZXYKQrpRlwoWIOXSiLadgVsO6b3gHZAle18BrIh7tm878gh/p/W3NWhylrOAyqfTpCgsJy omJByB60JZN9Zyir50uPVclyRSajKubKzJo9IIeE9XUPXNM9OEAxpLrpJnkbMLjT+ec+5xU0GOk9 SrXenE5WLp22Bv7ujYstZnDq1F5C52/Bf2liubpPVz8rb8SLNbLqiH4x3SU1iqpwFr+NjXyqNzRh kQW4stbajjXj8fJqYRxEcdZjGCz3MxncBSH9D6x/VITMfrjQC2qf70NvRfAdwvKHIKsv6a4GGaQb pP01gH2PHbTJpFVZavOdj2atWKwveKNaznuKbG3ZIvE+J9nlJsqdzqnFiyQ7Z9jh2o7NpRoie7pE YWhYnENMYMwXr+pHKT54AIHegev/MbOfqWQGT6YOsj1hsmvAo0n+k0m74Nqs02cYjWTpPhkiGh0X 54+SCVtC9lNJsUU2aC2mE60UXPEdGlzBHK9F7WpZCi+fLVxKmJmhZZfC5lLNpwA+lOWNWx/tAG+b rPVaF1fBFEv/DGULGO+nzHvyWZQye1B8baDegDJ1/HrKcqaAvNnEg0+dAsPRq2f6Lyw6NtNNym79 AQAA//8DAFBLAwQUAAYACAAAACEAk6p9mLsAAAAkAQAAMAAAAHBwdC9oYW5kb3V0TWFzdGVycy9f cmVscy9oYW5kb3V0TWFzdGVyMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0iqISNNeROhV6geEZJsG 2yQkUezfG+jFguBlYWbZN7NV855G8sIQjbMcSloAQSudMlZzuHfX3QlITMIqMTqLHGaM0NTbTXXD UaR8FAfjI8kUGzkMKfkzY1EOOIlInUebN70Lk0hZBs28kA+hke2L4sjCNwPqFZO0ikNoVQmkm31O /s92fW8kXpx8TmjTjwiWci/MQBE0Jg6ULs4yDzR3BVZXbPVb/QEAAP//AwBQSwMEFAAGAAgAAAAh AJMKbXUTBwAA5x0AABQAAABwcHQvdGhlbWUvdGhlbWUzLnhtbOxZzW8bRRS/I/E/jPbexk6cNInq VLFjt9CmjWK3qMfx7tg7zezOamacxDfUHpGQEAVxQeLGAQGVWolL+WsCRVCk/gu8mdld78Tjxinh Q9AcWu/s77157/c+5mOvXjtOGDokQlKeNoP65VqASBryiKajZnC33720HiCpcBphxlPSDCZEBte2 3n3nKt5UMUkIAvlUbuJmECuVbS4tyRCGsbzMM5LCuyEXCVbwKEZLkcBHoDdhS8u12tpSgmkaoBQn oPbOcEhDgvpaZbBVKO8weEyV1AMhEz2tmjgSBhsd1DVCTmSbCXSIWTOAeSJ+1CfHKkAMSwUvmkHN /AVLW1eX8GYuxNQc2Ypc1/zlcrlAdLBs5hSjQTlpvdvYuLJT6jcApmZxnU6n3amX+gwAhyF4am2p 6mx01+utQmcFZH/O6m7XVmsNF1/RvzJj80ar1VrdyG2xSg3I/mzM4Ndra43tZQdvQBa/OoNvtLbb 7TUHb0AWvzaD717ZWGu4eAOKGU0PZtA6oN1urr2EDDm74YWvA3y9lsOnKMiGMrv0FEOeqnm5luAH XHQBoIEMK5oiNcnIEIeQxW3M6EBQPQHeJLjyxg6FcmZIz4VkKGimmsH7GYaKmOp79fzbV8+folfP n5w8fHby8IeTR49OHn5vdTmCN3A6qgq+/PqT37/8EP329KuXjz/z42UV//N3H/3046d+IFTQ1KIX nz/55dmTF198/Os3jz3wbYEHVXifJkSi2+QI7fMEfDPEuJaTgTifRD/GtCqxnY4kTrGexaO/o2IH fXuCGfbgWsRl8J6ADuIDXh8/cAzuxWKs8pA7nt2MEwe4yzlrceFl4aaeq0Jzf5yO/JOLcRW3j/Gh b+42Tp34dsYZtE7qU9mOiWPmHsOpwiOSEoX0O35AiIev+5Q6vO7SUHDJhwrdp6iFqZeSPh042TQV ukETiMvEZyDE2+Fm9x5qcebzeoccukioCsw8xvcJc2i8jscKJz6VfZywKuG3sIp9RvYmIqziOlJB pEeEcdSJiJQ+mTsC/K0E/SZ0D3/Yd9kkcZFC0QOfzluY8ypyhx+0Y5xkPmyPpnEV+548gBTFaI8r H3yXuxWinyEOOJ0b7nuUOOE+uxvcpSPHpGmC6Ddj4YnldcKd/O1N2BAT02qgrzvtOqHp2969cO/e FtRbPDdOdex5uNN9us1FRP/9bXoHj9M9ApUxu1a97dJvu3Twn+/S8+r54nvztB1Dp9Z7J7vpNlvw ZO4OfEgZ66kJI7ek2YRLWISiLgxqOXP6JOWJLIvhp65kmMDBjQQ2Mkhw9QFVcS/GGWzg64FWMpK5 6pFEGZdwcDTDXt0aD4cAZY+dq/pAYjuHxGqXR3Z4RQ8X545SjbFqZA63xUQrWsGik61cyZWCb28y WV0btfBsdWOaaYrObKXLmmJzQAfKS9dgsGQTdjcI9kTA8hqc//XUcPDBjESadxujIiwmCn9NiHKv rSMxjogNkTNcYbNuYlek0Ix/2j2bI+djs2QNSDvbCJMW8/NnQZILBVOSQfB0NbG0WlssRUfNYGN1 eTVAIc6awRCOvPAzySBoUu8HMRvBvVGohM3aM2vRFOnU4w1/VtXhFmNOwThlnAmpdrCMbQzNqzxU LNUzWfuXVxs62S7GAU8zWcyKlXVIkX/MCgi1G1oyHJJQVYNdGdHc2ce8E/KxIqIXR0dowMZiH0P4 gVPtT0Ql3FyYgtYPcM2m2Tav3N6ad5rq5ZbB2XHMshjn3VJf0xQVZ+Gmn5Q2mKeKeeCb13bj3Pld 0RV/Ua5U0/h/5opeDuAWYSXSEQjhlldgpCulGXChYg5dKItp2BWw7pveAdkCV7XwGsiHu2bzvyCH +n9bc1aHKWs4DKp9OkKCwnKiYkHIHrQlk31nKKvnS49VyXJFJqMq5srMmj0gh4T1dQ9c0z04QDGk uukmeRswuNP55z7nFTQY6T1Ktd6cTlYunbYG/u6Niy1mcOrUXkLnb8F/aWK5uk9XPytvxIs1suqI fjHdJTWKqnAWv42NfKo3NGGRBbiy1tqONePx8mphHERx1mMYLPczGdwFIf0PrH9UhMx+uNALap/v Q29F8B3C8ocgqy/prgYZpBuk/TWAfY8dtMmkVVlq852PZq1YrC94o1rOe4psbdki8T4n2eUmyp3O qcWLJDtn2OHajs2lGiJ7ukRhaFicQ0xgzBev6kcpPngAgd6B6/8xs5+pZAZPpg6yPWGya8CjSf6T Sbvg2qzTZxiNZOk+GSIaHRfnj5IJW0L2U0mxRTZoLaYTrRRc8R0aXMEcr0XtalkKL58tXEqYmaFl l8LmUs2nAD6U5Y1bH+0Ab5us9VoXV8EUS/8MZQsY76fMe/JZlDJ7UHxtoN6AMnX8espypoC82cSD T50Cw9GrZ/ovLDo2003Kbv0BAAD//wMAUEsDBAoAAAAAAAAAIQAttP+IAFQAAABUAAAXAAAAZG9j UHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBgAGAAAP/bAEMAAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAf/AABEIAMABAAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJ Cgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQz YnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm 5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIE BAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZ GiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SV lpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAoor8sr79vn43+MU/ZV0T9n/8AZu+FfjLx9+01aftL6v8A2R8Yv2mPF3we8H+CdE/Zt8W6R4U1 Kb/hL/BX7Lvx51rxJqviqTWrS9stN/4QXQLTTEjuIJ9Xuykcs2c6sKbpxlzc1WfJBRhObcuVyekI y5YxjGUpTlaMYpylJJNjinOTirXUJ1PelGK5aavLWTSb1SjFPmnJqMFKTSf6m0V+X3x7/ay/br+D XxG/Zq+Hek/si/sl+L7n9pbxZbfDDQNT1H9vL4w+FYPDfxT0v4FfEH43eO9P1i3tv+CdniqS58Aa PbfC7xf4d8JeNLKRvEXi2eTw3qWsfDrwPHqup2Xh/pfhl+1P+158U/2hvi18IND/AGYf2b7DwR+z z4++Efw4+Nvj/Vf2x/idH4qtfEHj34G/Cn42+L7j4V/Dq0/YevNI8e6P4RtPievh/wAN3Xi34l/C q98b3OiHUNU03wHFqItbHop051akqdPlcoe1c7zhCMYUcThsJVrOpOUaaw8MRjMJB4nm9g/rNGaq OnUjJqadNJyjJc2Ap5nFKMpSeDq16uGpzUIpzdWWIoV6SwqX1vnw+IToL6vW5P0cor4p/ak/aQ+N Hwm+Jn7O3wa+AnwW+F/xg+IX7QNz8VjbH4vfHrxX8AfBvhbSvhR4V0vxRqd1P4g8Gfs8ftH63q+o apFqiWdhp0fhDTraOSJpbjVVVgg+L/jN/wAFdNf+C/wS17xjrf7Kmq6n8d/hH+1Hpn7M37R37Pun fFqzmbwI3/CndV/aF1j4o/Cvx7b/AA9u5vjN4K1b4Jadb+PPhTZ3ngb4aeJviB/aUXhTXtH+HXjT T9Y8P6dzKvRdSVN1IQnCvg8PL2r9jGM8fmGV5XhpudXkgsNLMM6yvC1sZzfVMLUxcHiq1GEKsqen sqri5QpzqpUcVXcaEJV6nJg8FjcwxEVSoqdR1lg8uxdalhlF4jEKkoYelVqVaMKn7TUV+cP7VP8A wUR8P/s++OP2PvBHgP4fxfG+b9qrx/8ADqyvdY0zx1a+E9L+GXwV+IXxG+F/wn0/40XLP4b8S3Hi n7Z47+M3w90zwt4KSHw/J4ss5/FOpweJdOg8Iamru/ZY/wCChOmftBfGr9sD4NeNfhtD8F5/2YfG vi6z8M+KdT8fQeJtF+Lvwp8E+OvHHwy8TfFMSSeFPCtt4Fm8N+N/h/rWn+KvB93f+I5PD+l6n4S1 yfxDPZ+JbZYdE1++5v3f1f8Atz2rrL2CiuGv7HWftOt7NTWUPPcuWOdPmVBvHKWuU5ssFk5RUaM0 1OGIjlEqU6X76Eo59PNqeTScqXPGCzKpkmYQwjqOKqzjhIr3szyxYv8ARyivgX/gnv8Atw3P7d/w 7+KnxGl+D+ofBvT/AAN8Y7rwF4U0vV/F0fivV/GXw+1b4afDP4v/AA2+JOrW8Xhnw2PBeq+NfAHx U8NarqXw/lOv3PhC9afSrvxJqd1FN5Pz38WP+CtXh34PfA7wZ8VvE3wX1M+KNV/bq8ZfsV+Pvh1F 43FvL8O7X4YfEPx/pfxO+NcuvXngyC48ReD/AAx8GPAF18c7HTrbw1pza7pOueHvDMes2FxqUWsn X2NVVcLh5U506+MwmW4+lRqxlSqwwObSyuGExmLp1FGeAwsZZ3lccdiMcsPSyp4yH9qTwfJV5JdS EaWMrucfYYDFZngsTWUlKlHFZPSzavmFCnOLccRUp0cizarRWHdX65DBVHgvrCnS9p+v1Ffm18ZP +ChE/wAOvit8Tvgr4G+Cd98W/iJonjz4K/Af4O6Fo/xA0rQW+Kf7SPxZ+GPjv45eIPAniq7vvD97 Y/CP4efB34G+GvDvxc+InxQ1G58Vao/hPxBqVn4S+G3iXxbpfhrwz47+ofgZ40/aV8STeKNK/aR+ Avw4+EGr6VHouoeGtc+DX7QF/wDtA/DfxXp+qtqtveaWNc8Y/Bb9nL4i6F418NXGkpda/pWofCOT wbLoniTwpd+GPiH4l1qTxh4d8FRTTqwqVIWcKbSlOTUISk6WGrqNKU3FV5+xxmGrclF1JexrQqtc l5LWrGVFwjUTjKpRpYinH4pSoVq1XD066jG8vYyr0MRR9pbkjVw2JhKSlh6yh9CUUUUiQooooAKK KKACiiigAooooAKKKKACiivjPwZ+3L8I/Gv7Z/xa/YYttC+IWh/Fr4S+CdH8cy+JPEWj+HrL4beP 7C+0fwLr2vaR8ONdtPFWoa9rPiLwFpfxN+H93410zWPC3h8WEHizS7nS7jWLQXdxaqLU69LDR96v XhiqlKkk+acMFha2NxUl0tQwtCtXndq0KcrXdkx6U6lV/wAOl7H2kv5fb4ijhKWm758RiKNPRO3P zStBSkvsyivhr4Wf8FC/2efip8SP2wfANvea/wCA9F/Ylm0z/hb3xi+KK+FPBPwXv9OmvPiJovij xD4R8a3/AItlkm8MfDfxd8JviN4J+IHiDxZpHhDS9H8TeD9bgsbjVtNs5NTGN8Uf+Cj37NXgfwd+ zn8XPB/xa+BvxR/Z++Onx31z4M67+0J4a+PHgGT4OfDLTvC/wZ+Nfxb8UeOdW+IelzeIPBWo2Xhq T4N3HhrXtNvPEnhyDSH1mbVNQ1u2OivpeouNpex5WrV6WX4im20o/V81lRhl9epJtKjQxM69KMK1 Z06cXK1SUOWXLfs582KhyS58E80jiYW9+nUyXC1sbmlBR+KpicFhsPWqVcLSU8ReHs4UpVXGD+/q K+E/jt+3z8KPhd8FPEfxs+G83hT4/eGYv2Vv2jf2qPh5r/gD4yfB5/A3xL8Ofs6+HNH1zVtF8O6z Z+Mdc8ca9aeIbjXtN08eO/hv8MPiV4I8HEsfHGraDqOq+D9I8Vc38Tf+Cnv7KfwHsrG8/aC8f+C/ gnDf/Fz4bfBqC78efGb9nvSrFvEHxF+G/g34nnxDdR3Pxeg1/wALeEPB/hzxvpVz4sb4ieHvA/ja 00s2/i+w8Dah4F13wt4o152abjL921VwtBqq1SarY7Np5HhaTVXkaqVs1pywcYO0lNKpJRoyjUY4 SVGjiEuejXoZliaNSnaqqmHyfCYPH5lWj7Pnfs8LhcfhKsptKM/a8lJzqU6sIfohRXl9v8b/AIL3 nh+TxZafF74X3XhWLxpo3w3l8TW/j/wpP4fj+IniLWtH8N+H/AUmsxas2nJ4013xF4i8P6Bo3hZr ka5qeta7o+l2VjPfanZQT8r+03+0F4e/Zc+Cviv42+J/CXjfx5pfhe+8G6RF4N+HEXhKbxr4l1rx 7448N/D3wzpGgDx54v8AAPg2K5vPEfirSoprrxH4x8PaVZ2huLq51GJIdrTUl7KHtJqahzQimoTm 5TqQo1acIRhGUpzqU8Th6kIRTlOFejOKcasHKaf72UYwcG5ycU3OEY3VSdKV5ykoRUalOcJylJRh KE4yacJW96r8H/i3/wAE0fij4m8L/sVafrn7O/7DH7Zdj+zg37WaeOPg5+1f418RaB8K9Vuvj343 0jxL4J8W+FL+7/ZJ/aVhvvEXhHT9OurS+h1f4b6HJbz6pcJpOuywCSS4/Vj4XftBnxja6Da/Fr4T +Ov2TvHfjPxVrfhX4d/Cf9oPxz+zXdfET4lyeHvDEfi7VdV8BWfwC+Pvx28Oa/ZWWjR6xdXmmR+J ofFmnWnhvXNY1Tw1Y+H4rHV7+h4k/bS/Y68Gx+G5fF/7WX7NHhSLxldeHbHwhL4k+O/wt0OPxXe+ L9V8XaD4Ts/Db6p4qtV1y68Ua58P/HmjeHbfSzdTa3qvgnxdp2mpc3nhvWYbKa+GjUqYeM7OpGrQ nQUHSrc1WqoKnTStVjKrP20Kfs0vb0q01GPssTGPK6VXk9rXimo0qGIVaUva040qE70KlWbTpuNL mVo1JP2NTRP2lKbjPzDx5+z78S/iR4g/4J4+MH0D4TfDCX9l34vaj8Svib8OvCHivX/EXhHQ9H1H 9lP47fA228GfB7XT8L/AjeKLLQPFHxP8OjTJ/EHgn4W2svg/S9SvY9L03ULex8O3fD/Dn/gnf8G7 X9sT9qP9r34yfA39m34k/Ev4jfGn4V/EX9n/AOKet/DPwt4x+M/wq0D4e/s7fBz4XmytPHHinwSu v+BtTtvH3gTxV4i0O28FeJr6yhsdWs9X+3WWtX+o6fZ/WPiP9pf9nHwd8XvCn7Pvi79oD4JeFfj3 48sYtU8D/BDxH8VfAmh/F7xnpk51UQaj4U+Gup69a+M/EVjMdC1sRXekaLeW8h0fVQkh/s+78mjp /wC1X+y/q3i7x58P9L/aQ+AmpePfhZr/AIU8J/E7wRp/xg+Ht54u+HPinx54lsfBngfw1488NW/i KTWfCGv+M/GGp6b4U8KaN4gstO1HxF4l1Cx0LSLa81S7gtZOmFeVTF/WaCUsTifr9Gg6bnVqKcsb leIxn1Wcp1K7xGHxOBwFOdVVJ16Sqyp1Z82IbkpJxpqhVVqdPLMBlM6c4QhCeCljMwx+Cp1qUYwp NYrEY7Fzox9nGnXjGEaUHGireBfta/CT9pTxB8bP2Ufjx+zb4R+B3xB1j4CXHxvtfE3gj44fGjx7 8C9M1fTPix4K0XwxY3uheMfAf7PX7R11JfaPdaXJcXWm6h4OsLe5t5UEOqxyBkrwDTP2B/jZ4h1/ wr8Xfiv4s+FGt/Fvxz+3l4K/a6+O/hrRG8St8N/Bvw78G/s1a5+zt4b+BXwq1XVfDX9ufEhfCmif 2DLeeMvGvh74bQ/EXWtT8ceL5PCnw8g1PTPAlj+iHjL9pD9nj4c6V4u134hfHr4MeBNE+H/iGbwj 481jxl8UfA/hjSvBPiu28Dx/E248MeLtQ1vXLG08N+IYPhtND8QptF1may1KLwPLH4se2XQXW/OH L+1r+ypB8Qvh18JJ/wBpn9nyH4rfF/w3pPjL4S/DKX4zfDiP4hfFHwhr9pf3+heKvh14LfxIPEnj bw3rVjpWp3uk654a03U9L1K006/ubO6mhs7h4+Slh6Uq8KqpxxFaeNyevRVSKrRc8Pjsp4hwGEp0 LOjUhjsTw/gMbeVOpi6+Eo4mjhsRDAYvGUa1VJzhSrUnKWHp1cBmdPEODdGc8NicJjckxmJnWuqs IYelmlbD2hOGCp4x4PEV6E8fhcHWpflP8MP+CWfx28GeDNV0PxT8Uvh74x1fwn+1x+yRdfASWTUP GNtpvw//AOCfv7HP7Qen/F74U/CS/wDtfh7UZ5PjBY6NrXj7TNTm06FPCmu3MPgXT7nX7O10qfVo n/Fj/glr8dfHGmRx+D/ih8PPAWt+Nv2vv2q73426zY33i/8AtDxf/wAE+/2w/iAfFXxf+EWiajY+ HbC60/4wXdloHge68PyXqT+EvDviLT9RuYdevYH8y9/dSaaK3hluLiWOCCCN5p55nWKGGGJS8kss jlUjjjRWd3dgqKCzEAE189eBP2v/ANkz4o+BdZ+KHwy/ah/Z2+Ivw08OeLNH8BeIfiJ4E+Nnw18X eBdB8c+ItR0TSPD/AIM1nxb4f8TahoGl+LNd1bxN4c0vR/Dt9qEGsanqPiDRLKys57nVbCK40oy9 lPnU3VqUY16uJnWkqs6sc1nwhhcxqYxy1azufB2VYbMJ+4sbLG5tSvzZnUionSdZrlhKEq1XCUcL 7BODp1svjxPLKaWEUP8Al7lUOKMwllkLTnho4LK3FSWXU2+T/Zh+APiT4G+L/wBrjWdZufC8mh/H X9pdvi/4B0/w1cajLLofgxPgR8DfhZa6R4gt73R9KttO1qDWfhjrc6WOkT6zpiaLc6PMuqG7mvNP sPivxf8A8E0PFfxI/a+/aw8Z+OPE/ge5/ZD/AGiPgV8SNM0r4eQPrN/8RdH/AGkvjv8AC74X/s// ABd+IGo6fqmgN4Sg8LWfwY+C/hS08DNpuvT6xH4k8bfE59U06PT9Us2r73T9sv8AZAk+Ccv7Ssf7 Vn7Nr/s5QamNFn+P6fHP4YN8E4dYOsR+HRpMvxVXxQfAsepnxBNDoQsH14XR1iWPTBF9tdYDmfss /tQaF+058LfG3xY03SdP0Pwz4U+Nf7Q/wp0++0nxRF420rxNoXwJ+LnjP4ZWvxB0zWNO0jTIJdP8 c6f4Sj8XWWm2MOpw6bbarHp1trWvpAmqXcYinGrQnGvOcKOWcMLJMZVlVlQUMhWS5fkcIY6u5QTa wzynMqU6k1UWYYTA51Sjz4KFalphnPBuGKwijTliuJPr+DdKMJuGe4jMM1zy+CoWmopVMJnGEbjS lSo4WpicsnOEsVCnV/O34bf8E7/2qfCf7O3wS8Ya98Vvg7qP/BQ74Q/tMeMv2tNc8WLF42v/ANn/ AOLXjLxF8OfF/wAArj4U+LdVXSNB+Idn4T1/9nfVvDfggfEuXwp4h8T+BfGHh/S/HFr4M8cWGjv4 O1/2v9hL9jDxV8A/2gP2oP2gvEf7O/7IH7KS/H3wZ8DvCP8Awp79jzxPqXjjwpq2v/CzxD8cfE/i X4u+OPFd/wDs0fsqi78ceObj4w2Wj3lr/wAK91y9Fp4Ot9Rv/GmoPqMOlaR7d+z3+3Z8P/jz8MfE Pxx1j4Z/Fz9nb4F6d8PNF+MvhX42ftGR/Cnwb8LviL8FNftNZ1Sw+LOg+LPCnxW8eWXg3w5DoWkJ 4j1jQPjSPhV8R/Dvh7WNF1jxD4G0uyvJJbefXP25/g7qSfsoa58CfFfw0/aQ+HX7Uv7R97+zxp3x O+EvxY8L+LvBXhu/0v4QfGn4o6rrtlr/AIOi8XaF4tu9Lvfg/J4S1Dw1BrGizWd1rr39zqsUujtp Oo+hKpip4ypTnBrE1o4TBwwsqXs55fDEvLckoYKNNqNbAYeMsswGWTy7FSjg8DjcJVlPC4bNfr1e XNGhShhMRShBU8LSpY3FYtr4cRRybEY7jKvVvNuNaeGrVsZnVLE4JfXMbg69PD06+LymrhcI/tei vDvh7+07+zX8W/F3xF+H/wAKf2hfgd8TfHnwgurix+LXgn4e/FnwF408XfC69tNQv9Ju7P4i+G/D ev6lrPgm6ttV0vU9MuLfxLZaZLDqGnX9nIi3NncRx/NHxB/4Ksf8E7/h54E8E/FC7/bF/Zo8TfDj x18ZdN+Bdh498HftCfA7WfBmk+Obq0sNT1qLxB4pk+IlloNhZ+CdE1bR/EHjlIdQu9Y8N6DrOk6r d6Q1pqFrJJwqcJKi1KLjiJYKNGSa5J/2jjqWW4Gan8CpYrH1qWEpVm1SlXmqfPe9t3GUfb3jJPDL EuvHlfNSeDwlXH4qE4W5lVo4OjVxM6VvaqjCU1Bo/Qiivme9/a7+AXhvRvjJ4w+JHxM+G/wk+G3w Q8T+D/DPi34rfEj4x/A7Rvh0W8eeDvA/jPwnq0+v6f8AE7V38EWOv2nxB8O2Gh6d8WrL4c+KfENx d2WseHfDureD/EPhHxP4in8Uftk/sheCPh94X+LXjT9qr9m7wj8KvHHhmTxr4L+Jnij44/DHQPh9 4v8ABsOr+F/D8vi3wv4z1XxRaeHNf8Mxa9438F6JJr2k6ld6Umr+L/C+mtdi91/Sobu5Xj8Xuv8A cJqWkoSxWHWLoU6kXaVOtUw79qqFRRrKMZ80IuE1FRTlycic/aQq1abh7yq0qFnVrUnG6qUaalGU qsHKmozhLm5ZRb+kaKqWGoWOq2Flqml3tpqWmalaW1/p2o2FzDeWF/YXkKXFpe2V3bvJb3VpdW8k c9tcwSSQzwyJLE7Iysfzy8a/8FQP2bvh98G/Avxr8UWPxHsdB8c/tf6h+xJ/wjseheHLrxf4R+M2 gfFnxr8J/F9x41s4PF76Lo3gnwTL8PfFnxB8UeIbfXtRms/hlph8TWml311NDpDvll7aOHcWq86t GgqTTjNVK+Lw+ApqadvZxeMxeGw8qlTlp06telGpOHMiU06E8StcNTpVq0q6u6Kp0MDi8yqv2qvB yjl+Ax2NUItznhsHia0IyhQqOP6MUV+cv7T3/BRzw9+zPefHwx/sv/tQfHbwx+y58OtB+J3x98e/ Bdf2a7Xwp8O9A13w74o8YCxmT43/ALSXwV8T+KvEWkeEfDC+Jdb0PwH4b8VXVnpniTwr5X2m81f7 JbfXXwR+J3iz4teDT4r8YfAP4t/s66i2pzWdr4G+M2r/AAL1rxXfaalpZXVr4kt7r9nz40/HbwTH o+oNdy2trb3vjG08RR3Gn3hv9BsrV7C5vlTTqRqzh8NF2m5fu9eZQSgqnK6rbbsqXO3GFSa9ylUl B1P3Toc//MS6qoSj+8hUdCnRqYhKdPmgnh44jDrEKUk6FTEYelW5KtelCfsFFFFIAooooAK/CX9p n9lb9sbTPiv+1d+1d+y98NNC8Q/tD+Gf2hvgV8Sf2W9O8R+OvB/hvQvir4Jvv2Y/B37O3x68La/q V7qs8fhzRLaxvtc8RLZeLrHTp9S8TfDfwvqOjWt7t0q5n/dqisK2Hp15U3UdS1OdGTjTq1KKqRpY zCYx0qk6MqdV0a0sHCjiIQqQ9rhqlejJ2qXjpTqum5vkp1FOnVpSjVpxqRca1KdGTUZJpTjGo5Uq itOlVUKtOUakIyX88viz/gnH8bfhrYfFLR/hp8PovjB4Y8D+B/8AglX4j0PQtR8RfD7wzN+1t4x/ ZC/aH+Lvxt/aM8M6lDrev2Gl+HvHHxB1LxJa+O9P1T4hy+F/AviP4oeItKi1rxXb6IPFesaRJ43/ AGZv2nvGvxI0X9q//hizVBaX/wDwUw+Gf7Wt/wDsj+IfiF+zY/xR0fwR8Ff2GfiN8CX+K2uahb/E /X/2fZvj942+J0fg258B+HvD/wAZdZ0iCPRfhJq/jD4k/Dy4j8ca38Pf6FqK7fb1FiKuJThGrUzJ ZvB0qdOjDD5h9ZyDFTrYenRhThGlN8M5TT+pTjPAUVRdbDYWhjHDEw56VKFKjOgnOaq5ViMlrTrV atadbL8Rk2a5K4VHUnKMsRCjnWOxKx/KsfVxM6dPE4mvgKccCfzR+Of2B/2uPGPw5+I2p6Z8D08M 6v8AGH9m7/guG9h8J/8AhP8A4Um9+Fvjj9u3xP8ABvxJ8A/hH4g1Oy8ZyeD5/GXi5vDPijWPHes+ EPE3i74X+FPG1z4gt3+Is3h+bQNX1P6N139mv9p3wLqPx/8AiVofwH8QfEy6P7d37C37QPg/4e+E PHfwb0vxl8Svht8HP2Yf2bPhT8T5/CN34/8AiR4L8CaZ4g8OeJvCPjWKz0b4jeNPAMevx+GJ5tL1 GSz1bQrzUv3PorPDS+qU8vpYZKlTyvC5Fg8CryqOlQ4c4mw/FWWRlOrKpOtOGOw1HDV6teVSriMF FqrOWMnPGS66+IniaVajiFGrHErjBYmT5ozrvjiOHWeSk6coRg28OpYNUI0oYZ1aq5akFSjS/CrW fg/441//AIK36F8OLTTFsP2efFujfDz/AIKefFLw7dX+l3Gp6H+0P8M/BWufsq+F/BviLTNLv9U0 61tfEWoQ/CX4vaHfaZe3Wm6n46+AXi++tL+9e3lu7j7g/wCCmvwg8f8Ax3/Yr+K3wx+GXgnxV8Rv GOta58HNWs/BPgXxvovw28beIdK8G/HD4b+NfFNl4O8e+IPHXwx0vwn4qXwt4e1q48Pa5L8Q/Blz Y6tDaS6d4j0rURaXcfZ/Hr9or9kz9lDx7pHjD4rQHRfi18WPCV7pg1n4c/AT4l/GL4ra58LvhDcz azqmreMz8EPhv4/8caL8F/hVf/ECa/1Xxn44TS/hh4C1Pxw8l9rekX3if/TvoPw18UvAXjHxd4z8 C+GfEMGseJ/h9Y+DdT8WWNtZ6kLbTtP+IGm32seD7u31eayi0XWINa03Try7ifRNQ1EW0cSrffZZ JoElxlThXy2jhkkqdPE4n206EYvCutTxbpZfRp0avt6UXl3D2X5Dw/7Op7SU8JkdCMlGnCFOnlzu jmTxTbc5UMuWEjWcoYh0MLhqdXGSlUpyp1JxxfEOKzvOHUoumqdXNqkafs2kl+L/AMeP2WPjH+1V +x94U/Zb+FX7P/7WH7LOq3/7QemeKk+Nn7Zn7WGl/tA/GX9n+w8GaLeeOF+L/gX4i+Dv22P2qfid 4lu/GOswQ/Arw/4Mj+KulJouieN/HWqa5oWneDLWOx8XfI/iT4d/GbV/it8V/gdoX/BPHw9cfFTx 1/wRE/Zz/ZJvvhf4N8dfAWy8Dfsz3niv4nfti+AAkniLxZ4/0OS+/ZRnvvDmna/qE/wx1bxl8ZY/ DOg/DoS/AvXPFf8Aa1j4I/pf+JPxJ8F/CHwRr/xH+Ims/wDCPeDPC8Ftda7rP9natq32GC7v7XTL d/7O0Ox1PVbnzL69tYNtnY3Dp5vmOqwpJImrD4P8I23i3UfH1v4W8OW/jvWPD2j+EdX8aw6HpkXi 3VfCnh3Udb1jw/4Y1HxHHarrF94e0LVvE3iTVNH0W6vJdN0zUfEGt3tlbQXOq38tw3TpTWNoVIye FzOrUrZlRhVrQniZPhPMeE6cVWjUValGWBxzjUnSqQrU4e0p4OrhqbjSWlKvOio1KbtjMJQwlHLq rhTcMN7HjTI+MKlSdLk5Zv6xk8o0lb2cqs41MRCtN1pz/BPXv2Pv2pdJl+Nf7M0PwE1H4lQfHv8A ae/Y3/aA0r9vOTx18FrLwl8NtG+A/hv9mex1+Txv4b1rxzpXx9Pxc+GV5+zx4iT4JWPw9+DPi7wL rknjHwI/iDxp4Jhn8fz6BJr3wA/bPms/2p/B/wAKPgR8dtO/Z70j42/AH9qj4SfBD9or4i/sgv4m 8YfGvwH+3lpH7Uvxz0D9l7xv8Jfiv45vtE+GnxY8N+F9V1nw9ov7YHjDwvfeHfiX4v8ADWjaNqvg H4e/8JHp/g7+guiun6xWeJwmM9o/rODqUqtKoowUHUwlDJcPl1SrhVFYSrVy2OQZbPDVp4d1q1Si pY+pjFGjGly0KVPDUIYeinGjTrYHEQi51JyhXweNxuNqzp1ZzlVpxx7zHG4bF4enOGFpYPEVcPl1 DARqVHL8G/Dv7LX7SnxP+JuofFX4j/s2z+AtJ8W/8Fe/g7+2FB4D8beOvgx4w1/wr8FvA/7CXgP4 T2HjDxUvhHxt4p8JR+NvC/xZ8LQWN74Y8H+IPGN7o/ibT11nwfq/ivwzZ6b42vuU+Jv7Ef7QOqft k/tBJ4ptv24/FH7Pf7R/7Vf7Nf7R2ma9+y/rv/BMSw+EPh+T4SaB8CdL0FPjtdftQaDpH7bGg6x8 LPHPwTg8RMf2d/FXjHTbv4bzaIfh7baR45u/E3hav6D68W+LPx18I/BzxL8BvCvifTvEd9qH7Q/x jX4I+CptBs9MurPS/FbfDD4mfFgah4ok1DV9LnsvD3/CO/CrxDZG70m31vUv7avNGtv7J+w3F9qO nZ4L/ZK2BWHinKlWy7D0KM7zp13Ry3gbIsFhpxb97mlwHw5io1IuFeOYfWqlOtToVqeHob4lzxkc VVq3bp5ZXdWvT/dVMPh8BX4ozvE46M6fK1Uo0OI87hVi+fCvCKi3hZYrDwxDzf2qNF+J/iT9mj4/ eHvgr4Y8AeNPi5r3we+IujfDfwh8VbWyv/ht4o8Zan4U1Sy0DQPHFhqkFzpOoeGdW1CeCx1bT9Yh bRr60nktNXaLTZrqVPwCtv2I/wBt34vSfte638Wvhp8fvG2mfHG7/wCCTlloOmftf+J/+Cdp+Jfi TR/2ZP20PEfxG/aAsPFHhn9iqy8KfASz8M+F/hlfQ6zodrrN74y8V+MvDdxb6ImvahrSw/Dnwv8A vf8AtK/tY/s9/sfeEfCPj39pL4k6f8LPBvjr4neDPg74b8R6to/ibVdLuPiH8Qbm5tPCmjajceGt F1oeHrG/ms7o3fifxENK8KaJBA91rut6Zajzj6Jo3xZ+H/iD4n+O/g1pGv8A2v4k/DTwx4C8ZeNv Dn9la1b/ANieG/iddeMrPwPqX9sXWmw6DqX9uXPw/wDF0f2PSNUv7/Tf7J36va6fHf6Y168HOVHE LH0kq/1bHZekpr2uHoY/JcRg87VJctvZYmVLFYCeOgpxryy/E4Rr2UK9KrNV6idGlhKihSsoY1O3 s61bD4jM8A6Eqjk/3uElj+H54XDvl9m6v9p0ISde/sfxt+JX7Ln7Rvgz9qb4jftN+Ev2fNU+Mngv wv8A8FHfAf7TWgfBzwd4y+C+heLvit4M1P8A4JteFv2UvEXxJ8CQfE74ieBfhzYeP/h38WLu/wBU fTfij4t+G+r63ofhzX9X8O65NeSeGLbxN9h/8E4/g18VvgN+zL488J+O/g74V+EPjLW/2k/2xfij 4X+EWk+LvDep+DdE8L/Fb9oj4m/EX4b6TbeJ/A2l3+lWGiXvhrxFohdrTwzHqGiW1w8V34Vt7+1l 0kfopXDt8SfBafEqH4QNrOPiJceB7n4kReHv7O1Y7/Bdpr9r4YuNZ/tYWJ0NfL1y9tbH+zm1NdWf zftKWLWaSXCZxv7GOAjLmnWyunk+F92nKvHB5bk2TU5qhS5HSr1aWX8J0cfiqlehiOWlSxspqGXU MPh8HeJq+2VKtVhCFLCYrAYuvK81TrYinWzvBYWWKqznKdP6zieLcVh3HD1MNHEYythHFPGVas8V /Ob41/YO/ah8a/D39obwx+zp8APjZ+xh8CRqX7KvxT8H/sh+Jfjh+zT46s9a+OnwX/apn+Pnxd1T 9j/wdf8AjP8AaX/Zj+A/gzxj4PtbOy8G+D/iVZeBfhD4y+LcHhzUPHXwH+GWiWGveNNT9v8ABX7G fx48Ran8I/iQfDv7aGm+Pde/4KDx/HT4767+2V4m/wCCe9p4/wBC8P6N+wP8Zf2cNF+K/hPQ/wBg LXdN+D0ujf2hrvwx8ISWFmJPi7qeq6RJrGsaWnhrTLXXV/Vr4mftl/s7/CL4veGPgV448X+Irf4l +KLPwpqQ0zw38Kfi74+8P+DtI8e+K7jwN4F1z4ueP/AHgTxP8PfgfoHjbxhZ3/hzwhr3xk8U+BNH 8Tarpmq2uiXt8+laj9m9p8E/EnwX8RZPGcXg3Wf7Yk+HvjnWfhv4vX+ztW0/+yPGnh+10291fRs6 rY2K3/2S21jTpP7R0s3uk3H2jZa300kM6RTTp06mErYSEXXw1f61iZt1KtaooYbNMjpZhOGK9pLE Qw9DE4DIcmrwVb6vl9GnluW4eGDlDBxg5YipQxNatJxo4uvRrYGq5QhT5o53kea06KnhWlhqmIxO Exmb59Qq1sPUr5ji6mMzPGSx9FVYr+Z74O/8Ezf2pde/Zy1n9nT4lQftk6B8V/hT/wAE+/j3+yB8 J/GHxS8Uf8Ezbb9hTVLz4j6H4G8K69ofgC+/ZR8IeGP22tV8BfErUvAvhvxPot1+0P8ADxtS0jw7 ZanqPxB0zUviIsNnr/6OfEe3/aF+Jvwm8F/Enw//AME6fHfws8d/B/8AaI/ZV8V3XwXm+JX7IC/G 34teA/hHqYbxR/wims+EvjVefAuDw34C07xLqMfww074h/HnwhrGuxab4rtp/Cvw+WfQF8U/r7RX TVxFatXpYmrJSr0cwyjNadRQhB/2lk/EFfiWljKkacYQrVMVmGJqxxcKsZ0PYTqfVaWFxNbEYmtz OlS9jUw6g1QqYTN8v9k6tepGGX51lFDJcVg6Uq1WpUp0qeEw1KdGpCaxPt4qeIr14KNOP4R/ED9m z9prQv2o/HH7Wmkfs5eJPi94Z8P/ALfXw0/aI0L4E6T45+Bmm+P/AB94Fvf+Ca/g39ljUvG/gyTx 18U/C3wwsviP8F/ird62bfQ/iD8RvBFnqug6V4w1jwnrWqXU3gmTX9H9mz9in4zaJ+0B+zb8Y/iX 8E/D/hPwraj/AIKrfEvV/h9c658OfE8f7OGq/tn/ABk+BvjD4b/DP/iU6vqOn6l4y8ReD9K+Jt58 TNT+GMnivwDpPi/XviB4dsvGuteFdX0HWfE/7l0VzSp0503TcEl/ZGJyKm05WpZXi+HMBw1iKEaT k6E608LlmDxax1elWx8MXSdGGJjlVSplk+iVapOWFk5PmwssJVUk3zVcTgoZxSw2JnL4qcqdLPMf FUMK8PguecMT9V+tqeIn8af8E7fhT8QPgV+wl+yL8GPiroJ8LfEb4V/s+/C/wD4y8M/2ro2uL4e1 3wr4V07RrzRItW8Oalq+gX0GltaCyt59F1S+0swQRrY3ElusZr82vil/wTn+L/xr/ax/a3+H3i7w lplp+xl8SPht8avjV8HviNc+IvDtxe6D+2F+0l8GPhz+zx4hsdD8HaZq8HjHwufhjovgT4h/FaPx i2mWtn4i8S/HvUhYakNa0C6uZv3worXMJ1MxxuPx9SpVoYnMsNnOExU8JUnRk8PnceevCnU5pVqc sLj6WAzfA1I1VVoZnlWXV5zq0qVahXKdX2XslCnQ5cPjMFjsPCpQpVqNHEYKpJQlDD1ozw7VXBVs bldVTpTay/McbToOjXnSxFH8L9B/Za/a38ff8Eqf279G+MPwu0/Sf28P23fAPx/1jxh8MrDxx4K1 jb431L4UWvwI+D3hCX4gxeJm+HrPN8O/h74AmnvLfxDp/hXR9Q1jUIJJbJbe8mP7gaRBLa6TpltO mye30+ygmTcrbJYbaKORdyFkba6kblZlOMqSMGtCit6+JlXf8KjRpxpYLD0KFCEoUcNhcuwscFgs NRUpTn7LD4SFOhF1Z1Ks404yq1Z1HOc+aFNQo4SinOUcHXzrE05TnKc51c9rZdXxvtJSbvGFTLKH 1aEFCNGE6sGpw9kqRRRRXMaBRRRQAUUUUAFFFFABRRRQB+RP/BUXTZdN/wCEG+Kvwrt/2yfBX7Yf w2+HXxjtP2Vfi3+yz8CfGH7QXhbxB4o8ZaZoi6n+zv8AHnwVongv4lfDeD4ZfE3xN4Z+G+p6trnx 90T4Z+EPD83h2y8TeCPjz8OPEWga3q9j856l8MtM+Enx9/4KC/GCz/4J+f29+2P8VP2KfBfxI8De IPhN8CvFvhey+Jvj1vhV410344fCfw3+2t8OvC9ra+CvHPiD4gWHh6y1HQZ/jD4Z+LHjG3Xwx4n8 KW3iC7srHVLH+gKisFRth69Dm5vbLF06U5qX+yUMXDMZ16GE9lUpTw9LHYvMI182pUqkKGPjgsNO FHCZlWzLNMfuq3+1YHESjzRwU8PUeHcn7HFzoYjCVIfW18VRYalh66y+pFwxODxGYYypLE4jBRwG XYH+P/wP+yvq3jT4Lf8ABUHwnf8A7HnhfxN8BNZ+CP7JHxY+E3wr+G3/AASk+NH7Dvwr8afGzwP4 s+Oq/F3XPhR+x1+0L4t+K3jfXPj1Y+D9F8G+HvEXirSNL8KeLPiBY2/ge10bwnqdjeeHPEni76p/ bS0q20D4eftleEv2c/2Rv2hz8Nf2rf8AgkP4E+Bv7J/gX4L/ALG3xf8ADWg6T4u+Gmtftkaj4g+F 3ir4e2vw58MSfszarovhv41+B9Z8PeEvjR4f+Fk3i5JtS8LfDux8T+O7A+EZf6V6K7ZVnKuqiXJS lGjDEUockXiI08Di8BedSMEnVo0q2FWBrTp1KmHpYONHEvHQrT5Vga88DWqV4/vas55TUi6qVqVT KMz4dzilKlGKjGn/AGhmOQzxWbU6ahSxVbMa9XDU8DOEZT/E74PeC7bwt/wVi8c+KfDHwbvPiVJ8 Tfh1q9x8T/jj8Uf2Hfi/8NviB+zPqPgj4d/BvwfoHw9+D37dvjvwXoXwx+N/wJ+Jz6S1z/woT4ba lrOueEPH83jHxy/inVdBTXNC0D5G/wCC3vhL4xfEvxb8R9A+Hn7Lo8ZeOfBX7LemeK/2XvjAP2E/ 2jv20PiNqXxtXxF8SdZ1HSP2afjJ8LPit4G+Fn/BPT4rfDCfwv4D8UX/AMUPG+nX3i7413fiDwNp 2j6L47Pwn8N+DtS/pqorOMnGeVTWjyybqR5Vy2lzYyaeF39k4TxfNT+u/wBp6xl7X2qlTVHHARhg adalyRxMKtPA0Wq6uqlLBPLYuniYRtTrQxeGy76nio0qeGUqGIqSpexxMY1z+cb41fsl+INf+LH7 aH7SMHwA8a61+0F4a/4KH/8ABNPxT+zr8VofAXizUfHXh/4eW3hb9gHwj+0H4h+C2rx2E1zpXgrV fClh8T/CP7Qmq+BhBoXinwv4T1rw18WZ9V0XwJFYaH5z8PPgHHZ/tffsy65qv7Ivx1T9sHwh/wAF SP2m/H/7Uf7VJ+BHxIsfBHiv4E+L/h/+2EnwB13Xf2iZtLs/AXxf+HUPw+8RfBzwb8M9I0PWvF9l +z7Lp8nw31zSPg7rmu2fh3xT/T/RWuGrfVnl6pwhGnl88PUpqmlSqOWHwXB+EcI1Yr93QxUuD8NW x1BRlDFSxdVy5a2HwtekpLny2eAqN1qlTL5ZbPFVm6s6lCWS5zksJVqcm1UqYWGeYzGYKbknhMXK Uqb9niMVCt+b3/BR74G2/wC0Ppv7Ivw01/4ban8Ufhtq/wC13oNr8YtAtNC1bWtJtvhXrnwH+P8A 4S8Uah4tl0mF30HwxIfEdlo13r93PYW1lfavp0KX9vfXVlu/EvxZ8Bf2/brwl/wUY+Fni34dfEHX rz4X6P8A8E3/AIIWvxS1b4XeNfitoH7ZX7JXwM+PXxg8WeOvEdn4H8GeMPhv4g/aE1zWf2YvF2ia N+0v8CfAPxF8N+L/AIjeLoviL8M9HSYeOfD2ha9/WrRXFh6X1anjqceSrTx+c0M8r0a0ZOhVxeDo cN4fBQxEKU6NWvhqNHIcXhquHdeFLE4PiDNqM4qusFisLrXn9YqYOpLnpzwWX0suoVqMlHE0KCzD OcwxMsJVqRqxwtbFVs0wtZ16VL21LGZFk2JhUth6tCt/Klb/ALLHxcuf2Yp/D/7GI1/Q/j/4q/bO 0vx5+yzqfww/4JwftGf8EtPgT+w5qmgfBLTbD4461bfCT9q6b4l6x4d+Dnxq+H+leIvDPiKPQYz4 H+J/xs+LE0HhzQovFkHjPxJoP1T+zZ+z9+zX4S/am/YL+Ldx+wJ40+Hmr6v+xC/w98G+MviD+yf4 w+JHxR+Cfx68AeLPD1rq2hfHH4723w11/V/h/wDEGPw7eeNLHTPjn8SfEnhnwx8WbSXxFqXg/wAd +ILTxZZrrP8AQJRXVRn7DF0MVHmqewxuGxkFXkp1KH1bg/HcGQw+Cq0o0I0KVPL8dLFYWdWjiq+G xuFwclWqUadajiOWvS+sUJ0JtU4zwdbBy9gpJVlU4mwXFKqYtVp15V3LHYGOGxFKnLD0K+BxGLpw pUMRW+sx/GL9uG38X+Df2ovBXxV/ZZ0P9rnw3+2Rq9t8BfhncW3gr4JeMPiX+x7+1D8Arb40w6x4 k8F/tB+O5PCXir4KfBiX4SaB4m+L2taJ8Rtd+IX7Pnxw8Pf8JDqMHhW9+J3hrXdH8Fa98P8AxY/Z U03wn8Gf+CmPwy/Zo/ZGj+FHxa1z9sX4afED4nap4Z/Yg8dTeGfj9+xdffEb4OeOPHXhbw9rPw4s vg7p37XPg258Hf8AC1Y/HH7Mfwt+O9v8Q/FNvN47+HMuiWet+PbbSfE39PtFctGj7GpCs2q06ccw pwhVUnQjRxuccN539VjFTVeOCq4vhqlSzPBQxMcPmGGzbPVSp4HE5nVxS66tR1XrKpB+3yzEurCa WJlWy7Ks3yanVlVcHCVfDYLN5PKsX7H65lmIyzI39YxWFyrDYRfyOa18Gvhd4B+FP7M9t478K618 Tf2b/Hn/AAVa0zXtd/Zb+EX/AAS3/a6/YM8AeDfDVr+wB+0JpPxD8J/DT9iD41eIvG/xb+J3wz8c DSm8d/FHwV8ONL8SeC/jFqeq/Ezwlpnw18c+JPEvjHwn4g7W4+Ctx4R8I/sqeKdE/Zd8Z+OIfBP7 WH7QWufslfsSfHD/AIJ7/HT4xfCzQf2afjR+1H4DvfA2tjxTaeAz4I/4JxfGH4X+GNGm8bfA/wAT fHCXwePgz8Ltb1j4c+J/hRpcNteXfhj+mjx38Jfh98TNZ+F3iDxv4f8A7b1f4L/EIfFX4aXf9q63 pv8Awjfj1fBfjP4eDXvI0jUrC21jHg/4g+L9H/svX4dV0b/ib/2gdO/tSw0y9svRq7KNX2ValiOa q50MRRVODnCUYYTD5fwzhcPyXp+w+uYWfDqoZbXr4TE/2fluOzPCt4yWYupg8sYliaWHoRSjCnlj w9WbUlOeMnmvGmKrR+OVR4DEYTitTxkI1qNbFZlg8FXpPBUsvjHHFFFFYgFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRXH+N/Fsvg3Ro9UtvC/iHxlfXOpafpVh4c8LS+GYNZ1C71Cby0F vP4w8SeE/D0McEayXNw9/r1n+5idYBPcNFBIm7cq1vKcKcUk5OU6k406cUkm25TlGK03Y7XUnolC FSpJtpKNOlCVSpOTdkowhGUpNuySbOwor5q0H9rf4HeItSOg2Ov+IW8S2tx4Zstc8OweAPHmr3/h i/8AFmmW+q6da+Irzw94c1nQtPt7a3uI4tY1xdYn8M6Pc/ub/W4S0Zk7fR/jt8Mdckihsta1aGS5 15PDViuseC/HHh7+09XlvNMsbeLRzr/hvTF1izvJtWtXsdW0s3ekX9nFqWo2d9Pp+jaxc2NWb5bW lzqDpuLU41FV9h7KVOUW41I1VicM6coOUaixFBwclWpuU3tdO8XFuM4yTjKEl7TmhOMkpQnH2Nbm hJKUXSqqSTpzt69RXieo/HjwjpOs6xomo6X4ntbjQvEa6JfztY6bJbDSv7NW8m8aweRq8t1P4Ttt Q3+G53S1/wCEh/t6JoYvD0unvDqUrR+0P8LdlqZLzxna3F7pesavaaZf/Cb4s6drlxBoOqaVo2pW cXh++8EW+tvry3+u6Ktn4ZGn/wDCR6rbavpuoaXpV7p97bXUkxalFzi04qHtG09Yw+rUcXzyW8YL DYilWlKSSjGfvNOM1GmnGXI01J1JUkrb1YV6mGnTT2dSNelOm4JuXMlpaUHL26ivIdM+NngvXyIN AfWZNQh8T2HhnU9M8T+F/GHgDUNInuPDa+N7251HT/GvhzRtSggsfBYl1pZHsRaz3H2fSZLu1vLh vI4Hw7+1h8L/ABLotv4rsJdTuvC13YxvBd+HtPvPiJrb6u+v6von9ijw58LLbxzczz+RpJ1lpbG5 vWtNNuY31S3054bhYnf3uXaV43jL3WlOl7enJqVrU61O/sKjtTr1FKjRlOtGUEnpB1P+XceW8lqr ut7DlTV7zjO7qQV50qalXqqFGMqi+nKK8p0v40+ANa8R2nhbTJ/Fdzqd/ezWGn3P/CtviTD4dv57 WzuL29ksPGE/hKLwle2OnR2slvqep22ty6bpmpyWmj393batf2Vlceaah+198H9AXxDJ4vi+I3hC 38MeIYPCeqahqnwr8f6von/CTzXlvpjeH7PxH4O0DxR4dvtYi1a5XTRp9rqslzeuv9oaXHf6LLba pO7PnjTs/aTlGMKdvfnKTpqMYx+KUpOtRUUk23VppazjcvdSl9mCvOXSCSqSbk9orlpVZa20p1Ht CVvqGivLvDXxg8EeKfEFr4U0u91OfXrnRk1wCPwp42j8Pi1eOOYW6eL9R8Mab4bOqiCWO6Ogy6jB 4gW0b7W+lLbK0o0PFPxR8GeDNZstC8Q3es217fWE2prPZ+EPGGtaNY2US3rJLrniPRNB1Hw94de+ bT72DSbfX9U0251q7tpLPSIb27AhMuUUottJTbjFtpKUouUZRjfdxlCcWldpwknrF2cU535U5WUZ PlV7RmoODdr2U1UpuLeklODV+aN/QaK8S1P46+GYfBeh+PNC0fxb4h0XWPFEPhlrEeEPFmgeKraR 0vmnuB4P8S6DpXiRjbmzEvk3enWEc+ny/wBpxXRslSWbOv8A9orwXb+JdF0HT9M8ZaxZ6jqFxpt9 4itvA3je00DT5Y/syx3dlrWpeGrPQfEulW800ttruo+HNZ1GPw7dRQ2epIl7eW9s1JSbmknenUhS qKzTpyqQoVIOonZwpyhiKM1Vlalyyb57Qnyy5RSi3JWnTdSErpxlGNWvQcYtXUqirYatT9jFurzx UeS86fN79RXzBZ/tQeGfGOrXWk/CLS/+FltpfjTRvAuu3iX934StNE1iXxPJonitrlvEeiQS31r4 V0yGbV0uNDi1aPxBcNbaXprKks2pW3Z698arCHVW8N+DfD2t+LfE9t4y8O+FtSs7/TNf8FaDbWep 63/ZXiDxDpvjDxJ4fh0DxdaeEoYb59Ts/BVz4juxq0Nrod0NOnvftNuqf71YeVP3liqqo4e2jqyb w9pwTs3h7YqhP61ZYb2c/a+19nCc4up+6lXhU9yWFpKtiL7UoOnWqJSl8KqctCsnRTdZVKc6Tgqq 5D2yivApP2gNFsfHWr+D9c8J+LtBsNKGqj/hLLuzs9S0a5Oj+e1xebfDl7rc+m6VeC3lg0l9aGma 5f31vdQ/8I/BbRRX1xr+IPjn4U8P+FdI8YS6J48udM1/+0oNGsp/BWteF/El9qunTCNNCHhXx7D4 S8RWur6rBHqOoaNDf6ba2+o6bpN9exXQhk0436i1KlCvFp0qijKM18PvycYKXWEpSi1GE+WT0aVm m24yjXlhnF+3jUVL2Vm5SqOMZckEv4jtJJ+z5kpqVN2nCcY+zUV5H4R+LcHjLxjqHhbTfA/jS206 x0g65b+Or6XwN/wiOr6dLrWraFp0+lR2Hja/8XyJq93oWrT6bLd+E7O3ksbQXdxNbR3mn/a/XKpp pK6avzaNWknGcoSUou0oyUoSTjJJ6XtZpuVKLbUWpW5G3FqStVpU69OSkrxlGdGrTqQlFuMoTi03 cKKKKQwooooAKKKKACiiigAooooAKKKKACue8U+EfCnjnRrjw5418MeHvGHh67kt5brQfFOi6b4g 0a5ltJkubWW40vVra7sZpLa4jjnt3kgZoZkSWMq6qw6Gik0no0mrp2avrFqUXr1TSafRpNaoabWz a0a000as16NNp907HCaZ8Lvhlomoanq+jfDrwJpGq600b6zqemeEfD9hqGrPCqpC+p3trp8VzftE iIkbXUkpRVVVICgDSk8E+EZJ9EuB4d0qGTw5qia1ov2S0jsorLVItI1XQoLsQWYggne20vW9UtbV LmOaK1N0bi3jjuYoJoupoqm22m2248tm221yW5LPpy2XLb4bK1rIlJLmSSSlzKSS+JSTjJS780W1 K+6bT0Ofm8JeFbm8l1G48M+H59QmjeGa+m0XTZbyWKS5jvZIpbp7Zp5I5LyGK7dHcq1zFHOwMqK4 5GD4J/Bm1sbfTLb4R/DG30200PVvDFrp8HgLwrDY23hrX7uW/wBd8PW9pHpKwQ6HrV/PNe6tpMca 2GpXc0tzeW800jufTqKlJKPIklGzXKl7tpRnBq21nCpUi9NYznF6SknTbb5m25cynzPfnTjJTvvz KUItS3TjF3ukefaB8Jvhf4T88eFPh54M8LwXdneafe2Xhzw3pOhabqFpf22mWV1HqOl6Xa2mnaiz 2Oj6bp6TXtrPNBp1sLC3kis5Z4JV8VfCj4ZeOIriDxh4B8JeJIL6+07UtSg1jQdOvoNXvNIhWDS3 1uCa3aLW4tPiSJbS21ZLy1gNvaukIe0tmi9AoqrtyjJ35oODhL7UHTalBxe8XCUVKDVnFpNWaQlo pRWkZKcZRWilGp/EjJbNVPtp6S+1c4Q+E/hv4Q1XW/iBD4Q8JaH4g1T7IPEHi7TvC+mW/iLVRGsW m2Q1TV9P0/8AtfUhDE8VnB9pmn8i3xGuyFSB8WfErxV+wN8U4/FFx448Pf2v/wAIxqPi2Pxf4x8O /Cf4z6FdaddfDPUzr3i6z1r4k+A/CGlXcljoeuahBrV5p1x4kl0vUNd1DSdRht77U73Sppf0A1LT bLV7KbTtRg+0Wdx5XnQ+ZNDv8maOeP8AeQSRSrtlijf5XXO3a2VJB4XTvhL4G0xJEgsNZuUa51+5 iXV/GHjLXxZf8JNf6PqesWel/wBua/qP9kaRNfaBpVxaaHpf2PRtKMEqaTY2Md7fJcx7ynGUXGLp U74eXK3Ojiac6P1acWpR5adKnGq+WDjU51RVOdOKkyk4qMo2k/aVI+1SkoxqUXSqwqqS5Zc1SXNT hGUrxVL2sZRlzRS4fW/F/wABNI0f4fyajZWcWj/FH+wrjwbNpXgXxNdR6na3TeHjpV5rM+g+Hp5f DmjSDVfD1nf3njB9H0gQXsOl6zKIJZ7U9tbWXwu+JeryeIn8N+HPFGu+AdU8QeDrfXtc8IRyaroN 3d6fbw+I9O0HVde0mO6/szVdM1CG3vrzQriXRtZtJnt/tV5Gk0aaXjP4ceDviDN4Vn8X6XPq3/CF +JLXxb4etxrOuafY2/iCximgtL6/03S9SstP11IIri4SOx1621PTwJ5f9EJkcmXwZ8OvAXw6h1i1 8A+DfDXgy01/Vm13WLLwxo1joljfau9nZ2El/JZadDb2q3EtrY2yytFDGJZVkuZFa5uLiaW/dc6r cWo81b2C5lOahNYaNNVZ8kE5ckswhWcIRU1LDcsYp14kR5oQpxi1/DpRquMXTg5ReIdVU6alPlpp xwU6SlOTi/rEZX5KU5S694A8B+KtDm8M+J/BPhHxH4buLuG/n8Pa94b0bWNDnvrZka3vJtJ1CyuL CS7gaNGhuHt2miZEKOpUYht/hv8ADu01zV/E1p4C8F23iTxCLYa/4gt/C2hw65rgsokgsxq+rR2K 3+pC0gjjhtvttxN5EUaRxbUVQO0opXau1u7pvvdU4u/e6pUk79KdNbQjYaTSTSaTuk1onzOd0uj5 5Snp9qTlu2zivD3w1+HXhE3B8KeAPBXhg3V+2q3R8PeFdC0U3OqPIZX1K4Om2Ft51+8pMjXkm64a QlzIWOauWXgbwTputa14k07wd4WsPEXiO602+8Q6/ZeHtJtda1690eGW30i81rVYLSO+1S60q3nm g024vp55rGGaWK2eJJHU9TRQvd5baciUYW05Yp02oxt8KTpUmkrJOnTf2I2cve5ub3uf4+bXn+L4 r/F8c97/ABy/md+Vi8CeCINS1nWYPBvhWHV/EVzBeeINVi8O6RHqWu3dtbJZW11rN8lmLrU7m3s4 47SCe9lnlitkSCNliVVEWk/D7wFoOiaR4Z0PwR4Q0Xw34fvZNS0Hw/pPhrRtO0TRNRle8llv9I0q zsobDTb2WTUNQkkurO3hnd768dpC1zMX6+ilZcvJZcq9naNvdXstaXu7fu/+XenufZsDd3zPWT5r t6v34uM9Xr78ZSjL+aMmndNmPpPh7w/oENrb6FoWj6Lb2OladoNlBpOmWWnQ2eh6R5/9k6NaxWcE KW+laZ9puf7O06JUs7L7RP8AZoYvNk3bFFFU2222222229W222231bbbb6ttsPl2X/gMVCP/AIDG MYrtGKS0SQUUUUgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD//ZD5V3AAAAAHzOUgIBAAAAAQAAAGoP lXcAAAAAgM5SAgEAAAABAAAAdg+VdwAAAACEzlICAQAAAAEAAACCD5V3AAAAAIjOUgIBAAAAAQAA AI4PlXcAAAAAjM5SAgEAAAABAAAAmg+VdwAAAACQzlICAQAAAAEAAACmD5V3AAAAAJTOUgIBAAAA AQAAALIPlXcAAAAAmM5SAgEAAAABAAAAvg+VdwAAAACczlICAQAAAAEAAADKD5V3AAAAAKDOUgIB AAAAAQAAANYPlXcAAAAApM5SAgEAAAABAAAA4g+VdwAAAACozlICAQAAAAEAAADuD5V3AAAAAKzO UgIBAAAAAQAAAPoPlXcAAAAAsM5SAgEAAAABAAAABhCVdwAAAAC0zlICAQAAAAEAAAASEJV3AAAA ALjOUgIBAAAAAQAAAB4QlXcAAAAAvM5SAgEAAAABAAAAKhCVdwAAAADAzlICAQAAAAEAAAA2EJV3 AAAAAMTOUgIBAAAAAQAAAEIQlXcAAAAAyM5SAgEAAAABAAAAThCVdwAAAADMzlICAQAAAAEAAABa EJV3AAAAANDOUgIBAAAAAQAAAGYQlXcAAAAA1M5SAgEAAAABAAAAchCVdwAAAADYzlICAQAAAAEA AAB+EJV3AAAAANzOUgIBAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwMEFAAGAAgAAAAhACsuTDGfBgAA DR8AACEAAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWzsWetu2zYU/j9g70BoPwfV 1tWyEbuwnbjNkLZBkj4ALdG2auoyis6lRYG+1vY4fZKdQ4q2laSr07QBuhkBLIoiD3k+fufCk4Pn 1xknl0xUaZH3LedZ2yIsj4skzed96+3FxI4sUkmaJ5QXOetbN6yyng9+/eWg7OWFZNUrWkkmCEjJ qx7tWwspy16rVcULltHqWVGyHL7NCpFRCa9i3koEvQLpGW+57XbYymiaW/V8scv8YjZLY3ZYxKuM 5VILEYxTCRpUi7SsjLRyF2mlYBWIUbMbWxqAhvE5T/A5nevfMzYjaXINOLXbjjU4oD2lJxtzQS4p 71vTuWO1BgctnAKD6xZOrsoLwRi28ssXojwvTwW+xK8vTwXIBJEWyWkGCKMA9aEepl5zGKYFN6bP jSTau56JDHcE8BDYIZzjDf7CJNpj15LEujPe9MaLN/eMjRdH94xumQVAtfWiqJXW6K46rlHnJaMJ EOSU05gtCo5thZFSUc8DGMuTIl5WJC9AacRC6wroGMkIAK5VLoi8KQGmRSKAme/71p8rKoCC9RQ9 DnaZr6dWCmujwL8j5HY7TtQG8BAnP+gARZXgzexSVPIFKzKCjb4lWCwVE+jlSSVx27Rnhqjj16uX PXk9KpIbPI0pPOHQwehg/qIQ7y3Cj/Oqb3Ud34elpXpRi1tEbH+ZNr5IPi6Ac/UZ80qeyxsOFKM9 fskdUJpQPgej5mp/CZudQRci5my0qkeqbW9LgHMF2uTJKRUUpy1XWZoV71LFU07RObyj9h+nFqwh T9Q7y+235zVYMB2OwKgMTU2UL9PFM3Q5pJI1yOKiyMeSJZFWbbgPpokXRX7owP42hmPM6b9IFvGt ZJnxRPmxD4ftSdcdT1zba/u+7Y19z+4OQ992wuDwqB20h4eO/xFYrqw4geOWacYm6Xwl2JuVtiU5 cNqtEFy7E6A9SUVPWOCJSekbUp7zNGHkOKPzJje9r3MTXNpZAXaO7r0YL8BS2LAqwWns5uUqnhxn 85q8yhSUa0NfqBrGPX7BxzmO77XRnQF5wyhAz9YICNrD1e7O890uDtZOzMQT48x28ncUkoJJyrla hOfkCp1NB2TiyVUFwIhf8QXFbsImBIdlve7WKDh6nitFn8CJEprH4Iz7VixVLIG1a4+qlLntEH+A DwwM3V5jYtVwgv7XiYantuUmMQDeipgYd5ohU/tExeIH0aqmErLK9+DvNq0CPwqxU0dRIGFNvHUW sYmRO9EKNvcEDNCkvXPoGEghTK4DLZge7Yn7Y6IU9sXZVkzUMVIJloMxT+MlkQVhSSpJnThLDCYV Bu5q4+rQugEiZSfqx2xBJUaw+rdu4ZzFRZ4Qzi4Z32E55XAesdzFIhW7r6Z4+IjVJsVKyMXOyimb esxy6eze1Z40bwqNz5gU4DSaaXbwPZzGDLxhI83WPkOB9yCfoYNQBK7DhWxKmcRPnUet48VUK2Oi BZrmz5d/dwyPdKrzepVNb7Ep/B5sgnQGRN9HKEXWBxFqOzH/P9Lq8Zn6cDzxjjquZ3te4NiHEaTr IzcIbNfzRqNh+ygcHrnrTL3CHDiHw0OCy8HnT3/99vnT35sg8mPScxX5TeUE/MVJBZeBUhU0VgJu ox9Go27ojqORPXL8ie0fdjv2cBIG9iTwfH88ioZj7+gj7Ll0/F4smKrzHCd1vQk679SIsjQWRVXM 5LO4yFq62NQqiysmyiJV9Sa4m+iilSr5eL7jeKHvBBEaCOwXdmmearfQZepIMRevaEmgSgS3cglX AnkNrWQJrencxT4om8hraCVLaNE4htIUjKgbpge+6571GM/0wD1VfwLF6obpCUwP5Jn6U2h6IIos eJovAQx8WGRW8Je6w7S09S9mBOoumAoRCAzqmcBNRt0Z6oLgnSJERsWJGmmqEQRKERd0eg6ViLrC QoRU+RVh9CQfCdgHIIIVvbx+hfXw6gRlw9NVru9OSMO6ptEoTqwLHGTJBJY0sdiBg7cuFnfqdnAO 6vRujVJbUDfVGVSv+tbvWW5ziSMhyNNbHxjVH+Lq1oe4qmXr7arcbl13UcHCxRxT42QQ2YOl6lUG LEQIUQfcvA1YqmAG3NiD1QALEarB8jdgOV7HCfFStkergRZCVKMVbKEVuZEqBO/RaqCFENVohRu0 XDcCau25ZUKScVsIUY1WZwutju9hVNpbYjMiIkQ1WtEGLYRKFZP2ltiwRISoRqu7hVYYdPZeHq8l TW4hRCotV/+1rpNUvG9u/ok9+AcAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABw cHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfny ki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAaj c3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZx VNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEAlLCXip4BAABvAwAAEQAAAHBwdC92aWV3 UHJvcHMueG1sjFJNTxsxEL1X6n+wfIddIghhlQ2XihNSkbL07tiTjSuvbXmckPDrGdub0IYcuHm+ 3rz3xvPH/WDYDgJqZ1t+c11zBlY6pW3f8tfu6WrGGUZhlTDOQssPgPxx8fPH3Dc7DW8vgRGAxUa0 fBOjb6oK5QYGgdfOg6Xa2oVBRApDX6kg3gh4MNWkrqfVILTl43z4zrxbr7WEX05uB7CxgAQwIhJ5 3GiPRzT/HTQfAAkmT/9PyQiMf0hdy9GobrMdVlZokzJ8QcJtkpTDl5BiwokugHqGdWT4TjbeTSc1 r/6tdc7n0sPtdJpL1VccNFpB2lJg5dKoEjG0wnfu9+ovyIiEn2nIsbgTYSmFoeOUPKZgMRcN7hnd lNYxRbU6r6Xs4WuWyIxTvnFB99qyfcuvHtLsIT+SGuoadyZl/ZbYPmM8vRlNkp9kvQvvnHlHTCc3 Re3YPiZns6MFnyAJ/CQ47zqzw7oI2ME+X2Z06NOsM9FJ7QXVZ+nLsovmI8OTYmq+QKEPWi29kPSt mSTP7unyBCDJtfIsvu3KVT8AAAD//wMAUEsDBBQABgAIAAAAIQBcnEcUTgEAAIkCAAARAAAAcHB0 L3ByZXNQcm9wcy54bWy0kM1qwzAQhO+FvoPRXZFkO3ZsYgc7dqHQQw7tAwhbTgTWD5LyU0rfvcJx S0MvufS2yzKz38x6cxFjcGLGciULQBYYBEx2qudyX4C31ye4AoF1VPZ0VJIV4J1ZsCkfH9Y614ZZ Jh11XrozgTeSNqcFODinc4Rsd2CC2oXSTPrboIygzq9mj3pDz/6BGFGIcYIE5RLMenOPXg0D71ij uqPwAFcTw8aJxB64tt9u+h633zlukEofkl3ci3XzFBwNL8BHmybbNosrmOBoC2MSh7DO2homDYlS jAmuwvQTeA2J857bjpr+WdA9a3vuGuroHNWf/+AJ3hll1eAWnRLomhNpdWZGKz5FJXju60THAmCA yjWaMG8Zm4hUOAkrmGarCsZRmMGqbhpY19VqmSQhXhL8w8gGehzdxNho/l94V8ypTT/+bn1nyi8A AAD//wMAUEsDBBQABgAIAAAAIQBOkTFdmwEAANICAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8klFr2zAUhd8H+w9CTyvMkeV4JRhHZWua UqihtB7p9qZJt6mYLQlJbZJ/P8lJvJSNgl/kc+53r85VfbHtO/QKziuj55hOcoxACyOVXs/x93aZ zTDygWvJO6Nhjnfg8QX7+KEWthLGwZ0zFlxQ4FEkaV8JO8fPIdiKEC+eoed+Eh06ik/G9TzEo1sT y8VvvgZS5Pk56SFwyQMnCZjZkYgPSClGpH1x3QCQgkAHPejgCZ1Q8tcbwPX+vwWDcuLsVdjZeKfD uKdsKfbi6N56NRo3m81kMx3GiPNT8tjcPgxXzZROWQnArJaiCip0wG6u2iVaNA1aXaPG/FJd7Iqu ttb4FwcoJose4k1EiAtAqxbdgzUu1GSsTyThgAfj2Ncuhv2pOEM/YK30YDpKaSEd96GJu3tSIL/t WGM8+M9owbXe1eRfPZU4eFVp96ycDZbxHNsOee17g0QxgWqf11FZTS8X7RKzIqdlRmn82iKvpmVV lD/TbG/qUyL7H/1hwveJXzKaZ/l5S4tELGcnxCOADRO/fYXsDwAAAP//AwBQSwMEFAAGAAgAAAAh AEAJBdBcAgAALgUAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAnFTbjtowEH2v1H+wslLVPkC4lbbUeFvBslQqCxLZ5dmbDGDVsS3bsNCv7yQh EFhUqc3TXE7mcjwz9HaXSrIF64RW/aBZbwQEVKwToVb94DEa1T4HxHmuEi61gn6wBxfcsrdv6Mxq A9YLcARDKNcP1t6bXhi6eA0pd3V0K/QstU25R9WuQr1cihiGOt6koHzYajS6Iew8qASSmjkGDIqI va3/36CJjrP63FO0N1gwo5H2XEYiBfal/YmGJ5UutE0ca7W6NCxE+t0YKWLukRE2EbHVTi89mea1 k5l+ATvTQnkaVoHIBzhsKv9tlPfMpqrmYgugyHytX8j7Tq/9gYZXgHTGLV9ZbtaOdZoIOal0LkUC jn2k4UGiD9qjoUHDQqBjkSSgDl40n+l0MhlIYXJ8KdJ5zCUMkCC25NIBhj4a6Bh49vgzLqxjdOt7 W4i9tsSJ3/j8nYA8cwcZrf1gy63gyiO9GaxQclka5y2LcA4wNvoKPRersKosOgwbRywKfwUWsfJu SSS8BPcPKZDFaykyY9Em5j4noEgxXeKT+Ct8dKt85KUVbBRVHmbmFRFHSn7cRSMynEzI4p5M9LOQ wu/J3c5ot7FAcOvIHCTyj6NIFhGZ43htXG5/wL1BHcxZ+6fAHlJyUzB6YP/C1yLveGq+kpt2lb8L UOeq77QDpDrMVewZoxccDnRquNozLvGAfNvDSqjsOtCwdNCfQv1yjybSQ+6hnNFzI52vuYUEb0np PxnoGMfTyizIYM3VCpIS89qRbftTcf5Ys1Nv4JcvdmnL9rU8dOwPAAAA//8DAFBLAQItABQABgAI AAAAIQBKqkPnEAIAAGAQAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAASQQAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAAAAAAfwcAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAA AAAAfggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAewkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAHYFU4xfAQAAGwcAAB8AAAAAAAAAAAAAAAAAeAoAAHBwdC9fcmVs cy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAA AAAAAAAAAAAcDQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAAAZDgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAM6exEMkCAABXDgAAFAAAAAAAAAAAAAAAAAAWDwAAcHB0 L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEA5zT+E44EAADeDAAAFQAAAAAAAAAAAAAA AAAREgAAcHB0L3NsaWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAD6oQ3j3BAAALQ8AABUA AAAAAAAAAAAAAAAA0hYAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQBF9Eja QwUAAFcSAAAVAAAAAAAAAAAAAAAAAPwbAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwECLQAUAAYA CAAAACEAtGTa6mkDAADFCAAAFQAAAAAAAAAAAAAAAAByIQAAcHB0L3NsaWRlcy9zbGlkZTEueG1s UEsBAi0AFAAGAAgAAAAhAGwaTHsEAwAApwYAABUAAAAAAAAAAAAAAAAADiUAAHBwdC9zbGlkZXMv c2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAEUoAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABOKQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAA AAAAAABWKgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABeKwAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAaaJfIR4BAADHBwAA LAAAAAAAAAAAAAAAAABmLAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1s LnJlbHNQSwECLQAUAAYACAAAACEAhMy8bjIIAACPMAAAIQAAAAAAAAAAAAAAAADOLQAAcHB0L3Ns aWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AAAAAAAAAAAAAAAAPzYAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAARzcAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAAAAAAAAAAAAAAAATzgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAHwysIorBAAAVQ0AACIAAAAAAAAAAAAAAAAAVzkA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAzbGCVuQD AAB1DAAAIgAAAAAAAAAAAAAAAADCPQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnht bFBLAQItABQABgAIAAAAIQA6VoR5yQMAAD0MAAAhAAAAAAAAAAAAAAAAAOZBAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAuUnXD64EAABsEQAAIQAAAAAA AAAAAAAAAADuRQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgA AAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA20oAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAA40sAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA60wAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQCVfkih/QQAAKMR AAAhAAAAAAAAAAAAAAAAAPRNAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQSwEC LQAUAAYACAAAACEAqkF3CJMEAAB7EwAAIQAAAAAAAAAAAAAAAAAwUwAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAOFxG7jrBQAAbB0AACEAAAAAAAAAAAAA AAAAAlgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQDU WPs2HQUAAJkSAAAhAAAAAAAAAAAAAAAAACxeAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 OS54bWxQSwECLQAUAAYACAAAACEAoAmJl20FAAB6EwAAIQAAAAAAAAAAAAAAAACIYwAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAhALfv10kQAwAAdQcAACEA AAAAAAAAAAAAAAAANGkAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbFBLAQItABQA BgAIAAAAIQDX0TP2VwMAAPQIAAAhAAAAAAAAAAAAAAAAAINsAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAAZ cAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAI49MGjoEAADHDQAAJQAAAAAAAAAAAAAAAAAhcQAAcHB0L2hhbmRvdXRNYXN0ZXJzL2hh bmRvdXRNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAAAAAAAAAAAAA AJ51AABwcHQvbm90ZXNNYXN0ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BLAQItABQA BgAIAAAAIQCTCm11EwcAAOcdAAAUAAAAAAAAAAAAAAAAAKN2AABwcHQvdGhlbWUvdGhlbWUxLnht bFBLAQItABQABgAIAAAAIQCTCm11EwcAAOcdAAAUAAAAAAAAAAAAAAAAAOh9AABwcHQvdGhlbWUv dGhlbWUyLnhtbFBLAQItABQABgAIAAAAIQCTqn2YuwAAACQBAAAwAAAAAAAAAAAAAAAAAC2FAABw cHQvaGFuZG91dE1hc3RlcnMvX3JlbHMvaGFuZG91dE1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAkwptdRMHAADnHQAAFAAAAAAAAAAAAAAAAAA2hgAAcHB0L3RoZW1lL3RoZW1lMy54bWxQ SwECLQAKAAAAAAAAACEALbT/iABUAAAAVAAAFwAAAAAAAAAAAAAAAAB7jQAAZG9jUHJvcHMvdGh1 bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAKy5MMZ8GAAANHwAAIQAAAAAAAAAAAAAAAACw4QAA cHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANj9jY+sAAAA tgAAABMAAAAAAAAAAAAAAAAAjugAAHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEA lLCXip4BAABvAwAAEQAAAAAAAAAAAAAAAABr6QAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYA CAAAACEAXJxHFE4BAACJAgAAEQAAAAAAAAAAAAAAAAA46wAAcHB0L3ByZXNQcm9wcy54bWxQSwEC LQAUAAYACAAAACEATpExXZsBAADSAgAAEQAAAAAAAAAAAAAAAAC17AAAZG9jUHJvcHMvY29yZS54 bWxQSwECLQAUAAYACAAAACEAQAkF0FwCAAAuBQAAEAAAAAAAAAAAAAAAAACH7wAAZG9jUHJvcHMv YXBwLnhtbFBLBQYAAAAAMwAzAG8PAAAZ8wAAAAA= --_002_F0CF5715D3D1884BAC731EA1103AC28134987CACHASMSX106gercor_-- From nobody Fri Oct 23 06:34: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 A8E4D1A010E for ; Fri, 23 Oct 2015 06:34: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 7zyZkZwqTdng for ; Fri, 23 Oct 2015 06:34:07 -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 716C71A0104 for ; Fri, 23 Oct 2015 06:34:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZE86628; Fri, 23 Oct 2015 13:34:03 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 23 Oct 2015 14:34:02 +0100 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 21:33:49 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYA== Date: Fri, 23 Oct 2015 13:33:48 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.63] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Fri, 23 Oct 2015 13:34:21 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

&n= bsp;

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180SZXEML503MBSchi_-- From nobody Fri Oct 23 08:22:49 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 1F7B21A1EF9 for ; Fri, 23 Oct 2015 08:22:49 -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 lMBWSu_EIwWp for ; Fri, 23 Oct 2015 08:22:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6FE1A212A for ; Fri, 23 Oct 2015 08:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=80568; q=dns/txt; s=iport; t=1445613761; x=1446823361; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t66YqoEnF07wdHCIaMxQFGxI1hIPFqkvhlRca8NiP3k=; b=WuwSKb/QwAyWL97HTAcs/VFtkRjFyizhTZqZoZJ82h1qPPTkWc62U0n6 9IBgVc1uJ3EZhIvsFocoGQobbcbPovcCxb3Lw6XHY6kUXio54q3SDApBu HnG6nqrMkOUQn/5/u0A6A/btTwcT+Wre0qT7zlVx8aHuJFjgkiBUSb2k/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQDGTypW/4cNJK1egmlNVG8GviUBDYFZI4V6AoE9OBQBAQEBAQEBgQqEMgEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcV7AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRiBxMNCgECBIQoBYVIgXqFUoVJg04BhRhpggeCXYI4gVhIg3eSH4NvAR8BAUKCER2BVXIBhTyBBgEBAQ X-IronPort-AV: E=Sophos; i="5.20,186,1444694400"; d="scan'208,217"; a="40278710" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2015 15:22:39 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9NFMcJs005875 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Oct 2015 15:22:38 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 23 Oct 2015 10:22:17 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Fri, 23 Oct 2015 10:22:17 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRDaaakYUlKCiPBU2yND9fo/RrIg== Date: Fri, 23 Oct 2015 15:22:17 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D24F961C1ED777sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Fri, 23 Oct 2015 15:22:49 -0000 --_000_D24F961C1ED777sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don=92t publish the algorithm, its just a number,= and and the MN only knows a bigger value means its most preferred. If I=92= ve two apps, why will I not ever use a best cost prefix ? Does this not all= finally converge to =93most-preferred=94 vs =93not-preferred=94 tags and w= ith Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has =93shorter tunn= el=94, but I=92m afraid prefix-cost alone is not sufficient. This is about = path characterization and it cannot be represented as a single parameter. I= f we want Apps to make meaningful use of it, there needs to be many additio= nal parameters and more than that I do not believe ND is the right containe= r for presenting such data. May be this should be part of routing protocols= ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can=92t send just a single prefix (lowest cost), taking away the higher-= cost prefixes, because the network doesn=92t know how many outstanding refe= rences (open sockets) there are for the high-cost prefix, and it doesn=92t = know the damage it would cause by breaking those ongoing sessions. The MN = needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don=92t see the reason to expose the network mobility management sch= eme to the MN. Why does the MN care that it=92s a tunnel being used, and n= ot a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D24F961C1ED777sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Ok. But, if you send multiple prefixes with different Prefix-Cost valu= es, how will that be used is still the question ?  As you said, Prefix= -Cost is local to that operator, we don=92t publish the algorithm, its just= a number, and and the MN only knows a bigger value means its most preferred. If I=92ve two apps, why will I not = ever use a best cost prefix ? Does this not all finally converge to =93most= -preferred=94 vs =93not-preferred=94 tags and with Prefix-Cost value playin= g no role in the address selection ?

I understand the point around selecting a gateway which has =93shorter= tunnel=94, but I=92m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single paramet= er. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that= I do not believe ND is the right container for presenting such data. May b= e this should be part of routing protocols ? This is like bringing BGP attr= ibutes to Neighbor Discovery, IMO.


Sri



From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6= :33 AM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

We can=92t send just a= single prefix (lowest cost), taking away the higher-cost prefixes, because= the network doesn=92t know how many outstanding references (open sockets) = there are for the high-cost prefix, and it doesn=92t know the damage it would cause by breaking those ongoing sess= ions.  The MN needs to explicitly release a prefix when it is no longe= r using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don=92t see the= reason to expose the network mobility management scheme to the MN.  W= hy does the MN care that it=92s a tunnel being used, and not a set of routi= ng table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

I=92ve = not payed attention to that discussion on the fixed/sustaining/nomadic addr= ess types. But, I don=92t see much relation to this specific extension arou= nd =93prefix-cost=94 and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

&n= bsp;

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don=92t see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.=

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D24F961C1ED777sgundaveciscocom_-- From nobody Fri Oct 23 14:33:56 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 3E8AA1B2A91 for ; Fri, 23 Oct 2015 14:33:55 -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 UJDBWEl3ZlPD for ; Fri, 23 Oct 2015 14:33:53 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 D88651B2A8B for ; Fri, 23 Oct 2015 14:33:52 -0700 (PDT) Received: by yknn9 with SMTP id n9so133548153ykn.0 for ; Fri, 23 Oct 2015 14:33: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 :content-type; bh=UtoPBnQn5I4kb6op7BcQBYqtTovlzon72+9jPQuIwcM=; b=z42AQnOJlxhgLooPQRol8KTy1wOlNqb6qym+vlUcTL1UrvtJaAGQSoLwDhhuxaQk3a Cz+PGDazw7aPnVPI4DNbWsooP7oL3MbeC1bdN6IXHtq+D3cDT/KpsLAqDyWzQVgt3AjX 7vo3Zvnoy5pIhq3Dx8s8NCNcZ8FSwJnvEWUkAZ6/ZSHAw+GZS1Uq+E2WLr+QdGZ+cQFs CM0aAMhqMVPClK2RfLFl63deiVWPQ+hLijvjkuw03k0k3aIJZRu3F8SRf8mOmMSNgExZ 50/TkR8HvacyqTW9Wr+k7VbTPmV2MZTozqBtTMfr505BxZKeKPi0Kc8Yk9DVRrrczKOK n4Aw== MIME-Version: 1.0 X-Received: by 10.129.114.8 with SMTP id n8mr3649865ywc.334.1445636032234; Fri, 23 Oct 2015 14:33:52 -0700 (PDT) Received: by 10.13.233.194 with HTTP; Fri, 23 Oct 2015 14:33:52 -0700 (PDT) In-Reply-To: <562912F6.5010204@gmail.com> References: <562912F6.5010204@gmail.com> Date: Fri, 23 Oct 2015 14:33:52 -0700 Message-ID: From: jouni korhonen To: "dmm@ietf.org" , Jouni , =?UTF-8?B?5oiQIOm5jw==?= Content-Type: multipart/alternative; boundary=001a11473b542d0b340522cc5ee7 Archived-At: Subject: Re: [DMM] Draft IETF94 DMM WG 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: Fri, 23 Oct 2015 21:33:55 -0000 --001a11473b542d0b340522cc5ee7 Content-Type: text/plain; charset=UTF-8 The agenda has been updated. ** DRAFT v2 ** Tuesday November 3, 2015 (JST) 9:00-11:30 Tuesday Morning session I Room: 411/412 9:00 Administrivia & Intro, WG organization & milestones 10 Presenter: Chairs ** DMM track 9:10 AERO, DHCPv6 PD, multi-addressing 10 Presenter: Fred Templin 9:20 Use Cases and API Extension for Source IP 15 Address Selection Presenter: Seil Jeon Draft: draft-sijeon-dmm-use-cases-api-source 9:35 WT Enhanced Mobility Anchoring 15 Presenter: Anthony Chan Draft: draft-chan-dmm-distributed-mobility-anchoring 9:50 WT Exposing mobility state update 15 Presenter: Danny Moses 10:05 Prefix CostCommunicating Prefix Cost to Mobile Nodes 15 Presenter: John Kaippallimalil Draft: draft-mccann-dmm-prefixcost 10:20 Protocol for Forwarding Policy Configuration 20 Presenter: Marco Liebsch Draft: draft-ietf-dmm-fpc-cpdp 10:40 Title: Distributed mobility management deployment 15 scenario and architecture Presenter: Zhiheng Liu Draft: draft-liu-dmm-deployment-scenario ** MIP maintenance track 10:55 LMA Controlled MAG Session Parameters 10 Presenter: Sri Gundavelli Draft: draft-gundavelli-dmm-lma-controlled-mag-params 11:05 MN Identifier Types for RFC 4283 Mobile Node 10 Identifier Option Presenter: Charlie Perkins Draft: draft-ietf-dmm-4283mnids 11:15 Adoption calls for MIP maintenance drafts 10 Presenter: Chairs Drafts: draft-yan-dmm-hnprenum-03 draft-seite-dmm-rg-multihoming-02 11:25 AOB 5 Adjourn 11:30 ** Overflow queue (if we got time left) Deprecated Network Prefix Provision 5 Presenter: Jong-Hyouk Lee Draft: draft-jhlee-dmm-dnpp Motivations, usecases and Models of VCPE 5 Presenter: Qiao Fu Draft: draft-fu-dmm-vcpe-models On Thu, Oct 22, 2015 at 9:46 AM, Jouni Korhonen wrote: > A bit late but here we go. Small adjustments are still possible but not > too likely. > > - Jouni & Dapeng > > Tuesday November 3, 2015 (JST) > 9:00-11:30 Tuesday Morning session I > Room: 411/412 > > 9:00 Administrivia & Intro, WG organization & milestones 15 > Presenter: Chairs > > ** DMM track > > 9:15 AERO, DHCPv6 PD, multi-addressing 15 > Presenter: Fred Templin > > 9:30 Use Cases and API Extension for Source IP 15 > Address Selection > Presenter: Seil Jeon > Draft: draft-sijeon-dmm-use-cases-api-source > > 9:45 WT#1 Exposing mobility state update 15 > Presenter: Danny Moses > > 10:00 Prefix CostCommunicating Prefix Cost to Mobile Nodes 15 > Presenter: John Kaippallimalil > Draft: draft-mccann-dmm-prefixcost > > 10:15 Protocol for Forwarding Policy Configuration 20 > Presenter: Marco Liebsch > Draft: draft-ietf-dmm-fpc-cpdp > > 10:35 Title: Distributed mobility management deployment 15 > scenario and architecture > Presenter: Zhiheng Liu > Draft: draft-liu-dmm-deployment-scenario > > ** MIP maintenance track > > 10:50 LMA Controlled MAG Session Parameters 10 > Presenter: Sri Gundavelli > Draft: draft-gundavelli-dmm-lma-controlled-mag-params > > 11:00 MN Identifier Types for RFC 4283 Mobile Node 10 > Identifier Option > Presenter: Charlie Perkins > Draft: draft-ietf-dmm-4283mnids > > 11:10 Adoption calls for MIP maintenance drafts 10 > Presenter: Chairs > Drafts: draft-yan-dmm-hnprenum-03 > draft-seite-dmm-rg-multihoming-02 > > 11:20 AOB 10 > > Adjourn 11:30 > > ** Overflow queue (if we got time left) > > Deprecated Network Prefix Provision 5 > Presenter: Jong-Hyouk Lee > Draft: draft-jhlee-dmm-dnpp > > Motivations, usecases and Models of VCPE 5 > Presenter: Qiao Fu > Draft: draft-fu-dmm-vcpe-models > > --001a11473b542d0b340522cc5ee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The agenda has been updated.

** DRAFT = v2 **


Tuesday November 3, 2015 (JST)
9:00-11= :30 Tuesday Morning session I
Room: 411/412<= /div>

<= font face=3D"monospace, monospace" size=3D"1">9:00 =C2=A0 =C2=A0Administriv= ia & Intro, WG organization & milestones =C2=A0 =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Chairs

** DMM track

9:10 =C2=A0 =C2=A0AERO, DHCPv6 = PD, multi-addressing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Presenter: =C2=A0 =C2=A0Fred Templin

9:20 =C2=A0 =C2=A0Use Cases and API Extension for Sou= rce IP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Address Selection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Seil Jeon
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-sijeon-dmm-use-cases= -api-source

9:35 =C2= =A0 =C2=A0WT Enhanced Mobility Anchoring =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: Anthony Chan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-chan-dmm-distributed-mobi= lity-anchoring

9:50 = =C2=A0 =C2=A0WT Exposing mobility state update =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Danny Moses

10:05 =C2=A0 Prefix CostCommuni= cating Prefix Cost to Mobile Nodes =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0John Kaippallimalil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-mccann-dmm-= prefixcost

10:20 =C2= =A0 Protocol for Forwarding Policy Configuration =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A020
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pre= senter: =C2=A0 =C2=A0Marco Liebsch
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Draft: draft-ietf-dmm-fpc-cpdp

10:40 =C2=A0 Title: =C2=A0 =C2=A0Distributed mobilit= y management deployment =C2=A0 =C2=A015
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 scenario and architecture
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Zhiheng Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-liu-dmm-deployment-scenario=

** MIP maintenance tr= ack

10:55 =C2=A0 LMA C= ontrolled MAG Session Parameters =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Presenter: =C2=A0 =C2=A0Sri Gundavelli
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draf= t-gundavelli-dmm-lma-controlled-mag-params

11:05 =C2=A0 MN Identifier Types for RFC 4283 Mobile= Node =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Identifier Option
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Charlie P= erkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft:= draft-ietf-dmm-4283mnids

11:15 =C2=A0 Ad= option calls for MIP maintenance drafts =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0= =C2=A0Chairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Drafts: draft-yan-dm= m-hnprenum-03
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 draft-seite-dmm-rg-multihoming-02

11= :25 =C2=A0 =C2=A0AOB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5

=
Adjourn 11:30

** Overflow queu= e (if we got time left)

=C2=A0 =C2=A0 =C2=A0= =C2=A0 Deprecated Network Prefix Provision =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Jong-Hyouk Lee
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Draft: draft-jhlee-dmm-dnpp

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Motivations, usecases and Models of VCPE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Presenter: =C2=A0 =C2=A0Qiao Fu
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-fu-dmm-vcpe-models
<= br>


On Thu, Oct 22, 2015 = at 9:46 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro= te:
A bit late but here we go. Small adju= stments are still possible but not too likely.

- Jouni & Dapeng

Tuesday November 3, 2015 (JST)=C2=A0
9:00-11:30 Tuesday Morning session I=C2=A0 =C2=A0
Room: 411/412=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
9:00=C2=A0 =C2=A0 Administrivia & Intro, WG organization & mileston= es=C2=A0 =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Chairs=C2=A0
** DMM track

9:15=C2=A0 =C2=A0 AERO, DHCPv6 PD, multi-addressing=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Fred Templin=C2= =A0 =C2=A0

9:30=C2=A0 =C2=A0 Use Cases and API Extension for Source IP=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Address Selection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Seil Jeon=C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-sijeon-dmm-use-cases-api-source
9:45=C2=A0 =C2=A0 WT#1 Exposing mobility state update=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Danny Moses=C2= =A0 =C2=A0 =C2=A0

10:00=C2=A0 =C2=A0Prefix CostCommunicating Prefix Cost to Mobile Nodes=C2= =A0 =C2=A0 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 John Kaippallima= lil=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-mccann-dmm-prefixcost

10:15=C2=A0 =C2=A0Protocol for Forwarding Policy Configuration=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Marco Liebsch=C2= =A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-ietf-dmm-fpc-cpdp

10:35=C2=A0 =C2=A0Title:=C2=A0 Distributed mobility management deployment= =C2=A0 =C2=A0 =C2=A0 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scenario and architecture
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Zhiheng Liu=C2= =A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-liu-dmm-deployment-scenario

** MIP maintenance track

10:50=C2=A0 =C2=A0LMA Controlled MAG Session Parameters=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Sri Gundavelli= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-gundavelli-dmm-lma-controlled-mag-= params=C2=A0 =C2=A0

11:00=C2=A0 =C2=A0MN Identifier Types for RFC 4283 Mobile Node=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Identifier Option
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Charlie Perkins =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-ietf-dmm-4283mnids

11:10=C2=A0 =C2=A0Adoption calls for MIP maintenance drafts=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Chairs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Drafts: draft-yan-dmm-hnprenum-03=C2=A0 =C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-seite-dmm-rg-= multihoming-02=C2=A0 =C2=A0 =C2=A0 =C2=A0

11:20=C2=A0 =C2=A0AOB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010

Adjourn 11:30

** Overflow queue (if we got time left)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecated Network Prefix Provision=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05=C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Jong-Hyouk Lee= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-jhlee-dmm-dnpp=C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Motivations, usecases and Models of VCPE=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Presenter:=C2=A0 =C2=A0 =C2=A0 Qiao Fu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft: draft-fu-dmm-vcpe-models


--001a11473b542d0b340522cc5ee7-- From nobody Mon Oct 26 08:19: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 460101B2FE9 for ; Mon, 26 Oct 2015 08:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 C1WOprIlLNc7 for ; Mon, 26 Oct 2015 08:19:42 -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 4D2B01B2FE6 for ; Mon, 26 Oct 2015 08:19:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDA96421; Mon, 26 Oct 2015 15:19:39 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 26 Oct 2015 15:19:37 +0000 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0235.001; Mon, 26 Oct 2015 23:18:56 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYIABwr2A//rE9nA= Date: Mon, 26 Oct 2015 15:18:56 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BFSZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Mon, 26 Oct 2015 15:19:57 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BFSZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BFSZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

&n= bsp;

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BFSZXEML503MBSchi_-- From nobody Mon Oct 26 15:14: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 2FC4A1A6F51 for ; Mon, 26 Oct 2015 15:14:39 -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 EevNA0e9dBsI for ; Mon, 26 Oct 2015 15:14:30 -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 53FBF1A6F3A for ; Mon, 26 Oct 2015 15:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89277; q=dns/txt; s=iport; t=1445897670; x=1447107270; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1aHIxjJLMPw23jxld+dDTLfu7U4Zk1hJtRHUNmiJiV4=; b=Uc2f2rh3uhBxsfjqf082IPHHeJ81FblwHTAiovr0psQCJOKrL66pPADP mJyekyuidqqSE5vsq0teInTGXARYFATlYmZXKDKapYV2Vp5qJvLPAkgFk WL6wN/8XR7khzPGE9LMyCA0AC+4BKXzFkGo1cwCaPc/dq7c+LuypImkxp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADAgDvpC5W/4ENJK1egmlNVG8Gvj4BDYFaI4V6AoE4OBQBAQEBAQEBgQqEMgEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcV3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRiBxMNCgECBIQoBYVKgXqFVIVKg1QBhRtpggeCXoI4gVlIg3eSJ4NvAR8BAUKCER2BVXIBhhGBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="scan'208,217";a="201507152" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2015 22:14:28 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9QMESNu017651 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 22:14:28 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 17:13:58 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 17:13:59 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHREDuckYUlKCiPBU2yND9fo/RrIg== Date: Mon, 26 Oct 2015 22:13:59 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D253EE471EDF89sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Mon, 26 Oct 2015 22:14:39 -0000 --_000_D253EE471EDF89sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I=92m not convinced this = even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don=92t necessarily w= ant to send a map of the operator=92s network to the MN. So, I think encap= sulating this information in a single cost metric is both necessary and app= ropriate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don=92t publish the algorithm, its just a number,= and and the MN only knows a bigger value means its most preferred. If I=92= ve two apps, why will I not ever use a best cost prefix ? Does this not all= finally converge to =93most-preferred=94 vs =93not-preferred=94 tags and w= ith Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has =93shorter tunn= el=94, but I=92m afraid prefix-cost alone is not sufficient. This is about = path characterization and it cannot be represented as a single parameter. I= f we want Apps to make meaningful use of it, there needs to be many additio= nal parameters and more than that I do not believe ND is the right containe= r for presenting such data. May be this should be part of routing protocols= ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can=92t send just a single prefix (lowest cost), taking away the higher-= cost prefixes, because the network doesn=92t know how many outstanding refe= rences (open sockets) there are for the high-cost prefix, and it doesn=92t = know the damage it would cause by breaking those ongoing sessions. The MN = needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don=92t see the reason to expose the network mobility management sch= eme to the MN. Why does the MN care that it=92s a tunnel being used, and n= ot a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D253EE471EDF89sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
We are attempting to solve the problem in the wrong layers and/or wron= g protocols.  Traditionally, such aspects are managed in routing proto= cols, DNS layers or in vendor specific schemes. Some of the vendors such as= Akamai has a entire business built around this for CDN selection.  There are sophisticated measurement techniqu= es.   There are also other query based schemes with DNS. DNS SRV recor= ds are specifically introduced for such localized node selection; Directory= services based on LDAP/MSFT AD use such schemes.  We can certainly bring that complexity into the access gateway and i= nto ND, and without being prescriptive on  the approach, or how it eve= n remotely helps in address selection on an application basis, but I do not= see any one using it. I will not repeat my other comments, but I=92m not convinced this even works, or if the choice = of the protocol is right. 

I suggest we should get this reviewed in 6MAN WG and get some better f= eedback.


cheers
Sri






From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8= :18 AM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n=92t necessarily want to send a map of the operator=92s network to the MN.=   So, I think encapsulating this information in a single cost metric i= s both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailt= o:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don=92t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I=92ve two apps, why will I not ever use a best c= ost prefix ? Does this not all finally converge to =93most-preferred=94 vs = =93not-preferred=94 tags and with Prefix-Cost value playing no role in the address selection ?

&n= bsp;

I under= stand the point around selecting a gateway which has =93shorter tunnel=94, = but I=92m afraid prefix-cost alone is not sufficient. This is about path ch= aracterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

We can=92t send just a= single prefix (lowest cost), taking away the higher-cost prefixes, because= the network doesn=92t know how many outstanding references (open sockets) = there are for the high-cost prefix, and it doesn=92t know the damage it would cause by breaking those ongoing sess= ions.  The MN needs to explicitly release a prefix when it is no longe= r using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don=92t see the= reason to expose the network mobility management scheme to the MN.  W= hy does the MN care that it=92s a tunnel being used, and not a set of routi= ng table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I=92ve = not payed attention to that discussion on the fixed/sustaining/nomadic addr= ess types. But, I don=92t see much relation to this specific extension arou= nd =93prefix-cost=94 and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don=92t see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.=

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D253EE471EDF89sgundaveciscocom_-- From nobody Mon Oct 26 18:24:04 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 348931B326F for ; Mon, 26 Oct 2015 18:24:03 -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 rm6VxI9AneLa for ; Mon, 26 Oct 2015 18:23:46 -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 165BC1B326D for ; Mon, 26 Oct 2015 18:23:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZH88778; Tue, 27 Oct 2015 01:23:43 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Oct 2015 01:23:31 +0000 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 09:22:58 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYIABwr2A//rE9nABTKH6gP//R2rA Date: Tue, 27 Oct 2015 01:22:57 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Tue, 27 Oct 2015 01:24:03 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't understand why you think it needs to be so complicated. It seems m= uch simpler than the other prefix coloring approaches I have seen being sug= gested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I'm not convinced this ev= en works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t understa= nd why you think it needs to be so complicated.  It seems much simpler= than the other prefix coloring approaches I have seen being suggested, and= much easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I’m not convinced this even works, or if the choice of the p= rotocol is right. 

&n= bsp;

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

&n= bsp;

&n= bsp;

cheers<= o:p>

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6SZXEML503MBSchi_-- From nobody Wed Oct 28 09:55:06 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 9536C1A92F4 for ; Wed, 28 Oct 2015 09:54:55 -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 kiTUIjLMwoyU for ; Wed, 28 Oct 2015 09:54:45 -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 028521B5B24 for ; Wed, 28 Oct 2015 09:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97484; q=dns/txt; s=iport; t=1446050568; x=1447260168; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=f88fMXtMy4eBXDw2Qfpdw9jYq+poWTiJICcKO8ZCn/k=; b=jTLVlaD6aQ/NwitsryAhdakYduRMSEtY6ZJan3fnWXNtWi5kX/dq1Jlx 9wRMwdg9ymat0cWqUZnwzLXja9zWlSkOqMdmfYjfA6RnqiZnWCWxXgByY emXBNkJmPs7Wtxy4wbvjCAYybykuND8aj074XUkQcWVR2lls14vlsF2+H c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdAgB2+jBW/4gNJK1egmlNVG8Gvw4BDYFaI4V4AoE8OBQBAQEBAQEBgQqENQEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcYVAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRFIAcTDQoBAgSEKAWFTYF6hVSFSoNYAYUbaYIHgl+COYFZSIN3kiyDbwEfAQFCghEdgVZyAYR2gQYBAQE X-IronPort-AV: E=Sophos; i="5.20,210,1444694400"; d="scan'208,217"; a="44794000" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 28 Oct 2015 16:42:45 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9SGgjms028822 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 16:42:45 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 28 Oct 2015 11:42:20 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Wed, 28 Oct 2015 11:42:20 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHREZ+ckYUlKCiPBU2yND9fo/RrIg== Date: Wed, 28 Oct 2015 16:42:20 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D25647451EE4F1sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 28 Oct 2015 16:54:55 -0000 --_000_D25647451EE4F1sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you look at the network design of any SP=92s network archtecture, they e= nsure the latency between two points in the back-haul network does not exce= ed =93n=94 msecs. So, there is a local gateway and two remote gateways, the= new logic that inserted in the access gateway will give you prefix-cost of= 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or= 2 ? It always coverges to local or remote, similar to the current home or = roam. If there is any latency differential, that is largely due to radio or= the application server, and the prefix cost does not include either of the= m. Fundamentally, the approach of application selecting a prefix that is ba= sed on some thing called prefix-cost, for which there is no published algor= ithm is not some thing I=92m able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don=92t know if MIF guys would have a clue about this, but 6man and = Routing guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don=92t understand why you think it needs to be so complicated. It seems= much simpler than the other prefix coloring approaches I have seen being s= uggested, and much easier to see how applications would use the information= . I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I=92m not convinced this = even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don=92t necessarily w= ant to send a map of the operator=92s network to the MN. So, I think encap= sulating this information in a single cost metric is both necessary and app= ropriate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don=92t publish the algorithm, its just a number,= and and the MN only knows a bigger value means its most preferred. If I=92= ve two apps, why will I not ever use a best cost prefix ? Does this not all= finally converge to =93most-preferred=94 vs =93not-preferred=94 tags and w= ith Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has =93shorter tunn= el=94, but I=92m afraid prefix-cost alone is not sufficient. This is about = path characterization and it cannot be represented as a single parameter. I= f we want Apps to make meaningful use of it, there needs to be many additio= nal parameters and more than that I do not believe ND is the right containe= r for presenting such data. May be this should be part of routing protocols= ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can=92t send just a single prefix (lowest cost), taking away the higher-= cost prefixes, because the network doesn=92t know how many outstanding refe= rences (open sockets) there are for the high-cost prefix, and it doesn=92t = know the damage it would cause by breaking those ongoing sessions. The MN = needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don=92t see the reason to expose the network mobility management sch= eme to the MN. Why does the MN care that it=92s a tunnel being used, and n= ot a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D25647451EE4F1sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8410968C7D285A4AA8C06C01001C8322@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
If you look at the network design of any SP=92s network archtecture, t= hey ensure the latency between two points in the back-haul network does not= exceed =93n=94 msecs. So, there is a local gateway and two remote gateways= , the new logic that inserted in the access gateway will give you prefix-cost of 1, 2 and 2. What does the client pick= ? Local prefix with prefix-cost 1 or 2 ? It always coverges to local or re= mote, similar to the current home or roam. If there is any latency differen= tial, that is largely due to radio or the application server, and the prefix cost does not include either of = them. Fundamentally, the approach of application selecting a prefix that is= based on some thing called prefix-cost, for which there is no published al= gorithm is not some thing I=92m able to follow.

> I = agree it might be wise to consult 6man and also MIF. 

Ack; I don=92t know if MIF guys would have a clue about this, but 6man= and Routing guys may give some sensible feedback.


Sri



From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6= :22 PM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

I don=92t understand w= hy you think it needs to be so complicated.  It seems much simpler tha= n the other prefix coloring approaches I have seen being suggested, and muc= h easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I=92m not convinced this even works, or if the choice of the proto= col is right. 

&n= bsp;

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

&n= bsp;

&n= bsp;

cheers<= o:p>

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n=92t necessarily want to send a map of the operator=92s network to the MN.=   So, I think encapsulating this information in a single cost metric i= s both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don=92t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I=92ve two apps, why will I not ever use a best c= ost prefix ? Does this not all finally converge to =93most-preferred=94 vs = =93not-preferred=94 tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has =93shorter tunnel=94, = but I=92m afraid prefix-cost alone is not sufficient. This is about path ch= aracterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can=92t send just a= single prefix (lowest cost), taking away the higher-cost prefixes, because= the network doesn=92t know how many outstanding references (open sockets) = there are for the high-cost prefix, and it doesn=92t know the damage it would cause by breaking those ongoing sess= ions.  The MN needs to explicitly release a prefix when it is no longe= r using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don=92t see the= reason to expose the network mobility management scheme to the MN.  W= hy does the MN care that it=92s a tunnel being used, and not a set of routi= ng table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I=92ve = not payed attention to that discussion on the fixed/sustaining/nomadic addr= ess types. But, I don=92t see much relation to this specific extension arou= nd =93prefix-cost=94 and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don=92t see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.=

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D25647451EE4F1sgundaveciscocom_-- From nobody Wed Oct 28 10:44: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 E910A1B5B2F for ; Wed, 28 Oct 2015 10:44:50 -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 z33kVQRVPW2o for ; Wed, 28 Oct 2015 10:44:33 -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 857EC1B5B37 for ; Wed, 28 Oct 2015 10:44:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZL98134; Wed, 28 Oct 2015 17:44:29 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 28 Oct 2015 17:44:28 +0000 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 01:44:17 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYIABwr2A//rE9nABTKH6gP//R2rA//x/aQD/+GffIA== Date: Wed, 28 Oct 2015 17:44:16 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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, 28 Oct 2015 17:44:51 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP's network archtecture, they ens= ure the latency between two points in the back-haul network does not exceed= "n" msecs. So, there is a local gateway and two remote gateways, the new l= ogic that inserted in the access gateway will give you prefix-cost of 1, 2 = and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? I= t always coverges to local or remote, similar to the current home or roam. = If there is any latency differential, that is largely due to radio or the a= pplication server, and the prefix cost does not include either of them. Fun= damentally, the approach of application selecting a prefix that is based on= some thing called prefix-cost, for which there is no published algorithm i= s not some thing I'm able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don't know if MIF guys would have a clue about this, but 6man and Ro= uting guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't understand why you think it needs to be so complicated. It seems m= uch simpler than the other prefix coloring approaches I have seen being sug= gested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I'm not convinced this ev= en works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

If you = look at the network design of any SP’s network archtecture, they ensu= re the latency between two points in the back-haul network does not exceed = “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to = follow.

&n= bsp;

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

&n= bsp;

Ack; I = don’t know if MIF guys would have a clue about this, but 6man and Rou= ting guys may give some sensible feedback.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

I don’t understa= nd why you think it needs to be so complicated.  It seems much simpler= than the other prefix coloring approaches I have seen being suggested, and= much easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I’m not convinced this even works, or if the choice of the p= rotocol is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75SZXEML503MBSchi_-- From nobody Thu Oct 29 11:54: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 48FDC1A89B8 for ; Thu, 29 Oct 2015 11:54:34 -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 qWl79SlnXSgZ for ; Thu, 29 Oct 2015 11:54:25 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECB11A89AA for ; Thu, 29 Oct 2015 11:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105134; q=dns/txt; s=iport; t=1446144864; x=1447354464; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AvpgdvwnWKUGiOo6XS5cxNmgmKex/mAMFGs9nO3m278=; b=lPGurDqzq43Dl6hM2VE07hF3FhGhemnyphgC0uyl+JyowQnfLJoS5r4W JiHX1xoPJMkkijUK3EjIEX9HTraWfqQKWRIeqiSRnUnysujpOh1OSdMXQ DimHZpXfjSEquWGS4pwdjL+Id3TgQx8kZDsNR25SGxAB7bOwK5tlMVjxm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgA8ajJW/4YNJK1egmlNU28GvyYBDYFaI4V2AoEyOBQBAQEBAQEBgQqENQEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcVCAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRFIAcTDQoBAgSEJwWFTYF6hVSFS4NdAYUcaYIHgl+COYFZSIN3kiyDcQEfAQFCghEdgVZyAYR2gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,215,1444694400"; d="scan'208,217";a="203358497" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2015 18:54:22 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9TIsM3L009673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Oct 2015 18:54:22 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 29 Oct 2015 13:53:56 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 29 Oct 2015 13:53:56 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHREnsphyjVxljecU6hZWFRcH16GA== Date: Thu, 29 Oct 2015 18:53:56 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D257B4621EEEC2sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 29 Oct 2015 18:54:34 -0000 --_000_D257B4621EEEC2sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sure. But, if this all boils down to marking a prefix as a local prefix , o= r a remove prefix (as in this example), then its more a capability indicato= r and not a cost indicator. Prefix-cost can be viewed as a property as the = value in there has no significance any more and it always converge to a bin= ary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-k= orhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell = what is local prefix and what is remote prefix. I=92m also thinking why the= much more generic prefix property scheme (draft-bhandari-dhc-class-based-p= refix, draft-korhonen-dmm-prefix-properties) does not help here. At least= there, inherently there is an aspect of an application selecting a prefix = based on its requirements and not have the network blindly assume the appli= cation requirement and select a gateway that it believes is the best for th= e application. Sri From: Peter McCann = > Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP=92s network archtecture, they e= nsure the latency between two points in the back-haul network does not exce= ed =93n=94 msecs. So, there is a local gateway and two remote gateways, the= new logic that inserted in the access gateway will give you prefix-cost of= 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or= 2 ? It always coverges to local or remote, similar to the current home or = roam. If there is any latency differential, that is largely due to radio or= the application server, and the prefix cost does not include either of the= m. Fundamentally, the approach of application selecting a prefix that is ba= sed on some thing called prefix-cost, for which there is no published algor= ithm is not some thing I=92m able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don=92t know if MIF guys would have a clue about this, but 6man and = Routing guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don=92t understand why you think it needs to be so complicated. It seems= much simpler than the other prefix coloring approaches I have seen being s= uggested, and much easier to see how applications would use the information= . I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I=92m not convinced this = even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don=92t necessarily w= ant to send a map of the operator=92s network to the MN. So, I think encap= sulating this information in a single cost metric is both necessary and app= ropriate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don=92t publish the algorithm, its just a number,= and and the MN only knows a bigger value means its most preferred. If I=92= ve two apps, why will I not ever use a best cost prefix ? Does this not all= finally converge to =93most-preferred=94 vs =93not-preferred=94 tags and w= ith Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has =93shorter tunn= el=94, but I=92m afraid prefix-cost alone is not sufficient. This is about = path characterization and it cannot be represented as a single parameter. I= f we want Apps to make meaningful use of it, there needs to be many additio= nal parameters and more than that I do not believe ND is the right containe= r for presenting such data. May be this should be part of routing protocols= ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can=92t send just a single prefix (lowest cost), taking away the higher-= cost prefixes, because the network doesn=92t know how many outstanding refe= rences (open sockets) there are for the high-cost prefix, and it doesn=92t = know the damage it would cause by breaking those ongoing sessions. The MN = needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don=92t see the reason to expose the network mobility management sch= eme to the MN. Why does the MN care that it=92s a tunnel being used, and n= ot a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D257B4621EEEC2sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <05F881D82C3B3649855BFD655BBBD654@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sure. But, if this all boils down to marking a prefix as a local prefi= x , or a remove prefix (as in this example), then its more a capability ind= icator and not a cost indicator. Prefix-cost can be viewed as a property as= the value in there has no significance any more and it always converge to a binary value. 

I also suspect  Jouni might be wondering as why his earlier draft= , (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it= can tell what is local prefix and what is remote prefix. I=92m also thinki= ng why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-p= roperties)  does not help here.  At least there, inherently there= is an aspect of an application selecting a prefix based on its requirement= s and not have the network blindly assume the application requirement and select a gateway that it believes is the b= est for the application. 


 Sri


From: Peter McCann <Peter.McCann@huawei.com>
Date: Wednesday, October 28, 2015 a= t 10:44 AM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

If you = look at the network design of any SP=92s network archtecture, they ensure t= he latency between two points in the back-haul network does not exceed =93n= =94 msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I=92m able to foll= ow.

&n= bsp;

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

&n= bsp;

Ack; I = don=92t know if MIF guys would have a clue about this, but 6man and Routing= guys may give some sensible feedback.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

I don=92t understand w= hy you think it needs to be so complicated.  It seems much simpler tha= n the other prefix coloring approaches I have seen being suggested, and muc= h easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I=92m not convinced this even works, or if the choice of the proto= col is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n=92t necessarily want to send a map of the operator=92s network to the MN.=   So, I think encapsulating this information in a single cost metric i= s both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don=92t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I=92ve two apps, why will I not ever use a best c= ost prefix ? Does this not all finally converge to =93most-preferred=94 vs = =93not-preferred=94 tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has =93shorter tunnel=94, = but I=92m afraid prefix-cost alone is not sufficient. This is about path ch= aracterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can=92t send just a= single prefix (lowest cost), taking away the higher-cost prefixes, because= the network doesn=92t know how many outstanding references (open sockets) = there are for the high-cost prefix, and it doesn=92t know the damage it would cause by breaking those ongoing sess= ions.  The MN needs to explicitly release a prefix when it is no longe= r using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don=92t see the= reason to expose the network mobility management scheme to the MN.  W= hy does the MN care that it=92s a tunnel being used, and not a set of routi= ng table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I=92ve = not payed attention to that discussion on the fixed/sustaining/nomadic addr= ess types. But, I don=92t see much relation to this specific extension arou= nd =93prefix-cost=94 and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don=92t see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.=

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D257B4621EEEC2sgundaveciscocom_-- From nobody Thu Oct 29 11:59:20 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 788A71A8A06 for ; Thu, 29 Oct 2015 11:59:18 -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 SDLTsh-JA67E for ; Thu, 29 Oct 2015 11:58:59 -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 1E8C21A8A01 for ; Thu, 29 Oct 2015 11:58:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDG37104; Thu, 29 Oct 2015 18:58:56 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Oct 2015 18:58:54 +0000 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Fri, 30 Oct 2015 02:58:43 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYIABwr2A//rE9nABTKH6gP//R2rA//x/aQD/+GffIP/vr5gA/97YlnA= Date: Thu, 29 Oct 2015 18:58:43 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 29 Oct 2015 18:59:18 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We need more than just a binary value. Those tunnels can be long, medium, = short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we r= eference it in the draft). I don't think DHCP is the right protocol to carry this information. If you= believe, as I think you do, that the prefix property will change upon hand= over to a new AR then we shouldn't tie the transmission of the information = to the DHCP state machine. We should not force DHCP to run on every handov= er. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , o= r a remove prefix (as in this example), then its more a capability indicato= r and not a cost indicator. Prefix-cost can be viewed as a property as the = value in there has no significance any more and it always converge to a bin= ary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-k= orhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell = what is local prefix and what is remote prefix. I'm also thinking why the m= uch more generic prefix property scheme (draft-bhandari-dhc-class-based-pre= fix, draft-korhonen-dmm-prefix-properties) does not help here. At least t= here, inherently there is an aspect of an application selecting a prefix ba= sed on its requirements and not have the network blindly assume the applica= tion requirement and select a gateway that it believes is the best for the = application. Sri From: Peter McCann = > Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP's network archtecture, they ens= ure the latency between two points in the back-haul network does not exceed= "n" msecs. So, there is a local gateway and two remote gateways, the new l= ogic that inserted in the access gateway will give you prefix-cost of 1, 2 = and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? I= t always coverges to local or remote, similar to the current home or roam. = If there is any latency differential, that is largely due to radio or the a= pplication server, and the prefix cost does not include either of them. Fun= damentally, the approach of application selecting a prefix that is based on= some thing called prefix-cost, for which there is no published algorithm i= s not some thing I'm able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don't know if MIF guys would have a clue about this, but 6man and Ro= uting guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't understand why you think it needs to be so complicated. It seems m= uch simpler than the other prefix coloring approaches I have seen being sug= gested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I'm not convinced this ev= en works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We need more than just= a binary value.  Those tunnels can be long, medium, short, or non-exi= stent.

 

We do in fact embed th= e prefix cost in korhonen-dmm-prefix-properties (we reference it in the dra= ft).

 

I don’t think DH= CP is the right protocol to carry this information.  If you believe, a= s I think you do, that the prefix property will change upon handover to a n= ew AR then we shouldn’t tie the transmission of the information to the DHCP state machine.  We should not force DHCP = to run on every handover.

 

-Pete

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 29, 2015 2:54 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Sure. B= ut, if this all boils down to marking a prefix as a local prefix , or a rem= ove prefix (as in this example), then its more a capability indicator and n= ot a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more= and it always converge to a binary value. 

&n= bsp;

I also = suspect  Jouni might be wondering as why his earlier draft, (draft-kor= honen-dmm-local-prefix-01) cannot meet the requirement here, it can tell wh= at is local prefix and what is remote prefix. I’m also thinking why the much more generic prefix property scheme (= draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties= )  does not help here.  At least there, inherently there is an as= pect of an application selecting a prefix based on its requirements and not have the network blindly assume the applicatio= n requirement and select a gateway that it believes is the best for the app= lication. 

&n= bsp;

&n= bsp;

 S= ri

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Wednesday, October 28, 2015 at 10:44 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

If you = look at the network design of any SP’s network archtecture, they ensu= re the latency between two points in the back-haul network does not exceed = “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to = follow.

 <= /span>

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

 <= /span>

Ack; I = don’t know if MIF guys would have a clue about this, but 6man and Rou= ting guys may give some sensible feedback.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

I don’t understa= nd why you think it needs to be so complicated.  It seems much simpler= than the other prefix coloring approaches I have seen being suggested, and= much easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I’m not convinced this even works, or if the choice of the p= rotocol is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761SZXEML503MBSchi_-- From nobody Thu Oct 29 12:38: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 7CD4C1A8F40 for ; Thu, 29 Oct 2015 12:38:49 -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 Xzg-_xQElEft for ; Thu, 29 Oct 2015 12:38:40 -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 A45271A8F3D for ; Thu, 29 Oct 2015 12:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=112607; q=dns/txt; s=iport; t=1446147519; x=1447357119; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HNNDlH9DRfqDClElJKq7TmwuvwZ6/Qg1A2mFLiaHRR8=; b=arlBE2pQXMPDYoqFwHDUzIhyk/9SE4yVX0MvoCOOJLhgk7k84voiQ8zN 0qtsO4wgRKi9tB1rlQboPS/bvXKweP8DvXPJpZJrxe4BOeVSNMmoxDmBe ZY26S5r90pQRA9y2V7cT680l8wvzqhM2BhF+wwuZUGJtBppROE6sXClnM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgA8dTJW/5tdJa1egmlNU28GvyYBDYFaI4V2AoEyOBQBAQEBAQEBgQqENQEBAQMBDA4BEjoJAQEFBwcEAgEIEQECAQEBIQEGBzIUAwUBCAIEARIfiAkIDcVFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3g3iBBoRFIAcTDQoBAgSEJwWFTYF6hVSFS4NdAYUcaYIHgl+COYFZSIN3kiyDcQEfAQFCghEdgVZyAYR2gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,215,1444694400"; d="scan'208,217";a="202664244" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2015 19:38:37 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9TJcbAI029806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Oct 2015 19:38:37 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 29 Oct 2015 14:38:11 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 29 Oct 2015 14:38:11 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , John Kaippallimalil , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHREoFYnBdQIsDPJU+B6EZA1dYwEQ== Date: Thu, 29 Oct 2015 19:38:11 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761@SZXEML503-MBS.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761@SZXEML503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D257BF0C1EEEF8sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 29 Oct 2015 19:38:49 -0000 --_000_D257BF0C1EEEF8sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don=92t think this is about a new option, vs an extension to existing opt= ion in some draft. I=92m trying to understand the practical use for that pr= efix-cost parameter. The idea that every base station/AP/some access node i= s constantly doing measurements on the high-speed backhaul links and using = that measurement in gateway selection appears to be a very expensive propos= ition and the real value of that approach is the question here. The differe= nce in the back haul measurements between a access gateway and any gateway = will be insignificant as these are high-speed pipes; the difference is alwa= ys the air interface, or the application server. We should discuss this in Yokohoma. Sri From: Peter McCann = > Date: Thursday, October 29, 2015 at 11:58 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We need more than just a binary value. Those tunnels can be long, medium, = short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we r= eference it in the draft). I don=92t think DHCP is the right protocol to carry this information. If y= ou believe, as I think you do, that the prefix property will change upon ha= ndover to a new AR then we shouldn=92t tie the transmission of the informat= ion to the DHCP state machine. We should not force DHCP to run on every ha= ndover. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , o= r a remove prefix (as in this example), then its more a capability indicato= r and not a cost indicator. Prefix-cost can be viewed as a property as the = value in there has no significance any more and it always converge to a bin= ary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-k= orhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell = what is local prefix and what is remote prefix. I=92m also thinking why the= much more generic prefix property scheme (draft-bhandari-dhc-class-based-p= refix, draft-korhonen-dmm-prefix-properties) does not help here. At least= there, inherently there is an aspect of an application selecting a prefix = based on its requirements and not have the network blindly assume the appli= cation requirement and select a gateway that it believes is the best for th= e application. Sri From: Peter McCann = > Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP=92s network archtecture, they e= nsure the latency between two points in the back-haul network does not exce= ed =93n=94 msecs. So, there is a local gateway and two remote gateways, the= new logic that inserted in the access gateway will give you prefix-cost of= 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or= 2 ? It always coverges to local or remote, similar to the current home or = roam. If there is any latency differential, that is largely due to radio or= the application server, and the prefix cost does not include either of the= m. Fundamentally, the approach of application selecting a prefix that is ba= sed on some thing called prefix-cost, for which there is no published algor= ithm is not some thing I=92m able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don=92t know if MIF guys would have a clue about this, but 6man and = Routing guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don=92t understand why you think it needs to be so complicated. It seems= much simpler than the other prefix coloring approaches I have seen being s= uggested, and much easier to see how applications would use the information= . I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I=92m not convinced this = even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don=92t necessarily w= ant to send a map of the operator=92s network to the MN. So, I think encap= sulating this information in a single cost metric is both necessary and app= ropriate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don=92t publish the algorithm, its just a number,= and and the MN only knows a bigger value means its most preferred. If I=92= ve two apps, why will I not ever use a best cost prefix ? Does this not all= finally converge to =93most-preferred=94 vs =93not-preferred=94 tags and w= ith Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has =93shorter tunn= el=94, but I=92m afraid prefix-cost alone is not sufficient. This is about = path characterization and it cannot be represented as a single parameter. I= f we want Apps to make meaningful use of it, there needs to be many additio= nal parameters and more than that I do not believe ND is the right containe= r for presenting such data. May be this should be part of routing protocols= ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can=92t send just a single prefix (lowest cost), taking away the higher-= cost prefixes, because the network doesn=92t know how many outstanding refe= rences (open sockets) there are for the high-cost prefix, and it doesn=92t = know the damage it would cause by breaking those ongoing sessions. The MN = needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don=92t see the reason to expose the network mobility management sch= eme to the MN. Why does the MN care that it=92s a tunnel being used, and n= ot a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I=92ve not payed attention to that discussion on the fixed/sustaining/nomad= ic address types. But, I don=92t see much relation to this specific extensi= on around =93prefix-cost=94 and the drafts dealing with colorometry. I thou= ght the starting point here was about delivering a prefix-cost which is abo= ut characterizing of a path cost as some number or some representation of t= opological distance; its not dealing with properties or capabilities and at= least the draft does not talk about that. Staying in that context, per my = earlier question, its unclear how the end point will ever pick an address t= hat has lower prefix-cost value, when there is another prefix with a better= prefix-cost value. The prefix-cost has only one implied meaning, bigger th= e better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don=92t see an issue there. As long as you can give a proper= ty name for each of your fifty shades of grey and have a printed card for e= ach of those colors, the AR will decorate the ND container with the right s= et of cards and ship it out on the wire. These properties have well defined= meaning that can be used by applications for matching the app requirement = with the address capabilities. We can certainly argue that we can define in= finite # number of properties (with the long/short tunnel example) and we a= re back in square one, but thats a name space management issue and we will = not allow such color definitions. This is different from the prefix-cost is= sue, where the algorithm is unknown and the value has no universal meaning = and my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around =93fixed=94, =93sustained=94, = and =93nomadic=94 as the only 3 colors. I hope we agree that those three v= alues don=92t really mean anything when sent from the network to the host. = They might make sense in some kind of internal operating system API, but t= hat=92s a separate question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents =93tunneling in effect=94.= However, there are long tunnels and there are short tunnels. A tunnel fr= om the previous base station to the current base station, which are connect= ed by a single Ethernet cable, is no big deal. However, a tunnel to a fore= ign network where the prefix was originally assigned may be using up substa= ntial resources and may be costing the visited operator real money due to i= nterconnection fees. I would like to be able to distinguish between these = two cases. In general, the MN just wants to know =93how much pain am I cau= sing the network operator by holding on to this prefix?=94 The MN doesn=92= t need to know or care about what kind of mechanism (tunneling, routing, or= carrier pigeon) is being used to direct packets destined for the IP addres= s to his current point of attachment. He can just make use of a simple sca= lar value that represents the degree of the operator=92s desire to move him= to a more local, less costly prefix. Simple administratively configured s= calar values are used like this all the time in routing protocols to choose= among disjoint routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that =93state=94 and =93reso= urces=94 associated with the prefix in a single parameter called =93prefix-= cost=94. At the end of the day, the goal is to enable the end-point to make= meaningful use of it. If we say, this value is so local to the operator, = how does my stack on the host make use of it ? I=92m launching two applicat= ions and there are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my= apps use P1 because it has a better cost, but my host not know what that c= ost means as we never published that algorithm. What is the point ? Why not= suppress all prefixes and give a single prefix that is deemed to meet the = app requirement, from the AR point of view ? If we say that, we don=92t specify the algorithm, keep the scope to operato= r=92s end points and domain, then there is truly no need for interop. I th= ink what you guys are looking for is this extension, https://tools.ietf.or= g/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the =93fixed=94 comment, I see where the disconnect is and its my= mistake. I meant to say, there are =93n=94 number of properties that goes = with a prefix; each of those prefixes have well defined meaning. As the pre= fix moves in the network from R1 to R2, properties do change. Property bit = A can be ON at R1, but may be OFF on R2. Your example of =93Tunneled=94 is = OFF at home link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So =93Fixed=94 does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don=92t have to, and we shouldn=92t= , standardize any algorithm for computing this value because every service = provider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that=92s not simple to measure either. An overl= ay tunnel across an IP cloud will be viewed as a single hop with a topologi= cal distance of 1, but there is an IP cloud in between. We can certainly s= ay, it can be any algorithm that presents two remote gateways/prefixes in s= ome order with some derived cost metric, but coming out with that algorithm= is the core issue here. When an access router views two sets of measuremen= ts for two distance gateways, each with different jitter, latency and packe= t loss characteristics, how would the AR make the call ? Would that be base= d on latency, or will that be based on packet loss ? Why jitter and why not= loss ? When there is no one definitive way to compute that, exposing the s= ame to the end point is incorrect as that has an implication on the applica= tion that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is =93Fixed=94 and will always be on-link = I am making a promise that cannot be kept. The MN can always move to an un= affiliated network that is unable to tunnel/route the packets to the curren= t point of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don=92t see any need to be mo= re specific than that. There won=92t be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn=92t) in prefix coloring= . We could explore about =93capabilities=94 in more detail - if we can do so= - that could help other stds bodies understand this better also. Would like to discuss this in more detail=85 Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability =96 there needs to be an associa= tion between the network/radio link provider (PLMN), the configuration of p= olicies of that provider, and the request for addresses in that network. If= the radio network, backhaul and core network (IP address) are through diff= erent providers, there will be agreements among them on consistent handling= of various policies and resources =96 this should be one of them. With regard to changing conditions and traffic patterns =96 so far this dr= aft has focused on prefix cost as a result of additional resources used due= to sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized =85 If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: =96 I=92d like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points =85).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point =96 As we note in the draft wrt policy =96 different service providers may conf= igure the how the cost is interpreted by the host (see chapter 4 =96 Host C= onsiderations). These could be the policy/configuration/other consideratio= ns in 3GPP for a mobile architecture, and perhaps a different set of assump= tions/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like =93Network Considerations=94 and state how host/network = work to deliver consistent prefix cost (but also that the values are out of= scope) =96 would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I=92m not sure how the AR computes this cost and how the end poi= nts make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation =96 what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D257BF0C1EEEF8sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I don=92t think this is about a new option, vs an extension to existin= g option in some draft. I=92m trying to understand the practical use for th= at prefix-cost parameter. The idea that every base station/AP/some access n= ode is constantly doing measurements on the high-speed backhaul links and using that measurement in gateway sel= ection appears to be a very expensive proposition and the real value of tha= t approach is the question here. The difference in the back haul measuremen= ts between a access gateway and any gateway will be insignificant as these are high-speed pipes; the diffe= rence is always the air interface, or the application server.

We should discuss this in Yokohoma.


Sri




From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 29, 2015 at= 11:58 AM
To: Sri Gundavelli <sgundave@cisco.com>, John Kaippallimalil &= lt;John.Kaippallimalil@hu= awei.com>, "dmm@ietf.org&qu= ot; <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version = Notification for draft-mccann-dmm-prefixcost-02.txt

We need more than just= a binary value.  Those tunnels can be long, medium, short, or non-exi= stent.

 

We do in fact embed th= e prefix cost in korhonen-dmm-prefix-properties (we reference it in the dra= ft).

 

I don=92t think DHCP i= s the right protocol to carry this information.  If you believe, as I = think you do, that the prefix property will change upon handover to a new A= R then we shouldn=92t tie the transmission of the information to the DHCP state machine.  We should not force DHCP = to run on every handover.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 29, 2015 2:54 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

Sure. B= ut, if this all boils down to marking a prefix as a local prefix , or a rem= ove prefix (as in this example), then its more a capability indicator and n= ot a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more= and it always converge to a binary value. 

&n= bsp;

I also = suspect  Jouni might be wondering as why his earlier draft, (draft-kor= honen-dmm-local-prefix-01) cannot meet the requirement here, it can tell wh= at is local prefix and what is remote prefix. I=92m also thinking why the much more generic prefix property scheme (draf= t-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties) &n= bsp;does not help here.  At least there, inherently there is an aspect= of an application selecting a prefix based on its requirements and not have the network blindly assume the applicatio= n requirement and select a gateway that it believes is the best for the app= lication. 

&n= bsp;

&n= bsp;

 S= ri

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Wednesday, October 28, 2015 at 10:44 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

If you = look at the network design of any SP=92s network archtecture, they ensure t= he latency between two points in the back-haul network does not exceed =93n= =94 msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I=92m able to foll= ow.

 <= /span>

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

 <= /span>

Ack; I = don=92t know if MIF guys would have a clue about this, but 6man and Routing= guys may give some sensible feedback.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

I don=92t understand w= hy you think it needs to be so complicated.  It seems much simpler tha= n the other prefix coloring approaches I have seen being suggested, and muc= h easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I=92m not convinced this even works, or if the choice of the proto= col is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n=92t necessarily want to send a map of the operator=92s network to the MN.=   So, I think encapsulating this information in a single cost metric i= s both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don=92t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I=92ve two apps, why will I not ever use a best c= ost prefix ? Does this not all finally converge to =93most-preferred=94 vs = =93not-preferred=94 tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has =93shorter tunnel=94, = but I=92m afraid prefix-cost alone is not sufficient. This is about path ch= aracterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can=92t send just a= single prefix (lowest cost), taking away the higher-cost prefixes, because= the network doesn=92t know how many outstanding references (open sockets) = there are for the high-cost prefix, and it doesn=92t know the damage it would cause by breaking those ongoing sess= ions.  The MN needs to explicitly release a prefix when it is no longe= r using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don=92t see the= reason to expose the network mobility management scheme to the MN.  W= hy does the MN care that it=92s a tunnel being used, and not a set of routi= ng table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I=92ve = not payed attention to that discussion on the fixed/sustaining/nomadic addr= ess types. But, I don=92t see much relation to this specific extension arou= nd =93prefix-cost=94 and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don=92t see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around =93fixed=94, =93sustained=94, and =93nomadic=94= as the only 3 colors.  I hope we agree that those three values don=92t really mean anything when sent from the network to the host= .  They might make sense in some kind of internal operating system API= , but that=92s a separate question.=

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents =93tunneling in effect=94.  However, t= here are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know =93how much pain am I causing the = network operator by holding on to this prefix?=94  The MN doesn=92t need to know or care about what kind of mechanism (tunnel= ing, routing, or carrier pigeon) is being used to direct packets destined f= or the IP address to his current point of attachment.  He can just mak= e use of a simple scalar value that represents the degree of the operator=92s desire to move him to a more local, less co= stly prefix.  Simple administratively configured scalar values are use= d like this all the time in routing protocols to choose among disjoint rout= es and they seem to work well.

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that =93state=94 and =93resources= =94 associated with the prefix in a single parameter called =93prefix-cost= =94. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? I=92m= launching two applications and there are two prefixes P1 with P-C=3D5, P2/= P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don=92t specify the algorithm, keep the scope to operator=92s e= nd points and domain, then there is truly no need for interop.  I thin= k what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the =93fixed=94 comment, I see where the disconnect is and its my mistak= e. I meant to say, there are =93n=94 number of properties that goes with a = prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f =93Tunneled=94 is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So =93Fixed=94 does no= t mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don=92t hav= e to, and we shouldn=92t, standardize any algorithm for computing this valu= e because every service provider will have its own topology and regional bo= undaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that=92s not simple to measure either. An overlay tunn= el across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is =93Fixed=94 and will always be on-link I am making a promise = that cannot be kept.  The MN can always move to an unaffiliated networ= k that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don=92t see any need to be more specific th= an that.  There won=92t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn=92t) in prefix coloring .

We could explore about= =93capabilities=94 in more detail  - if we can do so - that could hel= p other stds bodies understand this better also.

Would like to discuss = this in more detail=85=

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability =96 there needs to be an association between the netwo= rk/radio link provider (PLMN), the configuration of policies of that provid= er, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources =96 this should be one of th= em.

 

With regard to changin= g conditions and traffic patterns =96  so far this draft has focused o= n prefix cost as a result of additional resources used due to sub-optimal p= aths/routes as a result of MN mobility.<= o:p>

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized =85

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: =96 I=92d like = to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points =85)..

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point = =96

 

As we note in the draf= t wrt policy =96 different service providers may configure the how the cost= is interpreted by the host (see chapter 4 =96 Host Considerations). These = could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like =93= Network Considerations=94 and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) =96 would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgunda= ve) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I=92m not sure how the AR computes this = cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion =96 what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

 --_000_D257BF0C1EEEF8sgundaveciscocom_-- From nobody Thu Oct 29 13:06: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 3A49C1A910B for ; Thu, 29 Oct 2015 13:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, 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 japOW5ptxC9x for ; Thu, 29 Oct 2015 13:06:41 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 949811A910A for ; Thu, 29 Oct 2015 13:06:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=abUs7d1zYyc+V0qdc3em4gjapxAyMy+ElORrqmeKZAUXbblV0HBNH66a8XEA2B6n; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [43.244.250.254] (helo=[192.168.99.114]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ZrtSz-0008Nt-6h; Thu, 29 Oct 2015 16:06:33 -0400 To: Hakima Chaouchi References: <20151019202134.18863.90218.idtracker@ietfa.amsl.com> <562554FB.3040600@earthlink.net> From: Charlie Perkins Message-ID: <56327C43.80104@earthlink.net> Date: Thu, 29 Oct 2015 13:06:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010702020505080906000808" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7aafb6aa795e3f6c06c69ef7677b964b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 43.244.250.254 Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-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: Thu, 29 Oct 2015 20:06:44 -0000 This is a multi-part message in MIME format. --------------010702020505080906000808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Hakima, I am O.K. with including more MNID types. The short addresses in Zigbee are purely local; that might be a consideration that affects inclusion within a Mobile-IP / dmm oriented draft. I could see arguments either way. Regarding the other identifiers for IoT -- are they proprietary? If there is support for the identifiers listed below I will include them in the next revision. It has been suggested to include short sections that describe each MNID type. Would you be willing to contribute some sample section text for one or more of the RFID types? I don't think it should be very long, and should not be misconstrued as specifying any of the behavior for RFID, only as a description. Regards, Charlie P. On 10/19/2015 10:51 PM, Hakima Chaouchi wrote: > Hi Charles, all, > > The draft is not mentioning the short addresses in Zigbee (16bits), > lot of sensors use that. > > What about the new long range technologies in IoT (Sig Fox, LORA) > > > Do you think we should consider in this draft a possibility of having > logical identifiers as the Internet of Things main architectures today > are pushing to have an abstraction layer between the application > servers processing the data of the objects (that might be mobile).... > > Cheers, > > Hakima > > 2015-10-19 22:39 GMT+02:00 Charlie Perkins > >: > > Hello folks, > > The updated MNIDs draft has been posted. > > I've incorporated potential resolutions for the recent comments, > especially from Sri. I did not make subsections for each type of > MNID, because I am hoping that won't be considered necessary. I > hope to get some more discussion about it from folks on this > mailing list. Or, if I get a sample text for one of the MNIDs, I > can attempt to create similar text for the other MNIDs. Notably, > doing so would make the short draft about 5 times longer. > > Regards, > Charlie P. > > > > On 10/19/2015 1:21 PM, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Distributed Mobility > Management Working Group of the IETF. > > Title : MN Identifier Types for RFC 4283 > Mobile Node Identifier Option > Authors : Charles E. Perkins > Vijay Devarapalli > Filename : draft-ietf-dmm-4283mnids-01.txt > Pages : 8 > Date : 2015-10-19 > > Abstract: > Additional Identifier Types are proposed for use with the > Mobile Node > Identifier Option for MIPv6 (RFC 4283). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01 > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > --------------010702020505080906000808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Hakima,

I am O.K. with including more MNID types.  The short addresses in Zigbee are purely local; that might be a consideration that affects inclusion within a Mobile-IP / dmm oriented draft.  I could see arguments either way.

Regarding the other identifiers for IoT -- are they proprietary?

If there is support for the identifiers listed below I will include them in the next revision.

It has been suggested to include short sections that describe each MNID type.  Would you be willing to contribute some sample section text for one or more of the RFID types?  I don't think it should be very long, and should not be misconstrued as specifying any of the behavior for RFID, only as a description.

Regards,
Charlie P.


On 10/19/2015 10:51 PM, Hakima Chaouchi wrote:
Hi Charles, all,

The draft is not mentioning the short addresses in Zigbee (16bits), lot of sensors use that.

What about the new long range technologies in IoT (Sig Fox, LORA)


Do you think we should consider in this draft a possibility of having logical identifiers as the Internet of Things main architectures today are pushing to have an abstraction layer between the application servers processing the data of the objects (that might be mobile)....

Cheers,

Hakima

2015-10-19 22:39 GMT+02:00 Charlie Perkins <charles.perkins@earthlink.net>:
Hello folks,

The updated MNIDs draft has been posted.

I've incorporated potential resolutions for the recent comments, especially from Sri.  I did not make subsections for each type of MNID, because I am hoping that won't be considered necessary.  I hope to get some more discussion about it from folks on this mailing list.  Or, if I get a sample text for one of the MNIDs, I can attempt to create similar text for the other MNIDs.  Notably, doing so would make the short draft about 5 times longer.

Regards,
Charlie P.



On 10/19/2015 1:21 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Distributed Mobility Management Working Group of the IETF.

         Title           : MN Identifier Types for RFC 4283 Mobile Node Identifier Option
         Authors         : Charles E. Perkins
                           Vijay Devarapalli
        Filename        : draft-ietf-dmm-4283mnids-01.txt
        Pages           : 8
        Date            : 2015-10-19

Abstract:
    Additional Identifier Types are proposed for use with the Mobile Node
    Identifier Option for MIPv6 (RFC 4283).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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


--------------010702020505080906000808-- From nobody Thu Oct 29 13:14:04 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 BDCED1A9245 for ; Thu, 29 Oct 2015 13:14:02 -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 MQJvsWz0wT-F for ; Thu, 29 Oct 2015 13:14:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C211A924A for ; Thu, 29 Oct 2015 13:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12739; q=dns/txt; s=iport; t=1446149636; x=1447359236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jqid7VIxNNyZjJClX4C3O+UEuIamfJ1JbFLRwDw6D9A=; b=Ua+GFyQal+olMQhdr9NPe1Jb8F1NHYSurVjCsFYOA2JPadBW1ngiNBcv CfCTRQCAkTsHOD3DBfJBrv9lGfqD8ZvGwKEV3LLsP5eOcm0pXiuTwERC4 poj5WXwNAFaHABUhbDtYQIU4icG15yO/ExA6i8AzKTNLKBZ6mHWcf2Cpb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANAgD0fDJW/5xdJa1egmlNU28GvyYBDYFaFwEJhXgCgTQ4FAEBAQEBAQGBCoQ1AQEBBAEBAWsLEAIBCA4DAwECKAchBgsUCQgCBAENBYgbAxINwQENhEUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneEfoJTgiwRBwmEJAWWQwGFHIYSgXaBWUiDd45Nh1ABHwEBQoIRHYFWcoR3gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,215,1444694400"; d="scan'208,217";a="203186070" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 29 Oct 2015 20:13:55 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9TKDtH0028186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Oct 2015 20:13:55 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 29 Oct 2015 15:13:29 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Thu, 29 Oct 2015 15:13:29 -0500 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins , Hakima Chaouchi Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-4283mnids-01.txt Thread-Index: AQHREoZGe/dsL1cBGU2k8VNRwYGC1w== Date: Thu, 29 Oct 2015 20:13:29 +0000 Message-ID: References: <20151019202134.18863.90218.idtracker@ietfa.amsl.com> <562554FB.3040600@earthlink.net> <56327C43.80104@earthlink.net> In-Reply-To: <56327C43.80104@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.218] Content-Type: multipart/alternative; boundary="_000_D257CB441EEF50sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-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: Thu, 29 Oct 2015 20:14:02 -0000 --_000_D257CB441EEF50sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charlie, I had the same comment on the missing LORA identifiers. Is that a standard= ? This is another SDO standard. I can provide the text for LORA. Regards Sri From: dmm > on behalf of = Charlie Perkins > Date: Thursday, October 29, 2015 at 1:06 PM To: Hakima Chaouchi > Cc: "dmm@ietf.org" > Subject: Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-01.txt Hello Hakima, I am O.K. with including more MNID types. The short addresses in Zigbee ar= e purely local; that might be a consideration that affects inclusion within= a Mobile-IP / dmm oriented draft. I could see arguments either way. Regarding the other identifiers for IoT -- are they proprietary? If there is support for the identifiers listed below I will include them in= the next revision. It has been suggested to include short sections that describe each MNID typ= e. Would you be willing to contribute some sample section text for one or = more of the RFID types? I don't think it should be very long, and should n= ot be misconstrued as specifying any of the behavior for RFID, only as a de= scription. Regards, Charlie P. On 10/19/2015 10:51 PM, Hakima Chaouchi wrote: Hi Charles, all, The draft is not mentioning the short addresses in Zigbee (16bits), lot of = sensors use that. What about the new long range technologies in IoT (Sig Fox, LORA) Do you think we should consider in this draft a possibility of having logic= al identifiers as the Internet of Things main architectures today are pushi= ng to have an abstraction layer between the application servers processing = the data of the objects (that might be mobile).... Cheers, Hakima 2015-10-19 22:39 GMT+02:00 Charlie Perkins <charles.perkins@earthlink.net>= : Hello folks, The updated MNIDs draft has been posted. I've incorporated potential resolutions for the recent comments, especially= from Sri. I did not make subsections for each type of MNID, because I am = hoping that won't be considered necessary. I hope to get some more discuss= ion about it from folks on this mailing list. Or, if I get a sample text f= or one of the MNIDs, I can attempt to create similar text for the other MNI= Ds. Notably, doing so would make the short draft about 5 times longer. Regards, Charlie P. On 10/19/2015 1:21 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working = Group of the IETF. Title : MN Identifier Types for RFC 4283 Mobile Node Ide= ntifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-01.txt Pages : 8 Date : 2015-10-19 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-4283mnids-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_D257CB441EEF50sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <049C96E72BED6B4E8B1F7BD1F62E8944@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Charlie,

I had the same comment on the missing  LORA identifiers. Is that = a standard ?  This is another SDO standard. I can provide the text for= LORA.



Regards
Sri


From: dmm <dmm-bounces@ietf.org> on behalf of Charlie Perkin= s <charles.perkins@eart= hlink.net>
Date: Thursday, October 29, 2015 at= 1:06 PM
To: Hakima Chaouchi <hakima.chaouchii@gmail.com>
Cc: "dmm@ietf.org" <dmm@ietf.= org>
Subject: Re: [DMM] I-D Action: draf= t-ietf-dmm-4283mnids-01.txt

Hello Hakima,

I am O.K. with including more MNID types.  The short addresses in Zigb= ee are purely local; that might be a consideration that affects inclusion w= ithin a Mobile-IP / dmm oriented draft.  I could see arguments either = way.

Regarding the other identifiers for IoT -- are they proprietary?

If there is support for the identifiers listed below I will include them in= the next revision.

It has been suggested to include short sections that describe each MNID typ= e.  Would you be willing to contribute some sample section text for on= e or more of the RFID types?  I don't think it should be very long, an= d should not be misconstrued as specifying any of the behavior for RFID, only as a description.

Regards,
Charlie P.


On 10/19/2015 10:51 PM, Hakima Chaouchi wrot= e:
Hi Charles, all,

The draft is not mentioning the short addresses in Zigbee (16bits), lot of = sensors use that.

What about the new long range technologies in IoT (Sig Fox, LORA)


Do you think we should consider in this draft a possibility of having logic= al identifiers as the Internet of Things main architectures today are pushi= ng to have an abstraction layer between the application servers processing = the data of the objects (that might be mobile)....

Cheers,

Hakima

2015-10-19 22:39 GMT+02:00 Charlie Perkins <= span dir=3D"ltr"> <charles.perkins@earthlink.net>:
Hello folks,

The updated MNIDs draft has been posted.

I've incorporated potential resolutions for the recent comments, especially= from Sri.  I did not make subsections for each type of MNID, because = I am hoping that won't be considered necessary.  I hope to get some mo= re discussion about it from folks on this mailing list.  Or, if I get a sample text for one of the MNIDs, I can= attempt to create similar text for the other MNIDs.  Notably, doing s= o would make the short draft about 5 times longer.

Regards,
Charlie P.



On 10/19/2015 1:21 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from th= e on-line Internet-Drafts directories.
  This draft is a work item of the Distributed Mobility Management Wor= king Group of the IETF.

         Title          &= nbsp;: MN Identifier Types for RFC 4283 Mobile Node Identifier Option
         Authors         = : Charles E. Perkins
                     = ;      Vijay Devarapalli
        Filename        : draft-iet= f-dmm-4283mnids-01.txt
        Pages           := 8
        Date            := 2015-10-19

Abstract:
    Additional Identifier Types are proposed for use with the Mob= ile Node
    Identifier Option for MIPv6 (RFC 4283).


The IETF datatracker status page for this draft is:
https://datatrack= er.ietf.org/doc/draft-ietf-dmm-4283mnids/

There's also a htmlized version available at:
https://tools.ietf.o= rg/html/draft-ietf-dmm-4283mnids-01

A diff from the previous version is available at:
https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-4283mnids-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<= br>
_______________________________________________
dmm mailing list
= dmm@ietf.org
https://www.ietf.org/mailman/listi= nfo/dmm


_______________________________________________
dmm mailing list
= dmm@ietf.org
https://www.ietf.org/mailman/listi= nfo/dmm


 --_000_D257CB441EEF50sgundaveciscocom_-- From nobody Thu Oct 29 13:42: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 3E7141AC41C for ; Thu, 29 Oct 2015 13:42:15 -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 3r26Fsw6hf1t for ; Thu, 29 Oct 2015 13:41:55 -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 278301AC43C for ; Thu, 29 Oct 2015 13:41:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZN25762; Thu, 29 Oct 2015 20:41:43 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Oct 2015 20:41:42 +0000 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 13:41:26 -0700 From: John Kaippallimalil To: "Sri Gundavelli (sgundave)" , Peter McCann , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YIAAhd4AgAAHIACAAA6LgIAAEk2AgABTZQCAAI/AAIAAHk+AgAS2DwCAAHP3gIAANMyAgAKTNACAABFOAIABpcwAgAABVoCAAAsHgP//lP+Q Date: Thu, 29 Oct 2015 20:41:26 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB21169@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761@SZXEML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.212] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB21169dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 29 Oct 2015 20:42:15 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB21169dfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It does not have to be as dynamic or complex. Just the topology of the netw= ork and resources used in forwarding introduces enough variable costs. Also, backhaul network costs being insignificant is probably valid now, but= with radio bandwidth increases of 100 -1000 times (some trials plan to exc= eed even this with cmw, mmw) in dense radio networks , backhaul costs and f= irst hop route is going to be a big problem. In the draft we've referred to these requirements from NGMN in the Motivati= on section. At this point, I think we are assuming different architectural = (and other) assumptions. Lets discuss in Yokohama. BR, John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't think this is about a new option, vs an extension to existing optio= n in some draft. I'm trying to understand the practical use for that prefix= -cost parameter. The idea that every base station/AP/some access node is co= nstantly doing measurements on the high-speed backhaul links and using that= measurement in gateway selection appears to be a very expensive propositio= n and the real value of that approach is the question here. The difference = in the back haul measurements between a access gateway and any gateway will= be insignificant as these are high-speed pipes; the difference is always t= he air interface, or the application server. We should discuss this in Yokohoma. Sri From: Peter McCann = > Date: Thursday, October 29, 2015 at 11:58 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We need more than just a binary value. Those tunnels can be long, medium, = short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we r= eference it in the draft). I don't think DHCP is the right protocol to carry this information. If you= believe, as I think you do, that the prefix property will change upon hand= over to a new AR then we shouldn't tie the transmission of the information = to the DHCP state machine. We should not force DHCP to run on every handov= er. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , o= r a remove prefix (as in this example), then its more a capability indicato= r and not a cost indicator. Prefix-cost can be viewed as a property as the = value in there has no significance any more and it always converge to a bin= ary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-k= orhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell = what is local prefix and what is remote prefix. I'm also thinking why the m= uch more generic prefix property scheme (draft-bhandari-dhc-class-based-pre= fix, draft-korhonen-dmm-prefix-properties) does not help here. At least t= here, inherently there is an aspect of an application selecting a prefix ba= sed on its requirements and not have the network blindly assume the applica= tion requirement and select a gateway that it believes is the best for the = application. Sri From: Peter McCann = > Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP's network archtecture, they ens= ure the latency between two points in the back-haul network does not exceed= "n" msecs. So, there is a local gateway and two remote gateways, the new l= ogic that inserted in the access gateway will give you prefix-cost of 1, 2 = and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? I= t always coverges to local or remote, similar to the current home or roam. = If there is any latency differential, that is largely due to radio or the a= pplication server, and the prefix cost does not include either of them. Fun= damentally, the approach of application selecting a prefix that is based on= some thing called prefix-cost, for which there is no published algorithm i= s not some thing I'm able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don't know if MIF guys would have a clue about this, but 6man and Ro= uting guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't understand why you think it needs to be so complicated. It seems m= uch simpler than the other prefix coloring approaches I have seen being sug= gested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I'm not convinced this ev= en works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_6561EABF52675C45BCDACA1B4D7AA1171DB21169dfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It does not have to be= as dynamic or complex. Just the topology of the network and resources used= in forwarding introduces enough variable costs.

Also, backhaul network= costs being insignificant is probably valid now, but with radio bandwidth = increases of 100 -1000 times (some trials plan to exceed even this with cmw= , mmw) in dense radio networks , backhaul costs and first hop route is going to be a big problem.<= /p>

In the draft we’= ve referred to these requirements from NGMN in the Motivation section. At t= his point, I think we are assuming different architectural (and other) assu= mptions. 

 

Lets discuss in Yokoha= ma.

 

BR,<= /p>

John=

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 29, 2015 2:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

I don&#= 8217;t think this is about a new option, vs an extension to existing option= in some draft. I’m trying to understand the practical use for that p= refix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul li= nks and using that measurement in gateway selection appears to be a very ex= pensive proposition and the real value of that approach is the question her= e. The difference in the back haul measurements between a access gateway and any gateway will be insignifican= t as these are high-speed pipes; the difference is always the air interface= , or the application server.

&n= bsp;

We shou= ld discuss this in Yokohoma.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 29, 2015 at 11:58 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

We need more than just= a binary value.  Those tunnels can be long, medium, short, or non-exi= stent.

 

We do in fact embed th= e prefix cost in korhonen-dmm-prefix-properties (we reference it in the dra= ft).

 

I don’t think DH= CP is the right protocol to carry this information.  If you believe, a= s I think you do, that the prefix property will change upon handover to a n= ew AR then we shouldn’t tie the transmission of the information to the DHCP state machine.  We should not force DHCP = to run on every handover.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 29, 2015 2:54 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Sure. B= ut, if this all boils down to marking a prefix as a local prefix , or a rem= ove prefix (as in this example), then its more a capability indicator and n= ot a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more= and it always converge to a binary value. 

 <= /span>

I also = suspect  Jouni might be wondering as why his earlier draft, (draft-kor= honen-dmm-local-prefix-01) cannot meet the requirement here, it can tell wh= at is local prefix and what is remote prefix. I’m also thinking why the much more generic prefix property scheme (= draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties= )  does not help here.  At least there, inherently there is an as= pect of an application selecting a prefix based on its requirements and not have the network blindly assume the applicatio= n requirement and select a gateway that it believes is the best for the app= lication. 

 <= /span>

 <= /span>

 S= ri

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Wednesday, October 28, 2015 at 10:44 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

If you = look at the network design of any SP’s network archtecture, they ensu= re the latency between two points in the back-haul network does not exceed = “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to = follow.

 <= /span>

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

 <= /span>

Ack; I = don’t know if MIF guys would have a clue about this, but 6man and Rou= ting guys may give some sensible feedback.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

I don’t understa= nd why you think it needs to be so complicated.  It seems much simpler= than the other prefix coloring approaches I have seen being suggested, and= much easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I’m not convinced this even works, or if the choice of the p= rotocol is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB21169dfweml703chm_-- From nobody Thu Oct 29 13:49: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 7554C1ACCF5 for ; Thu, 29 Oct 2015 13:49: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 iHsEMZfxn5jn for ; Thu, 29 Oct 2015 13:48:47 -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 D05F61ACCF3 for ; Thu, 29 Oct 2015 13:48:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZN26083; Thu, 29 Oct 2015 20:48:44 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Oct 2015 20:48:42 +0000 Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.132]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Fri, 30 Oct 2015 04:48:30 +0800 From: Peter McCann To: John Kaippallimalil , "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Thread-Index: AQHRBe6H506Xx1vSGkWzLTLnkpVlYJ5rKIxAgACO8ID//5n+EIAAf92A//+LD4CADKr/YP//imkAABFDjRD//4uOgP//dw2QgADupgD//utSYIABwr2A//rE9nABTKH6gP//R2rA//x/aQD/+GffIP/vr5gA/97YlnD/vitpgP98RSYA/vgDvbA= Date: Thu, 29 Oct 2015 20:48:29 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9901@SZXEML503-MBS.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171DB1DDD5@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE33@dfweml703-chm> <6561EABF52675C45BCDACA1B4D7AA1171DB1DE9A@dfweml703-chm> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C587E@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C59AF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C5AC1@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C6180@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C79BF@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C7EB6@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C8C75@SZXEML503-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE77D9C9761@SZXEML503-MBS.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171DB21169@dfweml703-chm> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DB21169@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.126] Content-Type: multipart/alternative; boundary="_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9901SZXEML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.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: Thu, 29 Oct 2015 20:49:07 -0000 --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9901SZXEML503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right it's not about measuring latency (the MN can do that itself at the tr= ansport layer). It is really about the network topology and the business r= elationships between providers. If I am borrowing a home address from a re= mote provider, and they are charging me for it while I deliver it on-link t= o the current AR of the MN (using tunneling, routing, whatever) I need to s= omehow reflect that fact to the MN and discourage the use of the prefix for= new connections. However, I am willing to keep it on-link for as long as = the MN has old connections that are still using it. Similar considerations= can apply even within the same provider if I have moved too far from the i= nitial point of assignment - there is a cross-regional tunnel in place that= is costing me OpEx to maintain. I would like to gently urge the MN to sto= p using that prefix, when it is convenient for the MN to do so. -Pete From: John Kaippallimalil Sent: Thursday, October 29, 2015 4:41 PM To: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt It does not have to be as dynamic or complex. Just the topology of the netw= ork and resources used in forwarding introduces enough variable costs. Also, backhaul network costs being insignificant is probably valid now, but= with radio bandwidth increases of 100 -1000 times (some trials plan to exc= eed even this with cmw, mmw) in dense radio networks , backhaul costs and f= irst hop route is going to be a big problem. In the draft we've referred to these requirements from NGMN in the Motivati= on section. At this point, I think we are assuming different architectural = (and other) assumptions. Lets discuss in Yokohama. BR, John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't think this is about a new option, vs an extension to existing optio= n in some draft. I'm trying to understand the practical use for that prefix= -cost parameter. The idea that every base station/AP/some access node is co= nstantly doing measurements on the high-speed backhaul links and using that= measurement in gateway selection appears to be a very expensive propositio= n and the real value of that approach is the question here. The difference = in the back haul measurements between a access gateway and any gateway will= be insignificant as these are high-speed pipes; the difference is always t= he air interface, or the application server. We should discuss this in Yokohoma. Sri From: Peter McCann = > Date: Thursday, October 29, 2015 at 11:58 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We need more than just a binary value. Those tunnels can be long, medium, = short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we r= eference it in the draft). I don't think DHCP is the right protocol to carry this information. If you= believe, as I think you do, that the prefix property will change upon hand= over to a new AR then we shouldn't tie the transmission of the information = to the DHCP state machine. We should not force DHCP to run on every handov= er. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , o= r a remove prefix (as in this example), then its more a capability indicato= r and not a cost indicator. Prefix-cost can be viewed as a property as the = value in there has no significance any more and it always converge to a bin= ary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-k= orhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell = what is local prefix and what is remote prefix. I'm also thinking why the m= uch more generic prefix property scheme (draft-bhandari-dhc-class-based-pre= fix, draft-korhonen-dmm-prefix-properties) does not help here. At least t= here, inherently there is an aspect of an application selecting a prefix ba= sed on its requirements and not have the network blindly assume the applica= tion requirement and select a gateway that it believes is the best for the = application. Sri From: Peter McCann = > Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt The application should always prefer the lowest cost prefix (the more local= one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a ses= sion already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt If you look at the network design of any SP's network archtecture, they ens= ure the latency between two points in the back-haul network does not exceed= "n" msecs. So, there is a local gateway and two remote gateways, the new l= ogic that inserted in the access gateway will give you prefix-cost of 1, 2 = and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? I= t always coverges to local or remote, similar to the current home or roam. = If there is any latency differential, that is largely due to radio or the a= pplication server, and the prefix cost does not include either of them. Fun= damentally, the approach of application selecting a prefix that is based on= some thing called prefix-cost, for which there is no published algorithm i= s not some thing I'm able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don't know if MIF guys would have a clue about this, but 6man and Ro= uting guys may give some sensible feedback. Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I don't understand why you think it needs to be so complicated. It seems m= uch simpler than the other prefix coloring approaches I have seen being sug= gested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can s= uggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong pro= tocols. Traditionally, such aspects are managed in routing protocols, DNS = layers or in vendor specific schemes. Some of the vendors such as Akamai ha= s a entire business built around this for CDN selection. There are sophist= icated measurement techniques. There are also other query based schemes w= ith DNS. DNS SRV records are specifically introduced for such localized nod= e selection; Directory services based on LDAP/MSFT AD use such schemes. We= can certainly bring that complexity into the access gateway and into ND, a= nd without being prescriptive on the approach, or how it even remotely hel= ps in address selection on an application basis, but I do not see any one u= sing it. I will not repeat my other comments, but I'm not convinced this ev= en works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedba= ck. cheers Sri From: Peter McCann = > Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session = with a previously-assigned, but now higher cost, prefix. We have to leave = the address release decision up to the MN because the network does not have= a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multipl= e (inbound) routes that the MN is selecting from. The network needs to pro= vide a hint about which prefix is the most local, direct path to the Intern= et. The network has the topology information, but we don't necessarily wan= t to send a map of the operator's network to the MN. So, I think encapsula= ting this information in a single cost metric is both necessary and appropr= iate. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, h= ow will that be used is still the question ? As you said, Prefix-Cost is l= ocal to that operator, we don't publish the algorithm, its just a number, a= nd and the MN only knows a bigger value means its most preferred. If I've t= wo apps, why will I not ever use a best cost prefix ? Does this not all fin= ally converge to "most-preferred" vs "not-preferred" tags and with Prefix-C= ost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel= ", but I'm afraid prefix-cost alone is not sufficient. This is about path c= haracterization and it cannot be represented as a single parameter. If we w= ant Apps to make meaningful use of it, there needs to be many additional pa= rameters and more than that I do not believe ND is the right container for = presenting such data. May be this should be part of routing protocols ? Thi= s is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann = > Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-co= st prefixes, because the network doesn't know how many outstanding referenc= es (open sockets) there are for the high-cost prefix, and it doesn't know t= he damage it would cause by breaking those ongoing sessions. The MN needs = to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long t= unnel and a short tunnel? They impose dramatically different costs on the = network operator, and we will need to inform the MN about this so it can m= ove its applications off of the high-cost prefix and on to the lower cost p= refixes. I also don't see the reason to expose the network mobility management schem= e to the MN. Why does the MN care that it's a tunnel being used, and not a= set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic= address types. But, I don't see much relation to this specific extension a= round "prefix-cost" and the drafts dealing with colorometry. I thought the = starting point here was about delivering a prefix-cost which is about chara= cterizing of a path cost as some number or some representation of topologic= al distance; its not dealing with properties or capabilities and at least t= he draft does not talk about that. Staying in that context, per my earlier = question, its unclear how the end point will ever pick an address that has = lower prefix-cost value, when there is another prefix with a better prefix-= cost value. The prefix-cost has only one implied meaning, bigger the better= . The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color= palette :), I don't see an issue there. As long as you can give a property= name for each of your fifty shades of grey and have a printed card for eac= h of those colors, the AR will decorate the ND container with the right set= of cards and ship it out on the wire. These properties have well defined m= eaning that can be used by applications for matching the app requirement wi= th the address capabilities. We can certainly argue that we can define infi= nite # number of properties (with the long/short tunnel example) and we are= back in square one, but thats a name space management issue and we will no= t allow such color definitions. This is different from the prefix-cost issu= e, where the algorithm is unknown and the value has no universal meaning an= d my point there its not helping the end point in address selection. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of = the consensus that has seemed to form around "fixed", "sustained", and "nom= adic" as the only 3 colors. I hope we agree that those three values don't = really mean anything when sent from the network to the host. They might ma= ke sense in some kind of internal operating system API, but that's a separa= te question. Now I think we are just debating the size and scope of the color pallette. = In your example, you have a bit that represents "tunneling in effect". Ho= wever, there are long tunnels and there are short tunnels. A tunnel from t= he previous base station to the current base station, which are connected b= y a single Ethernet cable, is no big deal. However, a tunnel to a foreign = network where the prefix was originally assigned may be using up substantia= l resources and may be costing the visited operator real money due to inter= connection fees. I would like to be able to distinguish between these two = cases. In general, the MN just wants to know "how much pain am I causing t= he network operator by holding on to this prefix?" The MN doesn't need to = know or care about what kind of mechanism (tunneling, routing, or carrier p= igeon) is being used to direct packets destined for the IP address to his c= urrent point of attachment. He can just make use of a simple scalar value = that represents the degree of the operator's desire to move him to a more l= ocal, less costly prefix. Simple administratively configured scalar values= are used like this all the time in routing protocols to choose among disjo= int routes and they seem to work well. If you can give me enough colors to describe all these shades of grey I wil= l be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt > It is intended as a measure of the amount of state being maintained in t= he network on behalf of this prefix and the amount of transport resources b= eing expended to tunnel/route the packets to the current point of attachmen= t. This is exactly the point. We cannot represent that "state" and "resources"= associated with the prefix in a single parameter called "prefix-cost". At = the end of the day, the goal is to enable the end-point to make meaningful = use of it. If we say, this value is so local to the operator, how does my = stack on the host make use of it ? I'm launching two applications and there= are two prefixes P1 with P-C=3D5, P2/P-C=3D6, should both my apps use P1 b= ecause it has a better cost, but my host not know what that cost means as w= e never published that algorithm. What is the point ? Why not suppress all = prefixes and give a single prefix that is deemed to meet the app requiremen= t, from the AR point of view ? If we say that, we don't specify the algorithm, keep the scope to operator'= s end points and domain, then there is truly no need for interop. I think = what you guys are looking for is this extension, https://tools.ietf.org/id= /draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt . Regarding the "fixed" comment, I see where the disconnect is and its my mis= take. I meant to say, there are "n" number of properties that goes with a p= refix; each of those prefixes have well defined meaning. As the prefix move= s in the network from R1 to R2, properties do change. Property bit A can be= ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home = link, but ON on a visitor link. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli >, John Ka= ippallimalil >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt So "Fixed" does not mean fixed? What does it mean, exactly? Prefix cost is not about conveying latency or jitter to the MN. The MN can= measure those things end-to-end with transport protocols. It is intended = as a measure of the amount of state being maintained in the network on beha= lf of this prefix and the amount of transport resources being expended to t= unnel/route the packets to the current point of attachment. A prefix alloc= ated originally by a different provider should have a high cost. A prefix = allocated from another region in the same provider would have a medium cost= . A prefix locally allocated by the current AR would have a minimal cost. = It reflects the internal topology of the current access provider and the r= elationship of the current AR to the point where packets would be routed if= the address were fully aggregated. We don't have to, and we shouldn't, st= andardize any algorithm for computing this value because every service prov= ider will have its own topology and regional boundaries. There is no standardized algorithm for setting weights or local preferences= in BGP, and yet the protocol functions by preferring routes with lower val= ues over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Pete, There are no simple way to compute that prefix cost. If we say that it is j= ust a topological distance, that's not simple to measure either. An overlay= tunnel across an IP cloud will be viewed as a single hop with a topologica= l distance of 1, but there is an IP cloud in between. We can certainly say= , it can be any algorithm that presents two remote gateways/prefixes in som= e order with some derived cost metric, but coming out with that algorithm i= s the core issue here. When an access router views two sets of measurements= for two distance gateways, each with different jitter, latency and packet = loss characteristics, how would the AR make the call ? Would that be based = on latency, or will that be based on packet loss ? Why jitter and why not l= oss ? When there is no one definitive way to compute that, exposing the sam= e to the end point is incorrect as that has an implication on the applicati= on that uses that prefix. Regarding the property meta-data that goes with a prefix, it can certainly = change. There is no assumption that property set does not change. A router= R1 hosting a remote prefix may present a different property set, than a ro= uter R2 hosting the same prefix. Updating the same will inform the end-poin= t about the change in network characteristics. What goes into the meta-data= is a set of properties with no ambiguity associated with it. But, here thi= s prefix cost is about path characterization and that is not based on one f= actor, but its a list of factors that cannot be normalized and presented as= a single value. Sri From: Peter McCann = > Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil >, Sri Gundavelli >, "dmm@ietf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Prefix coloring in its current form is not going to work. If I tell the MN that an address is "Fixed" and will always be on-link I am= making a promise that cannot be kept. The MN can always move to an unaffi= liated network that is unable to tunnel/route the packets to the current po= int of attachment. Instead of making promises about the future availability of a prefix, the b= est we can do is inform the MN about the current cost in terms of topologic= al distance from the original point of assignment. The AR/network can use = whatever algorithm it likes to calculate this, as long as it increases with= topological distance from the original point of attachment. Some simple f= unction of the bitwise distance between the assigned address being redirect= ed and a new link-native prefix might suffice. The MN can use whatever alg= orithm it likes to release/acquire addresses, as long as the cheaper ones a= re more preferred over the more expensive. I don't see any need to be more= specific than that. There won't be any interoperability issues. -Pete From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, Thanks for the feedback about what worked (and didn't) in prefix coloring . We could explore about "capabilities" in more detail - if we can do so - t= hat could help other stds bodies understand this better also. Would like to discuss this in more detail... Some notes inline below. John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi John, Thanks for your response. Certainly, operators can define their own definit= ions for the cost metric, but it will still break the end point interoperab= ility. If the industry approach is BYOD, how would you make different devic= es from roaming partners interpret this cost metric that they receive from = the attached common access network ? AR needs provisioning interface to the= end point and it needs policy interface to the respective home networks. A= ssuming those interface exists, still how would a AR ever provide a cost me= tric for two different prefixes from two remote gateways. Its the same back= haul and the conditions/traffic patters are always changing ? With respect to end point interoperability - there needs to be an associati= on between the network/radio link provider (PLMN), the configuration of pol= icies of that provider, and the request for addresses in that network. If t= he radio network, backhaul and core network (IP address) are through differ= ent providers, there will be agreements among them on consistent handling o= f various policies and resources - this should be one of them. With regard to changing conditions and traffic patterns - so far this draf= t has focused on prefix cost as a result of additional resources used due t= o sub-optimal paths/routes as a result of MN mobility. I see the issue you are pointing here: that this mechanism has broader appl= icability than just the change in prefix cost due to mobility. It could ver= y well be that the MN does not move, but yet the cost of supporting the IP = prefix can change due to traffic patterns/other network policies. This needs more thinking to see if it can be generalized ... If we rather acknowledge that metric definition is difficult to specify, in= stead we focus on capability indications. We spent few years in IETF discu= ssing this topic of prefix coloring and may the approach is coloring is wha= t we should look at. Just making sure I understand this: the comment is not about prefix colorin= g vs prefix cost (I think they are complementary), but rather that we shoul= d learn from the issues that prefix coloring draft faced. If so: - I'd like to learn from this and avoid repeating/wasting time. Lets discuss what these general capabilities are (also related to the previ= ous points ...).. Regards Sri From: John Kaippallimalil > Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt Hi Sri, This is a good point - As we note in the draft wrt policy - different service providers may config= ure the how the cost is interpreted by the host (see chapter 4 - Host Consi= derations). These could be the policy/configuration/other considerations i= n 3GPP for a mobile architecture, and perhaps a different set of assumption= s/needs in a cable or BBF network. The host and network mechanisms are in some way related: for example, host = is dynamically configured with S14 or OMA-DM, and the network should use th= e same rules to determine what prefix cost information is sent by the AR in= Router Advertisements. I do agree that the draft does not explicitly say about how the network sid= e is handled (i.e., similar to the chapter on host considerations). We can = add a section like "Network Considerations" and state how host/network work= to deliver consistent prefix cost (but also that the values are out of sco= pe) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefix= cost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the = role of a access gateway and the projected prefix is from a remote gateway,= how would it put a cost ? Our earlier discussions, we always talked about = presenting capabilities of a prefix and not some arbitrary cost metric; tho= se capabilities in the form of attributes allow the MN to pick up a right p= refix. So, I'm not sure how the AR computes this cost and how the end point= s make use of this value. Sri From: dmm > on behalf of = John Kaippallimalil > Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org" > Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost= -02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submissio= n below). The comments addressed include that from the last meeting, as well as discu= ssions on the reflector regarding how this cost can be provided to the host= : 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host.= I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would= be interesting to hear other views. Would appreciate comments and suggestions. John -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IE= TF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title: Communicating Prefix Cost to Mobile Nodes Document date: 2015-10-13 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefi= xcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcos= t/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mccann-dmm-prefix= cost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9901SZXEML503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right it’s not a= bout measuring latency (the MN can do that itself at the transport layer).&= nbsp; It is really about the network topology and the business relationship= s between providers.  If I am borrowing a home address from a remote provider, and they are charging me for it while I de= liver it on-link to the current AR of the MN (using tunneling, routing, wha= tever) I need to somehow reflect that fact to the MN and discourage the use= of the prefix for new connections.  However, I am willing to keep it on-link for as long as the MN has old con= nections that are still using it.  Similar considerations can apply ev= en within the same provider if I have moved too far from the initial point = of assignment – there is a cross-regional tunnel in place that is costing me OpEx to maintain.  I would like to= gently urge the MN to stop using that prefix, when it is convenient for th= e MN to do so.

 

-Pete

 

 

From: John Kai= ppallimalil
Sent: Thursday, October 29, 2015 4:41 PM
To: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

It does not have to be= as dynamic or complex. Just the topology of the network and resources used= in forwarding introduces enough variable costs.

Also, backhaul network= costs being insignificant is probably valid now, but with radio bandwidth = increases of 100 -1000 times (some trials plan to exceed even this with cmw= , mmw) in dense radio networks , backhaul costs and first hop route is going to be a big problem.<= /p>

In the draft we’= ve referred to these requirements from NGMN in the Motivation section. At t= his point, I think we are assuming different architectural (and other) assu= mptions. 

 

Lets discuss in Yokoha= ma.

 

BR,<= /p>

John=

 

 

From: Sri Gund= avelli (sgundave) [mailto:sgundave@ci= sco.com]
Sent: Thursday, October 29, 2015 2:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 

I don&#= 8217;t think this is about a new option, vs an extension to existing option= in some draft. I’m trying to understand the practical use for that p= refix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul li= nks and using that measurement in gateway selection appears to be a very ex= pensive proposition and the real value of that approach is the question her= e. The difference in the back haul measurements between a access gateway and any gateway will be insignifican= t as these are high-speed pipes; the difference is always the air interface= , or the application server.

&n= bsp;

We shou= ld discuss this in Yokohoma.

&n= bsp;

&n= bsp;

Sri

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 29, 2015 at 11:58 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

&n= bsp;

We need more than just= a binary value.  Those tunnels can be long, medium, short, or non-exi= stent.

 

We do in fact embed th= e prefix cost in korhonen-dmm-prefix-properties (we reference it in the dra= ft).

 

I don’t think DH= CP is the right protocol to carry this information.  If you believe, a= s I think you do, that the prefix property will change upon handover to a n= ew AR then we shouldn’t tie the transmission of the information to the DHCP state machine.  We should not force DHCP = to run on every handover.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 29, 2015 2:54 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Sure. B= ut, if this all boils down to marking a prefix as a local prefix , or a rem= ove prefix (as in this example), then its more a capability indicator and n= ot a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more= and it always converge to a binary value. 

 <= /span>

I also = suspect  Jouni might be wondering as why his earlier draft, (draft-kor= honen-dmm-local-prefix-01) cannot meet the requirement here, it can tell wh= at is local prefix and what is remote prefix. I’m also thinking why the much more generic prefix property scheme (= draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties= )  does not help here.  At least there, inherently there is an as= pect of an application selecting a prefix based on its requirements and not have the network blindly assume the applicatio= n requirement and select a gateway that it believes is the best for the app= lication. 

 <= /span>

 <= /span>

 S= ri

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Wednesday, October 28, 2015 at 10:44 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

The application should= always prefer the lowest cost prefix (the more local one).  What is w= rong with that?

 

The only reason you wo= uld use a higher cost prefix is because you had a session already establish= ed on that prefix and needed to keep using it.

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

If you = look at the network design of any SP’s network archtecture, they ensu= re the latency between two points in the back-haul network does not exceed = “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway wil= l give you prefix-cost of 1, 2 and 2. What does the client pick ? Local pre= fix with prefix-cost 1 or 2 ? It always coverges to local or remote, simila= r to the current home or roam. If there is any latency differential, that is largely due to radio or the app= lication server, and the prefix cost does not include either of them. Funda= mentally, the approach of application selecting a prefix that is based on s= ome thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to = follow.

 <= /span>

>&nb= sp;I agree it might b= e wise to consult 6man and also MIF. 

 <= /span>

Ack; I = don’t know if MIF guys would have a clue about this, but 6man and Rou= ting guys may give some sensible feedback.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

I don’t understa= nd why you think it needs to be so complicated.  It seems much simpler= than the other prefix coloring approaches I have seen being suggested, and= much easier to see how applications would use the information.

 

I agree it might be wi= se to consult 6man and also MIF.  Perhaps Brian can suggest how to ope= n the discussion to those other groups.<= o:p>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

We are = attempting to solve the problem in the wrong layers and/or wrong protocols.=  Traditionally, such aspects are managed in routing protocols, DNS la= yers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for = CDN selection.  There are sophisticated measurement techniques.  = There are also other query based schemes with DNS. DNS SRV records are spe= cifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. &nbs= p;We can certainly bring that complexity into the access gateway and into N= D, and without being prescriptive on  the approach, or how it even rem= otely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comme= nts, but I’m not convinced this even works, or if the choice of the p= rotocol is right. 

 <= /span>

I sugge= st we should get this reviewed in 6MAN WG and get some better feedback.

 <= /span>

 <= /span>

cheers<= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

An MN may not use the = lowest-cost prefix because it has an ongoing session with a previously-assi= gned, but now higher cost, prefix.  We have to leave the address relea= se decision up to the MN because the network does not have a reference count for the addresses.   That only e= xists inside the MN.

 

This problem space is = very much like a routing protocol.  There are multiple (inbound) route= s that the MN is selecting from.  The network needs to provide a hint = about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we do= n’t necessarily want to send a map of the operator’s network to= the MN.  So, I think encapsulating this information in a single cost = metric is both necessary and appropriate.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Ok. But= , if you send multiple prefixes with different Prefix-Cost values, how will= that be used is still the question ?  As you said, Prefix-Cost is loc= al to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value mea= ns its most preferred. If I’ve two apps, why will I not ever use a be= st cost prefix ? Does this not all finally converge to “most-preferre= d” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

 <= /span>

I under= stand the point around selecting a gateway which has “shorter tunnel&= #8221;, but I’m afraid prefix-cost alone is not sufficient. This is a= bout path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there= needs to be many additional parameters and more than that I do not believe= ND is the right container for presenting such data. May be this should be = part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

We can’t send ju= st a single prefix (lowest cost), taking away the higher-cost prefixes, bec= ause the network doesn’t know how many outstanding references (open s= ockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing = sessions.  The MN needs to explicitly release a prefix when it is no l= onger using it.

 

Why would you tell me = that I am not allowed to distinguish between a long tunnel and a short tunn= el?  They impose dramatically different costs on the network operator,= and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to= the lower cost prefixes.

 

I also don’t see= the reason to expose the network mobility management scheme to the MN.&nbs= p; Why does the MN care that it’s a tunnel being used, and not a set = of routing table entries?

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

I’= ;ve not payed attention to that discussion on the fixed/sustaining/nomadic = address types. But, I don’t see much relation to this specific extens= ion around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a= prefix-cost which is about characterizing of a path cost as some number or= some representation of topological distance; its not dealing with properti= es or capabilities and at least the draft does not talk about that. Staying in that context, per my earlie= r question, its unclear how the end point will ever pick an address that ha= s lower prefix-cost value, when there is another prefix with a better prefi= x-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by s= ending a single prefix was my point.

 <= /span>

Now, re= garding the specific shade of grey that you are looking  in my color p= alette :), I don’t see an issue there. As long as you can give a prop= erty name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the= ND container with the right set of cards and ship it out on the wire. Thes= e properties have well defined meaning that can be used by applications for= matching the app requirement with the address capabilities. We can certainly argue that we can define infini= te # number of properties (with the long/short tunnel example) and we are b= ack in square one, but thats a name space management issue and we will not = allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown an= d the value has no universal meaning and my point there its not helping the= end point in address selection.

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Ok, now I think we are= getting somewhere.  I was assuming you were part of the consensus tha= t has seemed to form around “fixed”, “sustained”, a= nd “nomadic” as the only 3 colors.  I hope we agree that t= hose three values don’t really mean anything when sent from the network to the = host.  They might make sense in some kind of internal operating system= API, but that’s a separate question.

 

Now I think we are jus= t debating the size and scope of the color pallette.  In your example,= you have a bit that represents “tunneling in effect”.  Ho= wever, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which= are connected by a single Ethernet cable, is no big deal.  However, a= tunnel to a foreign network where the prefix was originally assigned may b= e using up substantial resources and may be costing the visited operator real money due to interconnection fees= .  I would like to be able to distinguish between these two cases.&nbs= p; In general, the MN just wants to know “how much pain am I causing = the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tu= nneling, routing, or carrier pigeon) is being used to direct packets destin= ed for the IP address to his current point of attachment.  He can just= make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, les= s costly prefix.  Simple administratively configured scalar values are= used like this all the time in routing protocols to choose among disjoint = routes and they seem to work well.<= /o:p>

 

If you can give me eno= ugh colors to describe all these shades of grey I will be happy. ;)<= span style=3D"color:black">

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

>&nb= sp; It is intend= ed as a measure of the amount of state being maintained in the network on b= ehalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachm= ent.

 <= /span>

This is= exactly the point. We cannot represent that “state” and “= ;resources” associated with the prefix in a single parameter called &= #8220;prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local = to the operator,  how does my stack on the host make use of it ? IR= 17;m launching two applications and there are two prefixes P1 with P-C=3D5,= P2/P-C=3D6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we neve= r published that algorithm. What is the point ? Why not suppress all prefix= es and give a single prefix that is deemed to meet the app requirement, fro= m the AR point of view ?  

 <= /span>

If we s= ay that, we don’t specify the algorithm, keep the scope to operator&#= 8217;s end points and domain, then there is truly no need for interop. &nbs= p;I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-= ipv6-nd-vendor-spec-options-00.txt . 

 <= /span>

Regardi= ng the “fixed” comment, I see where the disconnect is and its m= y mistake. I meant to say, there are “n” number of properties t= hat goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do c= hange. Property bit A can be ON at R1, but may be OFF on R2. Your example o= f “Tunneled” is OFF at home link, but ON on a visitor link.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, John Kaippallimalil <John.Kaippallimalil@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

So “Fixed”= does not mean fixed?  What does it mean, exactly?

 

Prefix cost is not abo= ut conveying latency or jitter to the MN.  The MN can measure those th= ings end-to-end with transport protocols.  It is intended as a measure= of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources bei= ng expended to tunnel/route the packets to the current point of attachment.=   A prefix allocated originally by a different provider should have a = high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix local= ly allocated by the current AR would have a minimal cost.  It reflects= the internal topology of the current access provider and the relationship = of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t= have to, and we shouldn’t, standardize any algorithm for computing t= his value because every service provider will have its own topology and reg= ional boundaries. 

 

There is no standardiz= ed algorithm for setting weights or local preferences in BGP, and yet the p= rotocol functions by preferring routes with lower values over higher ones.<= /span>

 

-Pete

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; dmm@ietf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Pete,

 <= /span>

There a= re no simple way to compute that prefix cost. If we say that it is just a t= opological distance, that’s not simple to measure either. An overlay = tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud &n= bsp;in between. We can certainly say, it can be any algorithm that presents= two remote gateways/prefixes in some order with some derived cost metric, = but coming out with that algorithm is the core issue here. When an access router views two sets of measurements = for two distance gateways, each with different jitter, latency and packet l= oss characteristics, how would the AR make the call ? Would that be based o= n latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one defini= tive way to compute that, exposing the same to the end point is incorrect a= s that has an implication on the application that uses that prefix.<= span style=3D"color:black">

 <= /span>

Regardi= ng the property meta-data that goes with a prefix, it can certainly change.=  There is no assumption that property set does not change. A router R= 1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same = will inform the end-point about the change in network characteristics. What= goes into the meta-data is a set of properties with no ambiguity associate= d with it. But, here this prefix cost is about path characterization and that is not based on one factor, b= ut its a list of factors that cannot be normalized and presented as a singl= e value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: Peter McCann <Peter.McCann@huawei.com>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Prefix coloring in its= current form is not going to work.=

 

If I tell the MN that = an address is “Fixed” and will always be on-link I am making a = promise that cannot be kept.  The MN can always move to an unaffiliate= d network that is unable to tunnel/route the packets to the current point of attachment.

 

Instead of making prom= ises about the future availability of a prefix, the best we can do is infor= m the MN about the current cost in terms of topological distance from the o= riginal point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it incre= ases with topological distance from the original point of attachment. = Some simple function of the bitwise distance between the assigned address = being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to = release/acquire addresses, as long as the cheaper ones are more preferred o= ver the more expensive.  I don’t see any need to be more specifi= c than that.  There won’t be any interoperability issues.

 

-Pete

 

 

From: dmm [mailto:dmm-bou= nces@ietf.org] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); dmm@i= etf.org
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi Sri,

Thanks for the feedbac= k about what worked (and didn’t) in prefix coloring .

We could explore about= “capabilities” in more detail  - if we can do so - that c= ould help other stds bodies understand this better also.

Would like to discuss = this in more detail…

 

Some notes inline belo= w.

 

John

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

Hi John= ,

 <= /span>

Thanks = for your response. Certainly, operators can define their own definitions fo= r the cost metric, but it will still break the end point interoperability. = If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost= metric that they receive from the attached common access network ? AR need= s provisioning interface to the end point and it needs policy interface to = the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric fo= r two different prefixes from two remote gateways. Its the same backhaul an= d the conditions/traffic patters are always changing ?  

 

With respect to end po= int interoperability – there needs to be an association between the n= etwork/radio link provider (PLMN), the configuration of policies of that pr= ovider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are = through different providers, there will be agreements among them on consist= ent handling of various policies and resources – this should be one o= f them.

 

With regard to changin= g conditions and traffic patterns –  so far this draft has focus= ed on prefix cost as a result of additional resources used due to sub-optim= al paths/routes as a result of MN mobility.

I see the issue you ar= e pointing here: that this mechanism has broader applicability than just th= e change in prefix cost due to mobility. It could very well be that the MN = does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies. <= br> This needs more thinking to see if it can be generalized …

 <= /span>

If we r= ather acknowledge that metric definition is difficult to specify, instead w= e focus on capability indications.  We spent few years in IETF discuss= ing this topic of prefix coloring and may the approach is coloring is what we should look at.

Just making sure I und= erstand this: the comment is not about prefix coloring vs prefix cost (I th= ink they are complementary), but rather that we should learn from the issue= s that prefix coloring draft faced.=

If so: – I’= ;d like to learn from this and avoid repeating/wasting time.

Lets discuss what thes= e general capabilities are (also related to the previous points …)..<= /span>

 <= /span>

Regards=

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <sgundav= e@cisco.com>, "dmm@ietf.org= " <dmm@ietf.org>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 <= /span>

Hi Sri,

This is a good point &= #8211;

 

As we note in the draf= t wrt policy – different service providers may configure the how the = cost is interpreted by the host (see chapter 4 – Host Considerations)= . These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different = set of assumptions/needs in a cable or BBF network.

The host and network m= echanisms are in some way related: for example, host is dynamically configu= red with S14 or OMA-DM, and the network should use the same rules to determ= ine what prefix cost information is sent by the AR in Router Advertisements.

 

I do agree that the dr= aft does not explicitly say about how the network side is handled (i.e., si= milar to the chapter on host considerations). We can add a section like = 220;Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the val= ues are out of scope) – would that address your concern?

 

John

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; dmm@ietf.or= g
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm= -prefixcost-02.txt

 =

John:

 <= /span>

How wou= ld the AR know the cost of a prefix ? Assuming the AR is taking the role of= a access gateway and the projected prefix is from a remote gateway, how wo= uld it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some ar= bitrary cost metric; those capabilities in the form of attributes allow the= MN to pick up a right prefix. So, I’m not sure how the AR computes t= his cost and how the end points make use of this value.

 <= /span>

 <= /span>

Sri

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: dmm <dmm= -bounces@ietf.org> on behalf of John Kaippallimalil <John.Kaippallimalil@huawei.com>= ;
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-pre= fixcost-02.txt

 <= /span>

Hi,=

We have posted a new = version of the Prefix Cost draft (please see submission below).<= /span>

 

The comments addresse= d include that from the last meeting, as well as discussions on the reflect= or regarding how this cost can be provided to the host:

1. What is the motiva= tion – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require = additional signaling?
   [No additional signaling incurred in this mechanism - sub opti= on of RA]

3. Does this impact L= 2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing= e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/appli= cation behavior when prefix cost changes?
   The updates provide some details on what can/should be done in= the host. I think that detailed mechanisms should be

   add= ressed in a companion/other draft related to APIs, etc. But, it would be in= teresting to hear other views.

 

Would appreciate comm= ents and suggestions.

 

John

 

 

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

 

 

A new version of I-D,= draft-mccann-dmm-prefixcost-02.txt

has been successfully= submitted by John Kaippallimalil and posted to the IETF repository.

 

Name:  &nbs= p;    draft-mccann-dmm-prefixcost

Revision:  = 02

Title:  &nb= sp;         Communicating Prefix Co= st to Mobile Nodes

Document date: &= nbsp;  2015-10-13

Group:  &nb= sp;         Individual Submission

Pages:  &nb= sp;         9

URL:   = ;         https://www.ietf.org/= internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:  &n= bsp;      https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:  =      https://tools.ietf.or= g/html/draft-mccann-dmm-prefixcost-02

Diff:  &nbs= p;        https://www.ietf.org/= rfcdiff?url2=3Ddraft-mccann-dmm-prefixcost-02<= /p>

 

Abstract:<= /span>

   In a net= work implementing Distributed Mobility Management, it has=

   been agr= eed that Mobile Nodes (MNs) should exhibit agility in their

   use of I= P addresses.  For example, an MN might use an old address for

   ongoing = socket connections but use a new, locally assigned address

   for new = socket connections.  Determining when to assign a new

   address,= and when to release old addresses, is currently an open<= /p>

   problem.=   Making an optimal decision about address assignment and

   release = must involve a tradeoff in the amount of signaling used to

   allocate= the new addresses, the amount of utility that applications

   are deri= ving from the use of a previously assigned address, and the

   cost of = maintaining an address that was assigned at a previous point

   of attac= hment.  As the MN moves farther and farther from the initial

   point wh= ere an address was assigned, more and more resources are used

   to redir= ect packets destined for that IP address to its current

   location= .  The MN currently does not know the amount of resources

   used as = this depends on mobility path and internal routing topology

   of the n= etwork(s) which are known only to the network operator.  This

   document= provides a mechanism to communicate to the MN the cost of

   maintain= ing a given prefix at the MN's current point of attachment so

   that the= MN can make better decisions about when to release old

   addresse= s and assign new ones.

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

 

 

Please note that it m= ay 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<= o:p>

 

--_000_5963DDF1F751474D8DEEFDCDBEE43AE77D9C9901SZXEML503MBSchi_-- From nobody Sat Oct 31 02:33: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 5A98B1A6F6B for ; Sat, 31 Oct 2015 02:33:39 -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 Y2LTEfGxtb9d for ; Sat, 31 Oct 2015 02:33:35 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345E61A6F6F for ; Sat, 31 Oct 2015 02:33:35 -0700 (PDT) Received: by vkfw189 with SMTP id w189so60953117vkf.2 for ; Sat, 31 Oct 2015 02:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mKZyEpLBahnMO5v8Q1jETk+J0CK/dTDIb1zVP7+DRrM=; b=TZLfqbCDKk+TgFKh4i7Bi6u/1tjx9vLn07arap94NLPz/agtkIv0pbAF2EU1FOTG7S 6yK/oChZL2fRUSql5dgXbSBHQGVDjwOlduBLKVSWHVa447zq4n4h4WtslmjHCq+dLwp+ UdHRFL4WFiJyJibBwU0SiFhm/LApqhs/Yd8UvQLZotSLFMugoCpB2Yzc4fuvYayPaVBv uRLowKE4IMi7jZFmELv5mgBuM3gvtyehJ4Of5EK1+KlCRPNPoUfZ20Y3EcOFWND+6/gK ELti6cnXbM086AxRR1AdZAedSyyjv/O3asksRxihEphIlG94KqB6T87j87mMyrjAbn6t 8xdA== MIME-Version: 1.0 X-Received: by 10.31.6.19 with SMTP id 19mr8533525vkg.0.1446284014369; Sat, 31 Oct 2015 02:33:34 -0700 (PDT) Received: by 10.31.3.24 with HTTP; Sat, 31 Oct 2015 02:33:34 -0700 (PDT) Date: Sat, 31 Oct 2015 17:33:34 +0800 Message-ID: From: Dapeng Liu To: dmm Content-Type: multipart/alternative; boundary=001a1143f256ebbf810523633cec Archived-At: Subject: [DMM] IETF94 DMM presentation slides 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: Sat, 31 Oct 2015 09:33:39 -0000 --001a1143f256ebbf810523633cec Content-Type: text/plain; charset=UTF-8 Our session will be on Tuesday morning, please send your slides to chairs as soon as possible. ------ Best Regards, Dapeng Liu --001a1143f256ebbf810523633cec Content-Type: text/html; charset=UTF-8
Our session will be on Tuesday morning, please send your slides to chairs as soon as possible.

------
Best Regards,
Dapeng Liu
--001a1143f256ebbf810523633cec-- From chaouchi@telecom-sudparis.eu Mon Oct 19 23:14: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 50D6E1A1A91 for ; Mon, 19 Oct 2015 23:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dsFB4OvmAVI for ; Mon, 19 Oct 2015 23:13:57 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id 52BFA1A1ABF for ; Mon, 19 Oct 2015 23:13:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id D4B8EFFC17; Tue, 20 Oct 2015 08:13:51 +0200 (CEST) Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id urpUoW38_kqU; Tue, 20 Oct 2015 08:13:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 5A7B9FFC58; Tue, 20 Oct 2015 08:13:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dl2DmM8ODRAk; Tue, 20 Oct 2015 08:13:51 +0200 (CEST) Received: from zmail121.enst.fr (zmail121.enst.fr [137.194.5.74]) by zproxy120.enst.fr (Postfix) with ESMTP id 39CFAFFC17; Tue, 20 Oct 2015 08:13:51 +0200 (CEST) Date: Tue, 20 Oct 2015 08:13:50 +0200 (CEST) From: Hakima Chaouchi To: Charlie Perkins Message-ID: <860297957.61370921.1445321630957.JavaMail.zimbra@telecom-sudparis.eu> In-Reply-To: <55D38CC3.9030300@earthlink.net> References: <55CB91DB.3030509@gmail.com> <55D37CDD.5030108@gmail.com> <55D38CC3.9030300@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [82.228.132.230] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF19 (Win)/8.0.7_GA_6021) Thread-Topic: I-D Action: draft-ietf-dmm-4283mnids-01.txt Thread-Index: jD/r3DqNbt8TGV6CVDNC9CcmcqTAeA== Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 08:41:48 -0700 Cc: dmm@ietf.org Subject: Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-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: Tue, 20 Oct 2015 06:55:35 -0000 Hi Charles, all, The draft is not mentioning the short addresses in Zigbee (16bits), lot of sensors use that. What about the new long range technologies in IoT (Sig Fox, LORA) Do you think we should consider in this draft a possibility of having logical identifiers as the Internet of Things main architectures today are pushing to have an abstraction layer between the application servers processing the data of the objects (that might be mobile).... Cheers, Hakima 2015-10-19 22:39 GMT+02:00 Charlie Perkins : Hello folks, The updated MNIDs draft has been posted. I've incorporated potential resolutions for the recent comments, especially from Sri. I did not make subsections for each type of MNID, because I am hoping that won't be considered necessary. I hope to get some more discussion about it from folks on this mailing list. Or, if I get a sample text for one of the MNIDs, I can attempt to create similar text for the other MNIDs. Notably, doing so would make the short draft about 5 times longer. Regards, Charlie P. On 10/19/2015 1:21 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : MN Identifier Types for RFC 4283 Mobile Node Identifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-01.txt Pages : 8 Date : 2015-10-19 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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