From m_ndeye2@voila.fr Fri Oct 1 07:18:25 2004 Received: from voila43.com ([213.154.88.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18678 for ; Fri, 1 Oct 2004 07:18:23 -0400 (EDT) Message-Id: <200410011118.HAA18678@ietf.org> From: Dr Mohamed Ndeye To: multi6-archive@ietf.org Reply-To: m_ndeye6@voila.fr Subject: From Dr Ndeye Date: Fri, 01 Oct 2004 11:15:23 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1749a23b-f72b-4618-8c52-114779c50bbd" This is a multi-part message in MIME format --1749a23b-f72b-4618-8c52-114779c50bbd Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM THE DESK OF DR.MOHAMED NDEYE AUDITOR, MINISTRY OF HEALTH AND SOCIAL SERVICES, DAKAR SENEGAL. DEAR FRIEND. LETTER FOR URGENT ASSISTANCE ON FUND TRANSFER First,i must solicit your strictest confidence in this transaction.This by viture of its nature as being utterly confidential and TOP SECRET. I got your contact in our search for a foriegn partner who has the ability and reliability to prosecute a transaction of great magnitude involving a pending business transaction requiring maximum confidence. We are top officials of the Federal Ministry of Health and social services = Dakar Senegal, We are intrested in ivestments in your country with funds which are presently trapped here Senegal in other to commence this business we solicit your assistance to enable us transfer into your account = the said trapped funds. The source of this fund is as follows: During our last year Auditing, we find = out that some government officials set up companies and awarded themselves = contracts which were grossly over invoiced in various Ministries, We also = identified a lot of inflated contracts funds which are presently Deposited in = a BANK here in Dakar However,by virture of our position as civil servants and members of the panel ,we cannot acquire this money in our name.I have therefore ,been delegated as a matter of trust by my colleagues of the panel to look for an = overseas patner into whose account we would transfer the total sum of = USD$25,500,000.00 [TWENTY FIVE MILLION,FIVE HUNDRED THOUSAND UNITED STATES DOLLARS]. Hence we are writting you this letter.We agreed to share the money thus: [1] 20% FOR THE ACCOUNT OWNER [YOU] [2] 80% FOR US [THEOFFICALS] It is from the 80% that we wish to commense investments in your country as you will also stand as our foriegn agent over there.Please note that this transaction is 100% safe and we hope to commense the transaction latest seven[7]days from the date of the receipt of the following information bellow. [A] COMPANY=12S NAME BENEFICIARY OF ACCOUNT. [B] YOUR PERSONAL TELEPHONE NUMBER AND FAX NUMBERS. [C] BANK ACCOUNT/SORT/ABA/ROUTING NUMBERS WHICH THE FUND WILL BE TRANSFERED TO . [D]YOUR BANK ADDRESS,TELEPHONE NUMBERS/FAX NUMBERS. The above information will enable us commense the transfer of this funds into your account in your country without delay and also to open an account in your name. We are looking forward to doing this business with you and solict your confidentiality in this transaction. Please acknowledge the receipt of this letter using the above email address,I will bring you into the complete picture of this pending project when i hear from you. With Kind regards, DR.MOHAMED NDEYE --1749a23b-f72b-4618-8c52-114779c50bbd-- From m_ndeye2@voila.fr Fri Oct 1 07:19:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18791 for ; Fri, 1 Oct 2004 07:19:09 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLZr-0004i0-EO for multi6-archive@ietf.org; Fri, 01 Oct 2004 07:27:55 -0400 Received: from [213.154.88.45] (helo=voila29.com) by mx2.foretec.com with smtp (Exim 4.24) id 1CDLRO-0007gB-E2 for multi6-archive@ietf.org; Fri, 01 Oct 2004 07:19:11 -0400 From: Dr Mohamed Ndeye To: multi6-archive@ietf.org Reply-To: m_ndeye6@voila.fr Subject: From Dr Ndeye Date: Fri, 01 Oct 2004 11:16:06 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="220f21c9-88cd-469e-999e-08b94cfa2c0c" Message-Id: X-Spam-Score: 12.2 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format --220f21c9-88cd-469e-999e-08b94cfa2c0c Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM THE DESK OF DR.MOHAMED NDEYE AUDITOR, MINISTRY OF HEALTH AND SOCIAL SERVICES, DAKAR SENEGAL. DEAR FRIEND. LETTER FOR URGENT ASSISTANCE ON FUND TRANSFER First,i must solicit your strictest confidence in this transaction.This by viture of its nature as being utterly confidential and TOP SECRET. I got your contact in our search for a foriegn partner who has the ability and reliability to prosecute a transaction of great magnitude involving a pending business transaction requiring maximum confidence. We are top officials of the Federal Ministry of Health and social services = Dakar Senegal, We are intrested in ivestments in your country with funds which are presently trapped here Senegal in other to commence this business we solicit your assistance to enable us transfer into your account = the said trapped funds. The source of this fund is as follows: During our last year Auditing, we find = out that some government officials set up companies and awarded themselves = contracts which were grossly over invoiced in various Ministries, We also = identified a lot of inflated contracts funds which are presently Deposited in = a BANK here in Dakar However,by virture of our position as civil servants and members of the panel ,we cannot acquire this money in our name.I have therefore ,been delegated as a matter of trust by my colleagues of the panel to look for an = overseas patner into whose account we would transfer the total sum of = USD$25,500,000.00 [TWENTY FIVE MILLION,FIVE HUNDRED THOUSAND UNITED STATES DOLLARS]. Hence we are writting you this letter.We agreed to share the money thus: [1] 20% FOR THE ACCOUNT OWNER [YOU] [2] 80% FOR US [THEOFFICALS] It is from the 80% that we wish to commense investments in your country as you will also stand as our foriegn agent over there.Please note that this transaction is 100% safe and we hope to commense the transaction latest seven[7]days from the date of the receipt of the following information bellow. [A] COMPANY=12S NAME BENEFICIARY OF ACCOUNT. [B] YOUR PERSONAL TELEPHONE NUMBER AND FAX NUMBERS. [C] BANK ACCOUNT/SORT/ABA/ROUTING NUMBERS WHICH THE FUND WILL BE TRANSFERED TO . [D]YOUR BANK ADDRESS,TELEPHONE NUMBERS/FAX NUMBERS. The above information will enable us commense the transfer of this funds into your account in your country without delay and also to open an account in your name. We are looking forward to doing this business with you and solict your confidentiality in this transaction. Please acknowledge the receipt of this letter using the above email address,I will bring you into the complete picture of this pending project when i hear from you. With Kind regards, DR.MOHAMED NDEYE --220f21c9-88cd-469e-999e-08b94cfa2c0c-- From owner-multi6@ops.ietf.org Sun Oct 3 00:03:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28989 for ; Sun, 3 Oct 2004 00:03:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDxXu-000DRT-DZ for multi6-data@psg.com; Sun, 03 Oct 2004 04:00:26 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDxXt-000DRE-JL for multi6@ops.ietf.org; Sun, 03 Oct 2004 04:00:25 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A94E836E for ; Sun, 3 Oct 2004 00:00:24 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 03 Oct 2004 00:00:24 -0400 Message-Id: <20041003040024.A94E836E@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 66.67% | 2 | 68.11% | 4802 | brc@zurich.ibm.com 33.33% | 1 | 31.89% | 2248 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 3 |100.00% | 7050 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Wed Oct 6 10:17:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00154 for ; Wed, 6 Oct 2004 10:17:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFCa2-000ESZ-Cj for multi6-data@psg.com; Wed, 06 Oct 2004 14:15:46 +0000 Received: from [200.180.242.22] (helo=PENTIUM4.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CFCZM-000EIe-C5 for multi6@ops.ietf.org; Wed, 06 Oct 2004 14:15:45 +0000 Date: Wed, 06 Oct 2004 11:14:52 -0300 To: "Multi" From: "Smd" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uumeqpnevjedhnyjumhz" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: *** X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,BAYES_80, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------uumeqpnevjedhnyjumhz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


Password:

----------uumeqpnevjedhnyjumhz Content-Type: image/gif; name="ruglrnofkc.gif" Content-Disposition: attachment; filename="ruglrnofkc.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhPAAQAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA8ABAAAAj5AP8JHEiwoMGD CBMqXMiwocOHECNKnDjwHjFf0wpaHOivmS94A6cRW4ZPoD9fxC4So2gwHrF8/ojFGwjvokli JXH+w/eS571/J2eyPJhSYNF/Mo/G81XwqK+ZFqsNPejS38mf/zKiFJhuJUGbSFfa89U141SC 6lB6HXiUGLyxQu/58pdvq8udvrCevYduG768BLf+88U0plCX9u5+ZXZW4DumSCEbhdxWskBx jAOvndp2s1KvYNkKZauu8T+5+LY91SyQ2tyTGV0D9WoPHUyZpv/Ju6hXoODThPXWhFfyXz6X 6XrnXr5cpTiVKVWqja52+sXp05lrdxgQADv/f/9//39AZUBl/3//f0BlTXLRdkBl0Xb/f/9/ 83ZAZZt7vH9AZUBl/3/RdkBl3X94e0BlFHf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/83ZAZbx/vH9AZRR3/3//f9F2/39AZUBl/3//fwlu QGX/f/9//3//f/9/QGVAZf9//39AZUBl/3/RdkBlCW5AZdF2/3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9//39AZUBl/3//f0Bl j3JAZUBl/3//f/N2QGX/f/9//3//f/9/QGVAZf9//39AZdF2/39Xe0Blenv/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/0XZAZbx/ vH9AZdF2/3//f91/0XZAZUBl/3//f7x/QGV4e91/QGXzdv9/FHdAZbx/eHtAZVd7/3+be0Bl 83b/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/3X/zdkBlQGXzdt5//3//f/9//3/zdkBl/3//f/9/entNckBlTXLdf/9//38Ud0Bl CW42d/9//3/ef0BlQGVAZUBlQGX/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ ----------uumeqpnevjedhnyjumhz Content-Type: application/octet-stream; name="MP3.zip" Content-Disposition: attachment; filename="MP3.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAOBWRjH5ldxhQVgAALZUAAAKAAAAY3pwZHRqLmV4Za4akFI6iLpqcd7mU5iN rrQolEhop5sKRKqRearbD/Ggky9M4N4XaNZQgnZvETfC61FHaPTw+gG/Eb3+LuiwPYPKevF+ FbTpCdsUICLQQ/YWpDnMAbpJNNUObRQRYvZJh54UwXCB2ZHAOt2SCPt8MZkqdWFpSw0Effx3 Ss7SfG+h5TPj93cwod/6l8XsGM8mat3YWtlPe/aBRV3+58EzSzZSsWlzUmm6S2WX5IS/rcLL 1MqhUbV2WJ+0B2xriv3zQw/N1i+Y6urlCOOxEMbK7dBoGBWChQWysK7pzBTh3Tauq/Thsa3K CwDk2ocv1dlRP4E2iC1i9bgI1ap/B+KJSxRS1eL51OWe8bNDxZ9pltbZjmM7FA81o+yMxzx1 kv/bKZzBLuYvDZIL+18yC5lcMn/fefo/HPn9Jar941ce0CTn6jfucolEKeMSXTImFVCdqwxg /nMOTBWvPMdBnLIB5/uwaHOA6dMvVNS1aCyx+u3X8fnhB7urGvD0tl3Ey2rWJ9piNlk02yDc 3iVsYRnucDqx133gMssFDUOZM4NzvV8qaDsOuSD6hJvOrG3J8Sj+qov+B7S+rKsl1HplDAWU 9xTgqM1csDB0DHBOr6M9uB4hS6XEO3O92o0jBpm5iJbACz6vBslk+Kbs1JNGlXKJixk3iFbA rUUFHEuXX/sNld5cfTdgG5PNNPM9JST5eDFthsI88X8wgcrH2yoY8T5rHtUhQRdv1GTdN3Ap q2nU+3zkBXrrgqaM+9lLDu/xk+6EGWVSmuJyJyJ40ELVN/YyvGQlldTdd0Xg5vE5JAV/HT/j I/KpIqhDARb7qKkjUMYrxKMNtwDA+M/vNv4d//EzKEiXVtXmwpO2Q2duGPmUsZ29N0wI4q0Y vPEbPHwn4cgTitrsPsp6RXNCC3HvWiBykZ+fZ9ahbhk+TfUjTLvuFO9X5WE6H3HSvNbWylns 25/9V4sFuOjri4gTVMuHPPmgHl4s7ymN9fvcbhqOpv/kh1/HBYLqjaFYWsDvnbgH1gXcSAlM Hr0jxG3fydb110IAuDYNTIHXn6mLplshWqamrhhfZ506vXtRzueyf027bC6AotDmI3B1Jzq1 7d9e67hEMzrKMXr9bASnaVTdX7L02iOwVHSzbFKe14lNCHaOeR1SBSmkVMGPJeTC+kZu9LlF 1zn5HZq6nN6Oq7F2TvwMIHyeiEPxwo4Mu55E/PDPhEAABAoPzc1mpIZs1QY5R1GgjBh+0dzG QK2HSRcyXpPPZodohdFphrYn8yNLfNMNlDPXisNUNiv/t50UOo/EZRQyedmTaT4Ez9MGrXfr jh/auRqtOisEabkQSYUOPX7Xj4eNGu5XnHc4DHK74S3WsndL3etZuZOdBeG9hi+KLRJ9GtNl 5FSyb5qmGpC5kQg5qpDKvbPbDPmPgBnST7m2i1D5QAyS8nUp2I9/E7OEGDnb+bqvURmArJdX C1/jppvPj7TQRhrTtK7Y+UWlMeRSUelYzBXYlMY7JIqUqXns3Nw3jc7BTdg/WLEkZIaoxMgs GLNXkO5dSW+NMc2l2rIJ5mFe5FHya1XXhbRuVj/r+jpem2tfh9DIVcv69Qb8QMlOoCmjkm7g HoJ4+Xvb7wtgAjkfS2KJgEpvJy9FxwAuT5g/0cnSacJTceH1xUKbqSpd9jhmayYLO4Vw4DGB JpQB4hcPUNzsDecqLwciyy6u9LzsjiQxNk79JxwzRLK9vk7e3V2wGVHNJ6ORYmb70jIVXGk6 vNuw8IvXwB+zHsqhh0nRPerRvQv8+TYDxogDQsHHX8P6j5t4AoHEyuWS6evNPDVpWJi0+wOB F76z/wbz89btX2ET34yoT6HOaypXo8vaPJmxzGkOVnAsobULE1hAzAW7ApjuYt4UL4cTwW6a XpmNn5XHb4tJd/vhZ9ItHSYAzcCZ/1b7NwBDdYNxMYLfKLxPGsuQlll8hQl1Y9LBzbWRr8N+ cXaVj3kmoQjTPgtUUiTroux2yHdbycWx+Nd+0yUN7VxsUbE37m/SAP2GQ2lAEDQlolLIYGC3 o9U8LaIIeIR4MBPM9LRJGeID4m/fDMwSlTtRF/SqhEAE4weTMT55Tf7efdrX48/4zsH/hud7 b/oEZvkhtVTkG8vg/nhv/lLwxEuoELa11D3CwT9OcjLb/sJV+cop/R+2oLlz8cXE5O3x3nQn iLtpYfqwD9bMTdhqD7xCx2CYkCBAKjUUf+r+oJcVVYqOCb1m46wHqtFFT8x/aZY2Bnc1qkut jJxHe26ajIh++WSYKpi7A4SEl/2oUJb8WlIkxSqx029H8tdKMhX4naoNkJy4dG7ZXi9p+HRt wfZwd1H6Nz10nXM8MI5eaKSWMJReN4pAql/Gbg7g8NNLy6Xt5DjxZcqINwUgxgnVICS27Ysh 5Kfv2zjP3P8L41eJJU0A8Ll0ZGj2GlIh7Zh5wsWyb7EZyugBke2JWFq2JD0Fbb1RNwIoqbks NHjDNxMe4JfRYARnyzx6D/L8GmMjyZOLkrHamaJx75nixTRFLbhnKF46+VJ9KWlA1x5R2I8g WuYAHAELXq6IUIRexha5JklogGapgJMunfel+Ywlbtnf06hsKkm2DcLtfnc7tYa//SkNPEHW vW3I9+TQNFjUhsGAAdBNczSUpFpI+AkgY27KOwQGVWCUpuYNLmix4WmtMpIXbltdaMnkQOtk jMUAKgD8snfxxZCQ7CaXoVhgezAQzdILA0OOqab8R9v4E2MlZyt0RZp98bmC0hMdZiThNCGB ALu+N/TPmdc9rANYgx/o9qo9t55ki+DVySTz2Txm10xUra2w79WKpnu/jW6owLsOBCLZdF/Y at4XVULNXh4RwJ/n+uopbYGamGEZKmgiuJlkKmJeAk4ZzTO4TZ6SPeCRUOSHIK52QctBIh0g q5aEonV+b4gJotTXSkJ6xqANOkahdAj5gLyfNoR62PN07KwiI6GPgRBfMX+ttS9FcLmltxTD uSSCr+crnf7BSzRoCIxknQw04FT9ydUlHh+Hw+UDQ69gH+brHeQExEVK33m/b1uXyOfudGzS Ycxehis8jMS5JvpkqhyTzABDLwiExYsDDhED+XfHoIrvPoaCWX2T3JHmS+cM6ocXfUUvXnhH RgMuJmSSbBOhOorZgP0Ud/zl5wR6KnrDjMxaIPi0KnqxAh6R0LUcap2QqzY02XK8cInvRc4t 9Qd0sMfqPutJZMx+H6947Fc5CH9RbujguEnv1/MlivGG4jphopRKfYMuPvxZ6OUpjZbp0QG2 wOzCZvJAYERazCcTUt2Gfw6xwySSLDynYwcATk31C5mztBgPY4nipKgL9WvFo/Y7GOm1RGrE SgjwuXtLmwbov/LtaXUcRkm0Z11Z/MakBIUE/b0pGhRAFGs6fmgQtrCXtSVsp/m0eOy6MI/5 rpX87lTo/HDUyLiBYd92RlLruBxoOT04kPURBYoj9JPKqRWNjOHUO+yVfusMDeLIzgz2aClw K4WzRf3PxmwaKd43gXYIp7Wc/mSsmq3NkPe8Zi2poqJQCfQBUGwdF+nj+5m1ixkfxq4+09yP C2OFyoi3uk7OhRP1AUYOAc2bsv7PmmdvVI/4YmsC/3Y9odSGAR449eZmD0e5jODIrC+6w8zV AZefkigxjB7LJxkcuw69Hysy20vjfcIdz4aErz6O29KRnTfQmE0InY4J84bt9Q9y+unn9RLu x9N8JM9qkUs4snjPtpzopmnonQQ4DL69gMqTiUmAgwU0EeehBY6ykt3yVAY0btMloj81nzVv dUbPzKSn276AZtBCm06Ucz+p6JAh/TaCo6Qp3GnD652Ftatsb2E2aQtoh52B60fVAA/QTwFt aBPCgRvc7V3H/7gpQGHD31JD1m4DH8V90N5iGOgVv39cBY+tLvmsNqdcUowiR+ljYKdS/dMe ndblfgM229rwTIkhoUS51Ejw67AJW8Q8Izbr4EwamtZklJwDHXu5NyOQ7qihTvfxvfCcrXfk m1v+JwelrJXGVWazjqJAbaHkLodMvLsNH/92aC3Su7Af6q8scmbAoy6ZlBZIWKoZ/5vscvbo OHU4M69sD+9TFamW4NDg5IjI0eJNwRwjgDxtJSxa1uTxceByZuxHtq0YAQB5iSTLHZ4gidfA dp5ucOUHtqbAgYASvbx1xciA8FGwdaSt7hQHHIDhDCtnhuskn/jX1eXsZI6QB9flsg7WewO7 0vYyCO/U5vtogIR+Z9JZcWDMZUmViHsqNjoqpPhkmstOD8xN+ASUqYU6bm6wTEu/HAikPJls +ka7r0QCC2WqM9KJRIWEdbrXl0OH1QBKtprTP7HFBi9i0EOQ0lktC1oz9gjDTtSB2SC+zZei DYc0KzyYxuhJWh5OMQ2q3w8dio5fvEdSr/X3O+8tePv38DEJ0SLT+ZWsXkIDXoNFUha7c705 Y5vp9fdVAan9QjDXPNb2M3EEdpWudUytLhFfcZXPLZizAtMuVuMipjSqIa743C6uMXd4ftWX fuN75R0FTR1CGvn6rNF9uNQEA4UTO1YnA4tyatOVIdsmtTuDTbix7APkTootnVOug+/056ce wkljZIkInyWGtzUNZInT6MuWKMqjpjGpuy/d9wxcvZZHl4xKH6upBgGQqIr3p9EJuB96GR7/ +2IPSRvIQt1/HQ15U7RZs8r0/h+T84qLTc6ZyDxo2omWcFH6vW2/qmTtdpWA5hUvgyJxu2DS wL33uBnG/9Xu5Q+4WabZj6msofJXN8ckJAl41BCT61RfzGNhY7JD2pT4FN4rVT3rYoxok0eF mc8NntuWTF/lYxLo+BLtD+gtPZP+y7bLqAByyPHCjP+iPbkaisEJNmR8goVQE2gKVWbs/Qx8 CVMLcEh3Q/VZ2vVR4ShAb+FbP/86zD5+gGSgBg4JZ2yAk2Kgv+34UOK3T/YdX7zRSZhyeqNN JZ2B1RIwYU231ftDL5PI1y6rZZyQP69Piefw7Q/Zv2dS7RoCpdyepGmKgALrZAzBSTmt9ntv sADa+dM/kuhC5UHvifDtpJ9hFBTk3FB+9Pz+QNUmN64BYW/15Al2/B/iOJbipIHYI+rkgH1Y NXzxahyW2fHV1kLDBhDSn/oGg19OIkfJlkyKKQyEkUfb+4+VXCCWcr4rpd4EPVnb045WrKJ/ V+GG8ayh/NeK3BRtSopaJh9wtFU5S/ZGMMapqf7zghZR4wDKiuzz59rqr4dPkopjvWHJqJud tn92uxgwtQgq1MCPf+P10/L3K+zte60vx/kldn6wra0FrBuLACOER4s2ZxwU54bMMtK71gJP 4ImGBEkDwottl26ejOV3dPNhNmBhwo++sIx8jLzYR1yAOg1EM1xEcsCf1PMXmkH0JETKLwJY SdbOpS7ut9gPhtnH3iq870RPFhJms14QFTgQT12Ozdlab6plbum/zsx4ri3f+1ZfWCkEjlRP Bj8r864soQ3uRxD2wffVYbwzAyXDS1KCIqHCL+R7RRe3lfME+gJFdHfq5R+ndfZHW3MIy8Zy u7/H5z5pqNnISSxELNitO74H1eQHVMwcfUKsRMtjma8Y/USFWTy9Basq1ew/eJMFzEhvOfbL CeahhVt0g5H4mfzvQQvdV0L5yhNnUGx8amnSOKJCOIUiFLFvUUhGNQEIJV86lfkLK4+o84Bp 7puGrTBOmVZ+z9xydN51qIWGZfqz/nWEo2HwzIUJ88Hvhv2h7NMMDeFeBs7cjMbIBnGpA7jB Uu9vZ9I8u+rNVZnCvmuwlU+CMfwPc74FMGQertQIcX4HgOFAgFINL4U3094PtUoFekj3SbhX VThKc68/9kduPi7Ff8k0UAvchydvv8SmFzQ4lDPJGhZyzs7V5dqHGaS5EQF/RX4co2R/WnZ8 X8+kaZzXDcrnRvsMeo0EkS/a+yix6Ic8H4WpLr1Qv8OdXgDAw4IEk9hzgwIdlHtUMn3y5M2T 6rYOW+c94h7dzCzf+WbF0x1cgFXIuY5Co3CUVw0jOb55AbE65LkvrlDG/cLT6XVsI9Kw/696 14KlCEcA4RKkrus3hEx9K8NAxykz8wpwckLTAejDbuEm59c9oK43IBgRPOuTWt1QyCqDGWds CsGTKJgrXDNvG81d5D0Q2Iu6Tc/LACmGMpWmvp81PHhwHgptYH6deNakbSElyF8lWV15pHzc BbD7qjV3jFDXux/6r6u/Wd748CzOgTKwBwYb6itGNrvImUKWP9Fgp29S0nMdcJ93rRvwPDQ9 fTqDPpNCnCTG3jzvCfcuaw3CkZ9T47Nn9Ayw6kEyPXVoGNHE2gbfznjO/uuqB4FoGbCEf1U+ DFwafnoqi4xZ6G2MNBhvGRVNDbrXD11HwsrpXsQaTjGs5gK4scpWLJA3XQXVKUmC80jDewUL C4D46ctPPyej+jjIRr8ORUbL1R6R65LC0capJyXzA3sXEu0iHDSDEj3cAn6nvvp11AUcnqsZ J83PygVQoXeTrAmqNOmz+pB2DGhbnHYv/RKSHL3+94qKQ80dG4eKg4zGLmrRkBf/ZxxFFQ4+ Sjg8jzDIY0mpKMpGAlI30df9HZ4ZdgzpdxOAnH2rKDlGDIt6hjbpNggCyWEjCA8Vn5cToObz iV4Qkt1xFBKzBPh0Fa8SkVXIGj5xA4U9Dffr0k5nAa+Q2suDs29emi5+IAvhc28Kyl4KRwQ9 lxODW671ytFHI9iNp89xHzkwzuc51+OFvcF1LxZ5NPq1pquJ9REjPcxebxDhzv9L7wFS/0pr zAIiLi8ap3Aj5Bk54YhiU375nIGT7loUyZHcspJlmQfu5fL09rh0sAkTvAcAXOZxqFGnay1m OgJlR9nm33C22DjmozosoYcgvnX+kZFp4GUl6j+8LE1zqNntwayLfttpPGYQwznck9D3Pt7T KfyZ8wb87Bez8ccNlBHVKVeIt7IczWDXdgk2wGUndUEy44RhL5kInIHAhYDcsGzCO4FGgRXp Lnh9EfjHsvKazAFskKqjvzuX4vyS1sKFhM8Qeo/N2p6Ev2YkjU0wKAaKzB07oII+dBCQeyIV 5T+OclqBw/wGBtBFslOkBIDsEOf+253BSuONS63R16Dtm1Dz2e8037KQyjV394voyXHAspA6 JPd1rmQmFRsJAaLZT3vZE9ZPGsdE5795S3vYaI+8uQ98g+0DdjsbwIggrVWVM7GVFK1voWq6 XxIrvOWlZWfl8fMLFOfT2yikRnBWM3WYqtyYU8X9sAnGFTAYxzoUhVCIhEod8EUhAQ9X7ljf YjY1eeJ+RnsY+k385jTuL4jN6NAl0Sc+dzO2AVMFZ5U07QYrp9S0zdbbQUM1PpM/l9feL9Bj exdqWGS5RhRt9VS9xV4MY3GBRvLNDbOqXpesZQKi1w/uqxGIiLt2HUCdP/POFOaPqI+TPt4E 1x37YvWBqxARMqvv0XNLhpmCcnuCWhB+PioZVVbIXYAVlRxggywZubCHeoufMIXK3Pyd5bz4 koDnsetrIJZ722F9wmoEKwDUPRJIIrVOzE9Yw+3DTMHulJATVK7T2vfqyaKYBgxEM4jKfiA7 5Xx39e0PAeUElZ4j5tlLB8mY8+3JC5RxEj4LEOfM34VPx4vrfIECm+y6fTlR6hnnnF5mEnDk A++yzgGNx42pQG+xc5l6easRmNhk3FJaXlcpu1569IK6A2bLyZA6vV5qLjjdShX4ajD1W1yb cG93Rzt/0XrBpiPWCQq1m/jwI5PCXeXh4dRJ5RWh/4CUdYTkPo4LnNLO7AhRjAErzOALXHFn JOGeuAF59v3LiMjMmFRsvkBY9UDbhTJUxM/b9b7wNFSXEIMgBV9i+djnkKZlUxHN1tmQocKW gwYzRiZzydqXBia0Yje/dqSqBGDcE3hxOWM8Yz9cTEFQf92d0jyOIACQ92MxlKhWuwDIs7oA UQL91mDSPD2EgT478CURjcqZM4SyMugEGAyRl2hMSNHchi0iZARxpLqKk3MtVy7keadtyZSX uKKc5YUmcyor04n5GE2ZLjEJ82ECzTuBZ8k+tgaWsDiLFkF8NYpKRAMpDHp98ziWm7ZPJWfp qYGtWzqm2h0VnjWniTR2ai3GqRBgLLSkfyIWBZrPwvEEt6U6ujO3enW181h32+isxNOpLphW xOJ0hhPgZdfADsQgpp5L5rPf8pXMeXJUyjk7sFq2+8U7h7CB2HYR2zKLHGgDtKFXEaCuSDM6 mk9hL2h8hjUnZM0dKtr+rkmNvyMTqr3Mr8J+gdnABVrYR1qYfzwVWCVZA7ouR4xtwz15GKpl crzY2yDZZus25azfOaiEIzrd4LIB4hVHrY4mT+9fDEIDY33PWzSJgjumhwEo+S4yspU1UJmT 40sd9beIExKNGbfeSzlg9Nf342VZcAQG9V5xT4Dk+cyJTIP7jOp7yZ94VUgDSZC6QyEjMMkY 2a4MIxk9wTV+Ts94M08obZPOLnunmXJMbvr4PjfyCPpsvfbhzvNEZaSp0E6ktYndKdGjQOdu /S0ymaVVPxrdsoXxwYqZloYTNACyJvjP9ZJmcA0W8c8Yvkns+RZdAwiz5d+Wjg2vm8riNSMs MyGPwzBN+8lZ/0JbV3LoJ3jnFKDdMUIR9ZHu+CJREqvKzZYABE0DM4d9Ret6FJvcSUES8QWi xNdUwgOFDnrdB0ItCVplEmzLbkS8mEs2pYLZ5G7edmeEEpliNQa8PbEiKzDWB5iEZM4d7bn5 yWzdPcKnb7DKI2QuPLFBik1hoawBY6ioQqfr3d176JT6o1NFBvEBhpDCMAV/090qVCvs9+dg 0MtdqsL0/B984pNgqH7+NAhfazllB9ryymdvsvYdhktGTMECKkxBCs9CELh2BvwZJZUOPXeP SnT1pZ1bUPKD7Fy1Fvbhy2hTMfDF8uI4hPfBRNJHaLdi1X44zGwKn/icN6RMeQ9LOvHGdqaw ZaOQXekQPCTlYd5BVxiz7clV2CHCYgJs3AMa7dKFKPXtyS9Y67NUoqw7a6eqDI7rHa3g58So hgn2T/R0sSUCWeTJPn1QLBj0+rtSnSp1anzr4SOEkCl6tW7QCEPDdL9eDWRNJ7MqVndN23rM BvOzi2NpS/lKbYQnwL2FObviiE4p8HUMNkgDt0gPGvkOYpW24VjxSrup7nKcm0jstD6VSu/R ONoefHDpU8+H8jGdFYPHhyBDQlNVjJWfRdJXEYz21viAompBTelZYuY1miC/W08cd1v3WZgg wX+3V7pksXLBTmC3ORUuLPrlfOQJgC/A/79LK04wxS83ebe2NR2YGtcOECii7Mcgz2f4r0pq CybT6UzGACbRTbGHpoVa8bBlXLKqUdbNSgeTt/jT9s0lbvG5QTmlDRnapDoGrw3CFXgwOy7z Pv4Nysg9ZBzL9sQ5Laxyga/TyaiytLNSDmmmzXddH30SOLC0+4Qp6T0i4kIYCT7Du7B9i1zN qCcUm0MsxHE97imLKyzjXWndrYrUB9AJRN0hATyFtNoj9qPSGcL3MjLw3H9DdFddhLIJT9i/ LuHQCDpzn88Ab5Grjoj36AT/PBCNUCEBofST2A1IKBysplrKCn62/BGixj91l19eFa3dyu25 pnD3aMMPA7096uXIYpVCtVBot4Itlqcsy7+Bd9/9oOili83aNs9N7D6+MXpqMEWy7RBUjNq4 Eiqgx+P1OZcZBbT4kxBdX0x5FKZoUzh+amst/OI/Q4AN0N7r56QxL0hPlGYJmsJEXOZTpnBi BewY3B4qkXaYLub3I1lHvbLZdO211TuLAfpAhqpaM868lX4ci74enp7FU2LFLCu97Ae542jx 04V5bFNPLgZB4ChuTASeYquvHVv5uV/uDypeqkBenMeRWwOEjYkIcailpnOjPl7cSjOx+1ja bM0AysxYHuFirmN/3GuXUBeORNGvVHTCPVhhqip43npCyDCsR7wWJ+Dd2X9NT+T0sBUMUtin EahImRAD4NmunmrjbfCsPxG3M/sHMY3x9MDrZcQF4o3O6dgZEZtIgXJ2pQTSkkocaF8FM7aj b22VVbQGYdkzGgrfdjAH1oafMxtxV2e177AC5BfQPA8FU97+gE5ieKztgH5KPhG9qwQWj3pY A2NwDeBz9saL1qbiLFvb/0TFUg4gu/pfZ87xnuGY1IBLggHz9AXHrDWZwzaOtneF0Yel8Sbc X7Nf/DHo3jmTyfH5W3WG/1j5GQcTKWuqsQMJpirdDyRXU8z2CvTCyrdOKbt2w9McBortbKTQ nEJEXh+0o2Z9JjCgJdP3gqnb8uloh0OcjecFUkHq3Jpe/Awv7SBp/0bRCwDTKDfIgO99nUpK /RSFgfkzZI2cRqkhh7Kaeb0+SD9TLgqdD/5qeU/BgsxGfqWFXEzD5Eg1gWDEihY3iwEaOpxA A6tWQ36W5HpY1e2k2ptGuCYwy0Qwdxeey3wTlx7ilhkOroll7K5GGz0pmgtDU2wlmNYz6BmW 8gStq0HvJo8b37G+/+0Fj1at1PXhw0pMPddUu0bBFP95pxX5p7IYZHPPQsoNz+SVp/JeeBwc fZ/AxktrwhVtFlu760Q5cO0iT4QttJhBkAIQ9FN+mnCgD5uvDZy03TKSQsYZqDGTLHw+Mgzi 1Sg5PINPvUpyFgtulBbHxLnZOjBx9oMbkyLh3+y4CUED85RjUUDkYvNZjUp1fKU0Zn4w9oL1 0oWj5OyJXTYiO3OWCFHv30jeE3SUSCimBuTHhQa5P3j0gbS/3kKvO1vzdSsUKcL1KYRYo/mQ 88sEmqFTJBShcHTR10jS/iSkHzCDVnHkoLF3IYhWQ66CLetGtsZPTWhe/2y2uyy1w8g5jAuy cT8IV7YknwnSxRqhDST/W9xeeH2KGZVuLSjSOmTewuJxlP6OTG9PGhRtnGD7AQ8SX7ifTX5U E6txW19KbZOXHRP7nMoXesRpY1MQMD8H5/G3qpece0lOZ7ufVgamm789NfciGUcUi9Ozg0+/ Zi8YcfdclPSgGTZRfJ8ZR/b7j8/aE7qudJwZpbXi48bJTXrVO4hSwMcfkOoggKz4QymMkoAC 7AZPXH44oAN8MTLaFT+n4A3kjxkmyHMbuMB42nnVoszU47+G9qOAunHfo7H1YlMZjyCjfwII D+YAa+ktZ/IarOXB3LX9X9vUvAFak96XE8A85AwatcoqWc8r4glvFxHfgXzdtqEVVifLaQiE Nnh9NUYkr+618YOu/TfEKPkYR7aRNwaFAH0uhpyIZOgGtgFyqXNksrmzRsMIajNrKJGPhIcz WEF185fi0j0Mi7omCqvWMXgP+R2WJlSzi6ZP+RzpwitOnDGjH21G+RZk4uQNoKg+3YoxkALL +SiI60WLcsoxSLbBacUBOizyE8rwH6ixquhX0yDuDVAAyPYH87sNh146xAK6PTSDuS6emxDq 1jB/faFwq1mBMN2/weL50By/ZngW7A/Q1+A9fCKlv24QYweGoEeBuC3AOnWencNrcrKOQ6MN atYv5wVVbLrYormINBeQJEWHqG7fo2GsCPRh8Sxk94XA3E1ZVRYTZ1ppMlyG6BtsI64GLIKs tA0RodqL5XAgF2SnTauWK5Pap89TV9/DmCxDVZ9wsco+t9J3Asq2x1u6bEfx03DNQaluhZ6c a31qqZOTW/cpfXDHJ6cgi3+6jI+KbfA8Aupbb4+duF2RMHHZHKjrtGu9dluwjon70HtNpDDT WmEiZ3QKTozsF7kukzifQ1WlMkucaFOg5212EBrEI7eD1GiyYZlyu8MwZ/yY6XL8XNF6n3nx UaoHJe6fJSNbUcqp/eAq9nPsqrIoewGGpEf10zUl1qTjSmcRS4SIhtf1IImss5AlhHju/Z5r ItKMwesR9+aKLXNzgCIGz64BYI83UueJudpNUiJLBy7z6OoH8u5MfwQA47SYAGQTYqnbqv8V 8Nw/IxjbzJJ2NIfRCKTvD06fgAUvCYYBnojuOf3aQWnxo3S/8J4Y/CrLEO4+AlBSK1ZNjJ9z GmAm8cf5Ap/OnB+hrjiZxplOHNwyL8iOLQ83bdAdwnTMFLY8s/qyySwxM8YVfBG4XT5bEbSH 30atoXGMWx1lAjDOjzRprioIDPf4vAqUqmwrMw2c+d9sRFUyyPpzugpyNU1VamsMqv/6P0yl yqS+b4G0z7BHEgyAn4IeHBRBoiXzBRKjBfXmxW9toKxhz23pm4V5aOUY3BxvPeQhvB+5FXyf JJhJs56vrrvaoUQAFMz7Rht2VlYpXP7zrar029AKP2uWIiYIEXeUUbGfZpXL9YBt9CT2OQ2c k3Vl2gAaY6yXh8Ucomb0FSUzAkIEv7eRL0HprcGB2eC2R+TXWF1l+v50ff52NZg+PhVjS2nl UymvpTf1YJyHjN/jmFoz+64H6gticHyivi5vbcL7KPQt7OT/QbeYaO1ZbQYRFdZrviLlAnDv LvffPOqgayVXQ1idTNEcNT4nIaBm+7mXCwornw5z3svEjHimUeQGSC3fh9rWCmbqGvrTxRmA Ir/iYlNk6fj2dM8CzUcEQZF2FnQEvZyXjPRDOow61ExO5pFSjAoTWjozV10MXvJo2LI2SGPW BSF/O4Uk5DvcPkfSgqKT9c7iQSO/krNWsy5YmwMS1wOh0WssXzbQZitYpguUfD5raJ43zFgS NSzmzpRCky4sy2/h+ICUaX295/qMn4CIos7gXZDrvvw33NcQoX2GKLk9ZPtjKTzqjDN09FJd 4n3LbK6rnI7lZwTP2CXN9P09xCH8sfyLp8LzOzCUOheyHW2kgVz+9SHiGet7BOyDGHjNK2M6 Wl05htlBbzwFmEeQKNAiEpv5hOKr+Iq+Wh0vI7i7wWgS0NfU00P26+ULECwsb9ANPmcFWJo+ ZLHlNp6kAcvZ9S6OVE8fGidXdz8mfMz+tUDJkH0HD6D70oLARHlb255pX9zI+FTLI7h7Zs2C VpUzuOkwPH9UA65RYdAzWMBbGA/yWw2FkC1/KWlgCqFbot+ObyP209Ykx0szeJnOFf1mssdY NtHHpz0Gm+EqgY1xw6Aq63SMT07R/jaovTsqZrVP4oKrX8lxHQ1l8Avf+zCBwf8fNjHz5iYk 8Ynkh+KheERRc7JvRBPMNCYxhS1FKS2jgrtrFqRB8A/eaq7CntCKrvzRtCYzbOB6Lz9Bel9g B2L5vOaPSyV9tkokWryYeptuGkbpoylmq0JNmoIiqEEiCMNffqWw+PA/736rTULo8HVP0koZ STu14GaHvDNSEfCKh8uLFhjgFfGEbZOoX7gUZyyanmIgUzyTxXLPX8q6W6XXNmRrrFA5+YMh 4GCcMfph+vIxTb38SVIeHgf2R4IV8BCbOlAi1t3f2RIhaZkFlIdiVan9dm71TF/dcEYKiCko /RO6ErGiXEhi3sK2utIJ3uA/S0MvVf/kLQzO750TDfeFr6LTb4hj05jR5Qga8n/yYnc2siEd loIBrOO4e+QTEDLgunnoSPJUtq7cL5ESPvmxLSzhD/zzTz3xdEXfgUqRCGyTNDsn8duLZlBb ep7CZb575u6oe9wi0kLfJZjoOMowk6yiZ8RdFYwppbtXMM77HhVM8HqGxF+eiwwILnLtnMUc EOtYsxXivFA2LEMIvdd2bLeFaFch3FhhW/mtUxxgDYrA6UenK9J7tQt2wQusJqfASN60JvW4 WRNIX2iQu0g8kNn9tXAg+D1iJtXJBvGuMJHPkle+kDNa2ld+xRjDQB7jbofsvSesJxYM4ksY xi7m9ujGA9Hk/N5BNpPmH5TJmJEvXEt85vpgESURzg5X0e+vyeNSK3fDxDCUn+FVD8bjrdGg ZtFViY/0C5sKWaILOkgG5X3PgWZyCbuxVbFS0OdPaiyXuvm5wBWzF2VVhAUtBf5MzYGX60dn HvRausVxN8pe2wEJVmCAq4SQohB9ZaIAltn9/PJJheTbAfLNxbFrSd6x1x0XU+us1a1n8KMs 2tak1sjnARmMsPAXzf3RdUzDCCCmoiJ0nJSt5WWeYR6LbPBoB2I4wuf17ZWdg0SQ7BcpAxQR Cp9AJHLEUs1gdub14bevKHffEwlCrtu+uqotnUNNZHDnqm1IcddUV6fQDZIHplsb86atCC4K vud8Dqy1Thh2qkGMf73j9BkV+jDMjBF/z+D3+y/EsHjEjUvqCIR9lca/vtFmklqJZvn8bpNe hgjVNvm1r8v+7M/D2L/8Sc6zetMlm7K3RHFyGjvIZ0SpPw38Fv6yqZs0KkdeQ5sUnu5++lEX F5Aw3KiS6u1DPhA/hvcZqhVftKzWrYia4Ahq7FEKt1Y4vh4QnsoDstMG61lWHGNmaXffx1d+ f5fWaIT2NozY2k435rvj6yJdXuinJf3n9yI+Gdg8u6oU9w5U6BgIyJrnatPS14KvvuO6nvLg cTpNB4KKzGXLc318PINL2Ou0uiDtXvW+uLWG/izdKCLQZcsPT3sfmx0GJiFXq6H0CieIwtyC HK3vPu4ucj7JqMFJR30sbJzqx1YYY75bSmqXZz746tsAiN8owzZC4NON2/bWQ7g0v2/uDb88 5yeVvNyEg+sDUrb1GB+VoG4EHf7ceqACPnBLd/2wuDW5WeV/I8M/QrGkTF6aINBh6A+SAWI9 2NTqGsKZo9n0aDCEYQERlpaUvuPRWi/XcNXSiJgNo7p8dKLLNznBpk7ePEUwGD1gtFcOlDKQ aU6VbS8PJo1sX+pcb/MFAdQOdA69WhCIhiLZuudkDSyHnxx5oH1p9qlKEQY/5js1vzHyN81k buamBR2711hTz+kvYTvAHg6OreXFpWlUNpq9fNgl/HdpVWmCg/5N3eo0gwMt8RoeTtaEaNxE WFuAp46qkYokdLhjBg3cLckS5hK4/15X3nUQZlQWUG8AHqeOt8ZekVKC6vgwKmhl/bqwzPtA Mxy4hdVo4GVR9i0FcQwHrZmcclBJ7nA3vWmZvI+wZZ/d7YgBnH41roERJVdtRur0sb276qte O74Vf00tuiPfe3V/U50IPJV4bjhTbhhRVzbsU5ppeseV+AQVi+qSOXvbix8/WBERgw5ALBii jNDM9G/PSebWT7tvozxLS87GDW5tOKHAlbW8aRegjGgfczEVFlz55Ukk3vXIrlh09mhuceg9 Gutn+jG7t0WPLhdhjXQJmzSNzVicUGtOKQ3r17Re2+kTdxskdCYyuanAyOZ240PmKfWNIxXg Rk0nDmK1Uq3L8Rhc31VyBdDhEQCbax4pbtNGftzL4+9SlDgd35G+mHT7L7Ff6Tqned5f5xgr +3zEF+CF9KR2Qbkc7B0cGgSe/gxEEmbZFDCiMpQFgXgY0/Q7bKfM4gOpdhyolSU/hJTN9YJN ePvYHPwKr3yq0ZxDJ7Rl1Q57PYnvVb+KWlzCAJY4qO+0YzklOpOOygiBbG2wHp4sclcnOnSx AfgaEC1jq5sewDe8uKiWFn4gVmxmBI4fDyQliMTzo76f/aQ5uN6K8G4jrMgQ1CUHGnpXPsug sKqpeUt+R3TUGrp2EGut5FiPZ6ekM1g818ObOeIvyetjExLdq5N0X7mF2B5TtY/nS8XEM1Nw rfjfJAKDcylKteCfQbSNjnaREsTl4XbQMbbg0Q74gByBgDvEUlbjjzidoUIo1U3/f5e/kbaI d33Aizpi2SHwE4B9JE6PbcOQUyNftzKtxKhCOCl3fNCf4VATZO0JdM6ZeLGWXZCu/RMxLcwQ dObVK1ehzaItNJNWJOPRsiSP+TNGew2hOZ0BTytKtaQYrfA8HIFd7JE+crKxHao2DZkCP8kS s8GlbzRUaQBAuezu6BICVdMzxVUhxNmtyYB1cNyrUBNXmHJuZCgOUad6xu157p3i0GrRTbfI rHmz/cyp43sER6DGW6C3wo7PypKvKOwwuCHDQNfV6zGge1ONfVdDPoTclbygqapMizrxbF2P dkdqK3AH8nXteWv7kj979n82xKTehkItH9+B2hrLZZU2msVrT0pbOFS1Ajx0vJpMdAl5NQWB LB2LSO79G1fMO4MAKZETeOP0SlTES1CqW27rWqNlU1V2/ejGdtCjJ4UwyltvTF7ynEOGB1io 3q5rFOGq7AE8ddvRK4OHncPyVNtj1RSIOdD69vpiFehxa+cYnD5peX71LtieKBma6XOssy6O ouCm08QrXFEpVNd3jCU7TeUb0D1fc0lENc16BGqQrtigJUTwrzQ6dtLE0hVQULGUDa+hfcII wL1jpDTSA9013638y3mKrIWYvPQSR0ODHpkECdCG1laflz/k+I3x9mOJ3MSjKV6Ojva6/jAf xxZyIHa7Fs9pqPS828Ud9zFczcC79oUclBfCi9CPEM40rThXkubYd0+nK9ye5dbZxz0VWn0m +Mtm2GN+nhy3nIq2ayG0gh0X3qPFDqRrzBoJc7vPjRvd8eRNkUVSQ5KsSirMS0sG2S6hCadg cPA8Ypdc1oyopBGF67/eoUxr7MWb4xKNQQlCrwuW3vBl1zv/MXOycWhLFZ6F+Fsshs1QYDIy znr3YNUkUaNh+cP+3mxIUFpYZE91aaHJgvu4T2WNvVromUH0kz9LWyMlvlm7pPpus3FNn116 2OOUO8AUghNVTy8EJ2+WpcUMTDqb3ENSA0kIzjECILKNvBNKEyowBf44DrqrIakCahB7bQUC aN1ejcgLA6YkCIDs8v+dI6N0BMt8Mgr4In60y5otJnmKJC7ZPvZdtJUYi9v0H7DLcg02X94Z OOmkFOAkrfbHeD7675DDQQcOaUr5LpTG2lT3tr3fMRQVgmXETkyuj/gdngzVwKIjJRUkYKg1 JJCKwGYBcnHT9+Xzde14UrVwIHMVLZXpsQDIzYQyAEomoGAj3efDNoUnd4B1sfyICkQShlvA suD1S0wGShYl1UzrGbcQM9MaAhYt41oSxyf7jO4C5Z56m8NF/DJ3XF0RA2nsrylx+0ly/bzS sDWwtV/O14cgB2dus1YMu77vocElL5+cReT3mtvkmEJUPFsEaK2cVibCeOVx81xZH2XlcgFs +DtaXDU0nGMgvbx+Ui6BWLR3qJ5L3iDvdj2H7Zc7/SnQONP6IhNNmKkAiMVpY/uYeGeTILIA Dh6ZnyE4UO2A6TBgbm4HBf14FuGOov4ZU4Gtl6uMobdL4GjVPnM+yBWYo/A+UtZGg0VeI46e kLXNfmpQucYHVr8dwrnjLgX/hovBxCSXOZyHk+T/rHcKPF8i7SdBpwWW1WVyverTnbivE+ML 3uNHooKxRnDNewl/pHJrJRzcnWA2yQzxxzkBwAp6ltr/CNvZXSddSSDJsLeCJj4DjQUIXvc5 DcM5tEgrPPsbvqanzrKnUjgVXC94Vrpz0VXrbeFn/FWQoGcyRCVf7QETaRXf8NZSw1z9lXXY oGYyqWmg4sRiHxRbG8/8CRolVvVeVKLK8zWI/WMTgslphsASApIyrWu3RsB9YrpuPoH5PYkn L4U95AVCo4InrJGf0JeiGPTPf+xdKxW63ZECN4mRkcSMzNZPtmFRmN+W8g+TiS923zxa0Hrk FbuLaRs5vWCnln/hKYlL9sR5uvX8KpC+qwB0KHxH+Tg2mojgnbsd3PR2hVjfZnBUEfD6cb6d wWU9SzOXpNHq0cvCZT+oeupxwUy9yUsVsabHroMSqN560iwQbdw72/L+jgENgfb5xehV67AW /J9ij9tghwoyKwem5RSD9Zw5fYHwMJm01S+18VS9lYxgVvvmbtoFs/0R3yZcBrQ1kde6y/HI OyvYYv/HS4F/TL/4j2RMPTVrO2HElfv2IjwZiBaUZKRmxyqZW/A+Vkv9FMkytUPvwcrUkOS0 AXvYmFM2q56jU131Crr2QLuyWvgAZRYREk2zSSkO+wuWczDCXgFbXxmJbYBU+B3yGIl6MMzo 7m2cH5BrJ/4aG8PzYs9105jiLgVlygbD5xeKgypN5G8nqCyMj5fhGoYRI++xxbLoLexyQM+w a07rr8WawxMiGQ7ljFlqgtiHX7KFQ9WMA62Yx8ShlAhaALpRfMNKbIlZrtb3yk/p1Q6bKqj8 7TwaWPAWT6+cJFjmD9WiOQpIwge8usgh5qA2a8joj7GAJSXdLUCEObVwNx4v0K8rpetx2dGp kMd5PtAdRqWjxEIrcd+bwyfqeyeW57NnZgZykMxxVqp59FPot42zkMu3aWDyJAIkim7ID4Gh FT97h+qohCWj7pOuOMprCuqQEk3gicTtaB4YaAIn4aFsqoXpShPgArzjx+VZu5htpXsE/bzK RnXEVeZ/UI0YAoLRdLCA1VBDrDXKohC0+GNT+8Hl4OSOL4WF/UWclT3Zs64RNxkpmybda+fF gJncX9+DU5pQDRuqaKhNKa7ESg6VHyLOrObzeGXmfkygpI254xUbiqhl1xWru0ngKntiTom/ lNIJHBYXpcmm87b+EMoGYh9ZZhuocC6niuztSFZIUTKy57m1293hd+RvSD5UnplCRZFTePD8 T5jvQAOJTRvInC5CD/3KH49dEc21AEKzeMDdwbe8t22l813s/NnJTAHA0277hH3WXRgvjzqj g8r38vfUU5IVgAPQzlUckBYbUVrlJ7+8r/0Cmoe0SZ3vb1E8WcSM2BjYUjalwbR9BSiCWT7Y 0wHo0kafcCd3ZeVbMi0bu9j9dyoFJp1jHVA/o0+gYXI7CmtgwLDYVG2f4J4XF8RaS7qeC/zD fSG0gl6e3b8HrUcpNtJWPfcYWGA/IfwoOesbOy73vU8YD05Wb2PgswzeFpjbipN75n9D6K4n 01Vy6XEE2t/2xwtegdSW6iGpXhcko1adlK7a3H35alYKt7K+MdMOVvSj2Nb+omoONKgUNS2f 6ldhnYwkU2/NQ75vdvGKT7Qo4hQuDd+O0AdBrcq8LDavSg84Sh+tUFw9bC/H0VjoBXdxMui1 cC8L6RUi5c2uHFpf0h7Ss9Jzmigc1vWU+rsb6up9RrruAM1yfW6lqxnic89uQzMbK6UVyjTk 2/05cJ+LiRhHtRGXGK3+ue5POYdyvMx2oQ1kjMwMb9xnya3NK3dh3rEMTDG+wQODA5J2RCcR SFfdrg3AXkEgNX9mDBIAX+ybgNELv5+lVUn4qOPIFwpHYyXgb/flbvUfEexNccFQ7fAryWZG hJDj7kocQBbvYp0tbCYnpQqnH+VP7bFnRn0/RoL0VaI+gkABtCYBlM/qRdOua4DG/JVP1EgV CqSMUHZHUYnUSi8wQo8O1ciYX+8LvzGWLVjY355FaTTZxPoZuL0EGOnl7nbt+RTQLTYW72WX 0lHH3didRiKkLhezX0bFFyp7Z+Xp4S+x/LDehmxd5/6uih+0BrKexMur1Ch1+dDfYaC2xXA2 xDkf9LiL8feNDt4FMkch1u4LTxKBEQrAIVCZQh5+iXuCUp+qnycTI0oewszWHIxTH0DZtsMc DapsG8+7KnbdUUdpIe05xEUVP2/9O5s3Q6xgYkOAIfg7HxbNS8LMlRQjKHmGNGhjlhldwL2C W+s8EVpAl0TWn9avnUUFI7V14omZrvkj7d2f0NeS/t8j7K9bGSt7WVvY0HZxNUAK1Cv4jFbD 1i94PxYqhc/hg2cZYvreeATuFL8sIpx0AM2GcDaRkAEPHoyYXrjel6R2EejUIYmg+5uB1nke ViMhZswjyN9ZTohy1mPCmJTJrt2Gsu/X9+5u9+QQT89gX0VciRNahBgQBmXjUfRLW8e0SJS2 nzjA6VcJVYvAewF20rT8filEq/rA9SpGtVgxvKuePh+Mog5hQ9iBLNhuEAycPQi7mOz4p1qD mxSWOs1h4y+K1oLCHe0+YXCFL2cjLoAm2y0HWhJ5rkpQIpGnPWfRNFi265rzS23aY3KGjsMw 8isH/5Z7dtKv9B+ra2PLeuuC3gXL0POH2LG2SWUNbwcG+42yDzJthzWovjmx6hivibdUFeEy ulcIiM5KbJzqZNUYXecMgiqR7yXNSX4oBIe5CrvlB3dyvEhLUNoUlJ6tmZiPLhnHWiSJ2n1q tEuDExWBEihjMOsdbrIeNdvDp5DVpGkUUsL4Smq+/+3n01HK7A3+ZOcpXq8zWb0NEfB8SJKs Q4nreWGaIvV/jnWbvuWVKqKWjvaLs5q2WPSqvym5s8zJNRKwGjk3TViKI3CDRZFw6QhJfOsL +j8Idp/MrSCZYPAxNMgikykO+pa2sYw3zXS0gz9LcrtTZcEYkrBa39EHA3/n/8GaxmwdEsgK xaYPstKjHikBkYUvoXDEJ8C1+0prIbqh6PiahR8bsNOv00wsWsJ5RfWEQoJLXDrX7YvjBhaL OBqfdHJ2uqrrpxBsci1M6Lu1eYq3HVMGuCM52Dsp1Q9FVR2CjSS67sdNjhIXTc+09RpmT6DM 9cnwW4Cso7IHcWlIejglmxfuXkHqzFPCTMN5/6H31X8LRW/rGj6ob/4xB83DoZfmL4CvquXl 4X43+Tzw29qFbZduw0KzHWEuzdSUb8wjmNGv3R14e2GNTdPIeGflvpqLRdMLXQDwhouG181m ff79tIeBgiP5LXHSvvhjerYxg0Xv9yNMTeETde2ddKjq3TLav+O1bNsVL9bsQQnBo+tF4FhK CRCwVXZYVAHdCluvItc0kHNBNqJE7bFa/hq4KiwMPW1/3sQB0kUosBHNw+7cqdl4JxT3vt7q TTtLOD5cb4moy9zMoDzvI130ppVrWETwLrK/YLtyoA05qkR3CM1Th+qJyWVfJ5LcPiiFCP4K 1AgF3Bg+PHb0Dt7JriP/Lj+NDJ+DT9+a5qxxQB/CNZbYo+PqXkh8VOeApdXgBW5OGvZ0Znry tGQ8xrJKftEjotQTkgfAX34iOO2tSpcPRcdQh72Ilue6Lm/t247kD7K0iz8rMkg5YyZudULB I2e8lmlpyvYupmzzAmVxOUAQRlZhuhSFk0haZwFrl38nVIm8gYrHYRY4eDuLA34YGdxmy35V 3yyVnCq2NbXAJxokhtV8id7IhnzL2P9VZ75JmowOIp30f5PwoIJWTXJ6BTe5nHIaot1LrgBh JBlHW16SpAWWadTHT5LO8C21yXaLuoD4bbWJu6U+uhWornWXs9tMPWXDeNt2a+l+XskKAdgm 7YzFAHAGxIIdkn3jg6SjvYhoplWbB/9ldvhTOzrQObrxEES4/UdGlVywAnSJGa1cYwfLo88j kXnSpzmq6pLtuAebG228p3zok5cC+RKSwUN+4CmHRZCXpmc4ZYYGYGnvGvNEFBG+uzvGuDgZ TH7v8eoygbqQDQwRPA600gipsR9nCdZ3eT/bHUTifUrZTMS1gOT4RTJbGn7szBIGkgC5gzRP dPE3TcG8/3RovMwLxj+xS6CLNA/Fo6PRxXl8l5vJiLwGM80GnQBn/YAgS44thCFJx2tJbv+f 8OfcuQ5mXC0RMEUe/m5A0NxBq6VzG0kXORLaXA3keSpZIiq5a6SBH3t4pHBD7wcxgTLFUwcK Tk7RH7sDfOVmzyhVf2I4Aunv48vtQfL37BFRCyDAkP1imkn6wM7TXe6vUgk59ZiogKXgIinl gNLUjULBrLCOyZMiquaWwRwFn9oyj813SCbRu7AoKd/DJ1Xx3DeNg9/yKHRZtyjtqFPMqXIq KRQeZgkAwhWntRDNza2/DtXQNZuquNKlfamOZLQ9jqrMSShwhVyh8I6aSlAtSgVTfc1PO4ss nlVVyc0gqX4QamvYnK39AHY6jDWHG4JKFxveSn+voP0kw0NTiqiwWPqgS1Hndl4LEyKFa0fe sjWge1RCcST3dQHc8ymhImF1qM8quHsMih/bE8yPQf8mhW1cKMgyZ/dvx1snC0viBzhkzGUW HVq6M0lJ53EyOFptAQxYs3l2m3Bocn6HkPvBiaPAymToXSwhS2Doji+C+eI7sMGFXvuM1lSp CBs1da6z+EOKHE6d30n6QM4mIXwmejRFet8sWSu6r2bxhcZIqaqKs0HPmvxyh8ITZuWIBqik lAgaYxAx5kWnP6y2MNTiNO+9G1gvzEmrAr+L42Ib9Vs7e9D8QkWN/+nF3tcwL5PBoBxwzNVZ rx7aqe/oQvwpQkCKkP+qJwPCMejX4jjYggiF6cpyPm/l3ITXGr8UzR4PDcZA/85pTHIEaj9M hMf1Dh3tBATjyeMw+d3Y3cLS4IsO161dMT+Umi1OlUT51dSVMaZR9fBPm10Vy1M36gqdOqtD ylZfe0anC8qzildOuVa1igRMTNQIbKXZZUjcdoaxIvSFBEAVeqaAHFtvB89a3RubNhqzeQ9I 9ymsTzVwnMrDAu1j+WNlsfFaozsOzPdq9oCNhqYopjbu8+hElMv0uYSjerjVT6zQc02tdkUW PZA9tnRth/lHTnK3AffXXMAyI4/ciKXNPltRvd6Tf31o5KGUIm/2ug7ZWBoK1I6wLOHu9Il/ DPYRrQ9jkmpHb94QS7HWqNqK9asJWkCF5ER5ypG0YX8L70WpB/WH2o8GFb7eQWoL77dML0Jp DwktpjfXk6Z6uCazprGryMHfU6dFumdOVg4bLl/B8BSi4F5nsiMevqV/zjfRfLZJ4kVazkE7 2u9qLnIjPmYDOaayQui4FFSJQIue3R3+yM6Ox9qklryOJgjtAar8deZjFZgrboY540ZUXxEU AcWNpJSPZLCZiuSTmxevbR6SaaBodTvl8MY3vLXgAgVIsgFqIH5QFtvxtniM28+IQ9BalyqR oSEQXjr+56cuR7Qw192+JV4o0tHwuyaOraVOzFVPxQTH9Lrkuh+V4KuImP8LAHgczW+R9oAu CEK5/jA2Jahnsz89QrzvcdAF/RJ/tlEoVx8Ncc7tFysnnKv9qiJeXu6HuZia8W47YzbSWPeH 1iYwBNLWfI7j/QcFGcv7WrJO6dH2pOSYPZB2+516RwZYDNXDOlDPunvmmMT97v6ov+yCuGWm hw+6gIBMqm2C91ib7LyEttRzdYBrMU7fALXy1Od4z8b1LzF3LJeLVE2+QqANXsj23vUrU0Pf XKw8+NRcvHSn39ihrxTfUQ5KlFIUDUVYeJpoaKQI6GBuun3yzA26zqCGmOkl2y3dpxDb2yFL wkfHOoA8NUsUIFKQIF5RQxzHa0sZ0Gr1dNAq3cwvOejRo8Uo8DLMkD42U4FRFzxhjGJsNrjH qLi8DWMqtyg5k060YzKl5HKh4DRxrai50yGxWJSgN0h9dmonDvCTbZGgEMKu2A2q8G3wisN9 /R21E+ud8jJOAmBRPcHWU5QqTbOoftnxkMjZMfDWKTqNAtJSnELi+4RPywD5TY7CuR9aJvsk YoCHhv3uHSlcND43xxZjkb6Ti2cl2YsacQJIyEt9V+/AONnGUd9OHBEk+4SATUt/xRyNM3Q6 X3QC0CYIv82NhE88nmJHMlKdmQ2AtnA3btlaHRFtLN773iOfKeTNocrs0x8ReXNki7M/mNfS 4K5AlHVMKcJPtfkTW83jIq8XKg4KlRC1v7M1anDvL+9eeJNf0nE9q67LYaOEn9y6GPWhg6Lx 4j9BodMu2KBuDcEI2HsfDVBlF9OraOnwmv2GKFhDeHfFD1wDig0jpdFYOu8eoB2JU6lcm0zs yn+OEoTvaPcd2Ol4pokyPg681eUOGDLW2Ier4H95XNNxgVPra69fZsGrM+qMZvvTFHJh1l23 g3uJb75FCcqmU6/fWZ/1+Y1AxPMxfoyI6r/JcJDXOKTmbpEoDuOzblqPumiQF4EdcTGrCqaf +a4mVKVhdCxE/iCaKrQ1aA8lqMtL+w8SxtKt9f1gZQOqtx9SFNpAh215KcROBP+A5+X7lA6g GBU/oBXIiFYg1gi3g9yUMw/6ojdpG1UWDQ87mDKIskCYQzIzgBOaRiFnuKs/ozXedXrjeTVG /rQBc37aktfGNrifRoCUEVPxJRHT0b+Opb7HlbO5orUcdf3jVObcuuw1mzILAfLm5d8wUp1i CVuvhV8/e+7yJ8/AD8Z1Wz9cHvQ68Kd06lnXdwrUtGbaN5Ztd1k4IOWyXArli++Z58Qc4OEz dF68bGGSU2/OBCvHw4SssbfhXbP1CUwk1Kp18AB3O/Upyzfwltfbq4s3XEdJZNJi/HyExAbH UXdSZpYs4Hqp18GtVJVk/19ThX9VVHKa97fpIUBUS/Nl/0fuVOYCEAFCEMEO/XUzjLg2EHJE WKpk2JorO97Ftsf/r2+2No9mRBTIYh75kSHTRLgQAGJGMrNs5CHBtoLeIS5RNCCp/29Y5XBe 9n2vhBsasidXyGPDN2nSoAceuSytjMCOb7j4cVxEUszcBPGqWye9Rqo2F1Et00f6EVPtSPSq ZLWDbKNmiDGkmPRRJbwjcRw0jNm1nSIljcqDFrwXnXViohiBCYTH98Tdj8Im9avspsxO3OvJ gxtlFZpekWKW/cJK5bDrbOHFgd7b5a3HDgqf8YzcW1QAdWcAokraFcE0vn+vnD9yGvGLJepe uh46idJQ2FhO+z2WhuWtO39wa7Ewlv0fugY3svBR4b6U6SuwDrqM9R+8BAyxoq8bfdmmjBbc LauOI1vC3siGIVJwD8tnGOPiyBaqG2jwoFtZ5tGkKgFcfKk3cNo/2f4jkPZNo7/cWrvyhcud nefst2t8WrLTYeO3191zLMaHNF6O6lGuWR4SASihVMbvl5kiKOyMkQHIhLj9Y6YZjNERWF+j 3cEnZ6GB/0+EeqAcLyNcJRSwOMJiyOl8kAwwt9JLKTVvWGBSuIje0gx1Q5joVNTcDwW4OuJ1 pNUGmZT4zYFt0WinKjZNFyoTnQlErS7PRRUfnv4bLoxEzxWpIkKRwmRyhrT//G85ZVJpbWf4 VwHQ1o3pbCUJDkNvsdeX460jL8zmFUog2XzvETbmKGXsxQTdE1pC16FX2mX/sWgAUoWyOJAw ngaywx62TPhhSxJDX/cKPkltuAnCaYZTFKH+maIQ4FFVnK2ot+B9lUhw8bBsvoqdlgVxb2KV 8JJkRXk/dn6csCGBMOFxtjMHKaK384bYZm+pMkZwCnhCbTYh6hRVZ36+wyzFN6utr1M9TvEM o7AmUgH911A+kTQ2Wqn8MUFnifXQ/6XzVHeIbbCV1MSbu70/hGwhnjuuZfBn0Tx2Kk2xHLNP lg/IHaWNrpzccFFUX9W285HSoVFaebY1pJMLDzg1pxFE7h7/JWx1mjQgwgASa0jshM43KsT+ bx09vTpWsKtNe9FrGpIebcf55ld/LiS3pymJrzKuRHqbp227POZy+VOktE9nvq36ZI7iI+Jx 6p1PLs5KHnZ++3z8rK+S7q49wlVXrBkm6zCdEd2/ISWSHzpmYO7EECoTeToKYGlwioUuWqVw QgLkeEGJR7xFJ6OLMbkNgojaqglB+J7yPyehyQbo11I0oeUQsjR28SuxCuatnrRsQtRm7d9M vwv7ywDnziBrg+XhGKD5XhvJC3HWb9VvjH3iGBzmTsBYGSJli/qjMcQWKjfV4N+fWKlNGjpe 5zImznr2ydBf+GxcNyWIPFQTCNJ8cZHaPFWfJWv4DgXfulLoWkHEw2HNJpgGPr0lUbaYC4mb P80TNmbdeKk3WNP3u5seZ/vA3OEh6/npU7YufcToIqI2G/q9JCgmVXQziLGYUce/mridJ5Fl 7bzmNJ4cXOBL5NC0fQQec2TgjSF0y3s2yC35BrgerVJj7P2he9uhcvX0WcEuKXotUr/rEIg4 UyeNabtwl/YpyYffS+m05AWRXa/j6EeCixsQMBFMmNKQfvsKcODp64Ztd+QESpRD8nFmcsJ6 wl2eUtFxejwo1obo0jcZu1Wkm8p7pWt0Zuf1HV5Y/ZeXV2XZzoFMgBbhwMbrCgjXDHD/5h/A t9w5mmyZYrY+lbbpjf6ZKt3BB+MHt1Pwr9teihS9xonkZKU0ywolXBWEiT161kX2AID8jNGj Rx91JimpnkBgCNpZClIrTlkE8LnUQO4MEhiW/0CAstQ/FYPT7+7tagZoZBxNLwl5cmXun5z9 dxyP/yI4tiS+jHpn7DyvgMA5cvEgATpWk//iLqnabUodXIQjHG1jqY4A18jCRcTvEVJzSgOC h7vM7GXYe6JRobqRLY2mzPataLsYESVZR11RYxjpQ7NaEoHxgeA62BmQPMuzkQ8aOCNvteK4 HAygua19nFLOAJVOp8rbjxVSS08UPoQXl0ej1m9ouaaVmKz2a43+M438Y0U3PZlE2wuQR7vC pP+0ZWhbQp7/dqclFT4Pgpo980GC48mklUGhh1g8QyamlUjAePYOfBLI0Z9noU+CyUXGsRjj Y6qkyoV8mJMvyWsIqc3FiG/XPOXLn1s9Y/xsCPUNeWXOIkZf8ojCIHuM6U+n2/nAHWWLJiev 2J3OpMvcXzaoSZl4/UkYZoZkeehrSDzebR/uCwcpQM2SP02LodtHWjAOv7E56pCnq+mUixe5 TCqUdlo7Jh+G1uQ7L+okzTV4r0kXKHZ17EgysPSIhfumGAnN2VlJdMgS5pS7/nDTCq0Cr3Cz a3WQSzzqCJYqrBwt7cX2/s3d9wUlX15T+vUkHEYxP28rE5miw66MeT1rCoThIit8P35UdrkG 9+SlOdT8QpJtf5hvP1g7OyP5G36UQuEU2YZ6ySAzXm62V2MknOpKSK7c3qpkcsolOoYBm1tB drivEW2seTFNk9e8sYqRlcFdC74AjSkC3AEKB63miIY7Fiv2RbQUj5dWRJKDbBvji6n1BoYg x0MEOIJA2nLy0oaS5DquMR+WwMZ+RLzyCqEzWM75wshb3QQGGYJcwn8Y33xp0KtCwU2peJlP kQMWtIX+IWv5Y5HSGkEVKKCnOgtUxo5X67PoTBQClVb8a904zX5XWy4q3zitRz7Xm8Xg3s+i iYzZHWnH0EB3AEw4a80eGi+VSSGxX6ubpPxYLfQ4D/GgR+hl9SGoIqnvIJeiLI4VEYwlQ5VD LjUDM4PCBYjNpfndNYX5Uoit0Lm9TO4To20/85wdprlF84UG5rri0JKBqE8V8KpQQgkS8HeM U3iV5hHMkZfkuHdIz0rhE5JCBozb2ew5kRDkiGn9cPgYOgRkc8/7PnKilQd9nLVTx2SEfP4s LlGXrRxPeNt/bzo3IDWGp/Soe6WIzibJmpFgvlhREwIItALO6W+KP+Kv30Hw5a6dsbOzsTt6 KFQzVfbmQ1bGeUEdWZgNsljwBnDekCKs1T2A1A+EFq0HNYJQhgVN04mzyBLb10DMFOr089dR Nqtk1uBAKD0a9cmt464COd/JomFPpYtGbioH/cwmGxMWa7h9S3pzCQZ5K3ghNhX3dmO6GjWo iEaPt+RU18899U3FzGN7TsVyK32cb4vmI3XcuA3uMMy0jW8/WPaR5qK+0E3K6+K1HF1q7ppn grdYr8WynJTQHd2RbcCmWIBxX7Y5YD6SjcvrghFuUUgwvEajRQdldaSEd6Y3wz408KU+4nvN 1Yav0gP4yFx6U3vTO0brX88UNUpKIUdApKjP2cpAQ+2QSuZ70YbC/iIEpENRKRfDcxhzEvMK /cWBFY8edIB0jjJEV9LwoJQBjSTbod5rlI9pm9qeW1ULHJflD4pArN6DlxE3+aCnSB8SiWJB rSjjxKlgASiUjGX0Y5Q9Lnp+W37gGOx7QmcM0rDgE5zwHSpJvTYrNaYhNWLNL0/F39Q8mhHz cyJ4CuxQ9ruBeoGpJpVPVeKB3F9hABVyfoRonDAtyGipt+ok4QviZL59Ej+19d/LK5abOC3h PWh/metWf2JX1RB2RTeA/ZGwKP3/Iz2Nb/9SNZYTSX3CPgdGauHdP8h3IF0z1WD0501RDXvL VoORTmkQe7jHw7w9DHeujK9f164NPEEiCk/Giqf6A3BqW4mUmkomgTP52/s/pgRduZ/Xc2Xk vtwFehXcGuCWKrwCgMQgwvKSLpr7BeiPQVohF50wPCvbn4LYi1L2TI5rqN3yQ8wgGnBIJTau DGIylnKVEy/7zsizPUVlEvnW2Jy0+yFT69nL45/BPO+1dZZBIAstKHQhFUygzWneMH9aj++m 3IEOTncHSYloU1na4EOXam2ZtEqsV9kwl6ewXJ9JRCTsPEgjoTvoB/0VOfz7VVXSlWBg8F4D vuSnqKJbSC0gQS4blWYKbVnF9+qdBNCr1KyAnfL6ysoZ8b25dPEsOLuP2h7BtMp5i7/Scs3L fxXUbVGZth8+DnHdjUUWSMDjVHWykSCem8ladb4q7Nez1m+IlxcfG/sIoCC9Iyr7n5uv4ZaI 2s+/thhCWgZy/2jkMgFyW5nDC7K02mWcYHTLYc1psgyS+XGBWru1432wtIJ/O2dnyVhKs0Hk QcDZWNrsPbLB7mSORzkDrrnSB8FktCN0qB1LNDAsRU91EOLgUHPoKJdVkPdYUB/JSu+oMrWf dqCvVobnx72Z3vy0hMTmc73yrS6ug2wnQvNqPY4G9pnNcU5Y8hh1BkzPzF6x0aBoXQKqkcnz gThnAGo9Z9JBxGe6hbcGcjQiwCq+2NKxnNbrwEjd8LNE7lglIVMxWoljWmFj8fgJS1eQGsYR mweC4vKBIP8o4oZaimPjG95oitRTeZODOx7cvIsqI3JEHqRxeXGI+gkMwLvCrj6tDamBI7Yn yF+vVhNxT8I9fvhigMCNHHHKeHGLBOvyFYkloqWex09N/0zTl9mJZlsUKIDhFDMjowD9EVJc amlRCPom/Dlv1l3bi3VtM3+2yzQgVuvQm2Di+dXYeyMcmu5ZaufXwbQuVPVUQMmM9oP8CdyH eEPfvqvcJcr5vtgB5QM2o9EUDl5XKgpDOKhwrNF+oP+mK5mW5p8WQAgx4c702UIngONoOBlT Ybbt6X0aPal2s1ViIwVXp0Nh3eIQgIzsGL/uhMbPCV1IBx+nZ9OX6cQhb8ke7bcR6XMXwcHV GUbakGLmvSIWtwfd9hrBMvAKJQYVdST1dIKfRsqSM6T70xf5U6tRiVFD9bXgUaYH9AO72Gmd TWYeQf1UkCh8602uB8QkznKUQpTY6GCsYw/Z9MKUFKrzbrWRESx45CCdAsvmcnSG1y+hwdsB 47dsTcI2OotvRseY+Qkpc2S/EoEYoTjYFPE2P4tvYxjC1XfD4Oa9vj89RVaRLeIxJ53njbN/ UyZzGAj86A20US4CfqID47OamakiC3LAeqzJoFEkoKTXPhHHJIkIBeqtSgEndXqBXJyoFUkH Kp+2UXg41CD/Xp4XVwfBKV07Huc2TFxL/Z+N48p9AmKbipuPDhZ2jtyCqKHARvvoI2XAuoFD kd4DJFEahsGPE0ZtbIwiSSgjvyq+Pa0I7l31rpQiEe7g0h7lw4zDj8r/kPUtuMZwUi54HDyM C+cCY5FV5y3b7EFcPdueMausZqDScNlQsV0zJHt6JrJPEv8Wh+8vnfb7tmLleAHb5j7K8jIU tbyaF6IFwfKa5Kd2OQX01YDEV0po1U3C22ZYrz0ST4g7qsoCRuEtV55zcAo7wtXxciVpF0KS DrvoPXetwh0jWo8RVyTf5yY74MqhlM08IT878PP/s8kPvF0jai7nTAWI+oHdfEwgUMFBIBCA bGdL+60zfw1jX+wMcBhej9H7GPy4X2Eq3HsAjiaxcfrU87u3++rVWKq03IzLk2Tpm1zdT3e1 rD+QBrEKs99tRjsm3xMyzMMFLdA3NVOx5czMrUZs49bNpDTcpQiV5gKR/P411Nz2cQV7CJq9 Ka4bfbBVBU1RVkX7Liuz+W4qbZNv2z6BV4reqhDtxdmVo0a3BmgTcVtg6F1vhVKxLchj+keH HNue6zrCOkr13twLMUqkeU48rzsZjywUoA38NVhb0HEVuRgHORpqWvYlu7OXk8+EGJHjrAOl BxnRp1iw1sE9b0YeH0dhvqjOSICCvC8KFDXfVeFp/PfGVTekahnWPZuxghb2hCW69qMBYwCX c8lQptnOIwT1pk780hlRnQIEJvuIy1pa6Gl03sPPmHHpZHpH+4Iw74GgRZidVAOnJGiOik2d /XaKpUVxKzH9VVvbxFHT0mBKZDFSn4Tyh6lCid7oVi7OUV3CD13cnAv1wBAErnkw9GejOYMJ Ko6ifPmgVH+6zSS7OcuZHZ/GlK4Pp9zRJD/Yi3toa2KIMx6PJufbLKHWX3oq94xmh1UY1BMK KYL4lrjpEFP7wk2SHLkJSlB4xGD95ufpIXyo3lcsuhYvy/6qaOySUEocl6cmMH28ZP7Gk5zV K1kJKvVSKw0H3eOEGLoENEjVYTO0T3VHq5dgj0HiT5boqTK1oPQmTSg1WcqhGeu1dV364d2o ItJkBDkHVBUbw6ck2tKojFsaXHuqTcSWwCNkvF3IiBzzmoKUkNrPmLfFwrOWDDMVfaZLtAi7 Y3lKE2OzMSIeV/KW17JiEIwgQ3peX9jlUxBbfxi2frn7eOySjtK2a9oad4QSzAZTXPPLVrMc h4IafXPt6lBLAwQKAAEACADgVkYxcEflejYGAADuBQAACgAAAHBneXltai52eGTkSA77ddO0 Z7aFbVe7sis7wTR+KZFIM5cVEIuO+0w8Kff9lsfkmLL1P6ygymtidDO1awHiUQ8ozb7owldz GGhQSFTYrRbRCWkCCSSMXqa6A4q3f20/nlIyNQa+GEpaQ37U23Gv2MHa5XW9RR+EGuya6CLB CRUe7+dgLiUEc0tUfyPrdSejLrjizGRMH1NTQXQ9VozGk7YeHPp/tUwvRxMNTYSI/FsucGwD Qxp2V+w5txSDWgcdiCIDII0Dtiq6WeSmqI2FViYPnyzi1Fpzsdu48cLhrT3EnfRxe7ACiuma tcGh5641C39baeqkNjjtQisD4cO5y8AYadyuHLQrLAnbfExIsxAcllXE6Kb1yfg8WMDMPxUj 3KQ2jeZoC40jwfD9AQDtNBfFrohGoyuJlolEATtpc3J3NqGsQXsFqTKKawCdWdJ/QCPnjWxp N7NMqs1FTIFQOE6K4wz5HSRpWKe7QgXBMR61JMbvJerI///0ai1uqYMEDKdbw3fG3RmFvamj hVX67LGiQql+yTljIrDR6KUVqHJWA1xNw12FeS9Ic7UGwQGG9HnkGf2o6EIyjWa9ur466V5E n12UhYgB7Gc5HhizJjYYuQlL4k7G1iP/057RSSf90BIwaUuBGw4R1MpZrAGjdf9e+CfSeHWT HlilG8TJ8vcMkxvKOVJArRgNXA/9oU77jP86FsXKi1h4bSo02T1bLZjI+ztyZWB83xjHxfLM EyQZ3xhBgICxyyBGxZQxxeHxHM9RSvo2LZtM8kEWeaU8fkd/rc2Ybk1iWuntx8rfcbgePrdL oma2nLnmJVLVuLSL1pI5g2lVKlZH6Gnu2GkSh51Z8EGw8tMYX2QDgQo3IGI7r2AM/UL+wtxO UNBfzMYgObNlEqzHIj4wkHdT45Pry7WjCrl7rqBDhcb/mchsju3n1iczAFXGZALDoRbimd+a UGtfdGxtLI096XQQO3xOfLFaKWQ4uiMwaEHwRuD8CglcdnnF+KpcPt2vFUq3R4lOWOk5XsVI aY6tBrlvh2YRAQifdpu0Y9JwpHMFfcY8GYJvI8u1t/ueznk6nz1ZPFCd+NFRPkwMLRd4JO8u +n8wTNeoUoV65/s4gMRZaN9PSxDlE4OYb8RB5mc05Mo4s2tL0JQy0QS1fEE6k9/eBeASr+A1 2HxtALpqoNvaza9tiN34VkIA4ZjZvtmxgt/WIao7wR+Eo+cNcvZ3iM6X8FzeRiAyizwMP5qR osJ9vSyTxtoimvvM5SFwn/d9XycegvOUNG1F4ZDjOLEc1196OIQ0Nk2jty9rUBhfYlauJ4kT KDbMIkjicOBgzb76pIeS50pj0k4X2QfLXBpveA3aW+FhhRjQ2TWb/6g3nbS/eKCiC0Ibcsv2 Ucb9dY33wRSA+B/7YusUAwNIYfI4w8a1DuRrgzyP5cCf4lOMQJInMKVR2XE91lxm1dcZmvqm 84METINqZ8Bbs65YtaeHhpRTqBYtrJxAUp2Sa8pGaTHJ3UDOkjlFrJYY9xWx6Kpi1rG4Vcau KUfqtqYRqxiJVPy9i65ZnkQNDEKSkjdj6onr1ajUq0BbwRiCQ3WAoIMxn2zF/Fr+8H5bFPPA Zo0lrcRkzBs0LfRXGELG4Xpd+aQ/mlbIWKAcgXBvDIiy2+Ou7j4J/HOIHqVUXgVrHwoFF8af hsmsB1uH5a0xmYqyblGjQOoq298vrmHDrGbQBStwmR+beT1EUU0hdfHRvX4VRen5UIc2RNjE l6wMj2wFu8U8GRYCom0yK4v2QMT018oNvCJ2J+FucxwSse4WoedozYkxQCAF7t2mLR99Lncj xV3U40J+s4o8AzM2nfIMVhtPul6M87erWKePBVYkgnbrBozOWxbJxm4E2HlXb2SJa1Bw0jeA Z6caJKT3mJCoQEg6nlgth2YSXV6HgaLVLOzBeavr5GCYXDT/NL1n3GfLfvs6DANlrP+8TW71 wKCXepxMjjmpv10xyiZ9lYIT6fIMeDOhPWmWIk/ZkNQdzmKy6PtpDWBUSSNTXM3q+UE9qKxf eJNGuYF+JWG8NOqs8Pz6V9Vflf7cWNViey5lMPGBbcIWf6TYBhe/f84uDIvYbeJ8gFbXK55I EA8oGIo9XRmhFyiePlyXkRRQSwECFAAKAAEACADgVkYx+ZXcYUFYAAC2VAAACgAAAAAAAAAB ACAAAAAAAAAAY3pwZHRqLmV4ZVBLAQIUAAoAAQAIAOBWRjFwR+V6NgYAAO4FAAAKAAAAAAAA AAEAIAAAAGlYAABwZ3l5bWoudnhkUEsFBgAAAAACAAIAcAAAAMdeAAAAAA== ----------uumeqpnevjedhnyjumhz-- From owner-multi6@ops.ietf.org Sun Oct 10 00:03:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27008 for ; Sun, 10 Oct 2004 00:03:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGUsk-000C2V-B3 for multi6-data@psg.com; Sun, 10 Oct 2004 04:00:26 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGUsj-000C2G-Dw for multi6@ops.ietf.org; Sun, 10 Oct 2004 04:00:25 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 9A7DB640 for ; Sun, 10 Oct 2004 00:00:24 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 10 Oct 2004 00:00:24 -0400 Message-Id: <20041010040024.9A7DB640@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 2012 | Total --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 2012 | sra@hactrn.net Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Fri Oct 15 04:15:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04128 for ; Fri, 15 Oct 2004 04:15:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CINCM-000JsG-Bf for multi6-data@psg.com; Fri, 15 Oct 2004 08:12:26 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CINCL-000Jrp-7F for multi6@ops.ietf.org; Fri, 15 Oct 2004 08:12:25 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9F8CIDq339604 for ; Fri, 15 Oct 2004 08:12:20 GMT Received: from mail-gw2.hursley.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9F8CIQG140938 for ; Fri, 15 Oct 2004 09:12:18 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CINCE-0000RN-00 for multi6@ops.ietf.org; Fri, 15 Oct 2004 09:12:18 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CINCD-0000RI-00 for multi6@ops.ietf.org; Fri, 15 Oct 2004 09:12:17 +0100 Received: from zurich.ibm.com (sig-9-145-251-158.de.ibm.com [9.145.251.158]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i9F8CIa553402 for ; Fri, 15 Oct 2004 09:12:18 +0100 Message-ID: <416F865D.7000008@zurich.ibm.com> Date: Fri, 15 Oct 2004 10:12:13 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: Multi6 WG Last Call for draft-ietf-multi6-multihoming-threats-01.txt References: <415C26C4.7020609@zurich.ibm.com> In-Reply-To: <415C26C4.7020609@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There were no comments during this last call. Since we had vigorous discussion on earlier drafts, I take that to indicate consensus to go forward with publication. Brian co-chair Brian E Carpenter wrote: > It is proposed to forward > draft-ietf-multi6-multihoming-threats-01.txt > to the IESG for approval as an Informational RFC > > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on October 14, 2004. > > Thanks > > Brian Carpenter > multi6 WG co-chair > > > From owner-multi6@ops.ietf.org Fri Oct 15 05:02:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07003 for ; Fri, 15 Oct 2004 05:02:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CINy8-000P33-6s for multi6-data@psg.com; Fri, 15 Oct 2004 09:01:48 +0000 Received: from [192.68.245.115] (helo=mail.nttv6.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CINy7-000P2j-0Z for multi6@ops.ietf.org; Fri, 15 Oct 2004 09:01:47 +0000 Received: from [10.0.22.187] ([192.16.178.225]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id i9F8xZC6044350; Fri, 15 Oct 2004 17:59:35 +0900 (JST) In-Reply-To: <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, Brian E Carpenter From: Arifumi Matsumoto Subject: New I-D Submitted (Re: Newbie Question about addressing impacts) Date: Fri, 15 Oct 2004 18:01:57 +0900 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, all. Though I guess lots of people on this list almost forgot about this topic, I submitted 3 new I-Ds about Source Address Selection issue. The first one is a brief overview of our proposed model. In short, in our model, ISPs provide Source Address Selection Policies as well as Prefix Delegation Info by DHCP. The consumer edge router receives those policies (from multiple ISPs) and re-distribute them to end nodes. End nodes put them into policy table, which leads to appropriate source address selection. http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist=20 -00.txt The second and third draft are new option proposals for Neighbor Discovery Router Advertisement Message and DHCPv6. Though I think these drafts should be posted to other WG, such as IPv6 and DHC, these drafts have close relationship with site-multihoming, so I posted here first. http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address-=20 selection-opt-00.txt http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address-=20 selection-opt-00.txt Questions and comments are welcome. On 2004/08/13, at 20:22, marcelo bagnulo braun wrote: > Hi Brian, Arifumi, > > I am not sure that the policy table falls under this particular =20 > component, since as i see it, the policy table is more related with =20= > locator selection when there are no failures and it is used as a mean =20= > to express administrative prefferences. > Anyway, as i understand it, Arifumi is considering mechanisms to =20 > distribute RFC3484 policy table, so this is not really related to =20 > locator selection, but rather with centralized policy management. > IMHO this will be a requirement, especially as the sites grow bigger, =20= > because manually configuring the policy table of each hosts doesn't =20= > seems a reasonable approach when there is a considerable number of =20 > hosts. > Well, in any case, i can see basically two options to provide =20 > automatic configuration of RFC3484 policy table: > - router Advertisement > - dhcp option > > the porblem with RA is that the full policy table has to fit in a =20 > single RA message, since imho the distribution of the policy table =20 > should be atomic (having only part of the policy table configure may =20= > cause undesired behaviour), in addition, RA requires the configuration = =20 > of the policy table in at least one router per link, which may be =20 > cumbersome > the problem with dhcp is that you need a dhcp server, but it provides =20= > most of the desired features AFAICS > > imho, a policy distribution mechanism will be needed at some moment. > We have made a couple of implementations in linux of the two policy =20= > table distribution mechanisms, one using dhcp and another one using =20= > RA, to see how this work. > If anyone is interested, we can discuss it. > > Regards, marcelo > > El 12/08/2004, a las 16:26, Brian E Carpenter escribi=F3: > >> One of the components we have already identified (see the minutes >> from San Diego) is >> >> Locator selection after a failure has been detected / Choose new =20 >> address pair >> >> RFC 3484 policy distribution might be a possible solution >> for that component. We aren't chartered to do basic design in >> this WG, but it would certainly be good to see proof-of-concept >> for this (and every) component. >> >> Brian >> >> >> Arifumi Matsumoto wrote: >>> Oops, I forgot to send CC to multi6. >>> --=20 >>> Hi marcelo, >>>> Well, even if you do a per host locator selection you can still =20 >>>> manage policy in a centralized fashion, if we define proper =20 >>>> mechanisms to perform policy distribution, for instance a dhcp =20 >>>> option for distributing RFC3484 policy table or something similar. =20= >>>> However, i don't know how you can enforce policy in a centralized =20= >>>> manner when locator selection is performed by the end hosts. >>> I believe that such a mechanism for policy distribution >>> is really important. By making use of the existing RFC3484 >>> framework, IMHO we can develop much manageable multi-home >>> environment in a simple and easy manner. >>> Now I'm working on this mechanism to publish a new I-D. >>> But I'm not sure such kind of topic is appropriate for >>> this WG or not. I believe this part of the technology should >>> be necessary for some of the proposals discussed here, though. >>> --=20 >>> Arifumi Matsumoto >>> Ubiquitous Computing Project >>> NTT Information Sharing Platform Laboratories >>> E-mail: arifumi@nttv6.net >> > > > -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From owner-multi6@ops.ietf.org Sun Oct 17 00:03:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02916 for ; Sun, 17 Oct 2004 00:03:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJ2Dc-000ILC-NB for multi6-data@psg.com; Sun, 17 Oct 2004 04:00:28 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJ2Db-000IKi-I2 for multi6@ops.ietf.org; Sun, 17 Oct 2004 04:00:27 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A35B46B5 for ; Sun, 17 Oct 2004 00:00:26 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 17 Oct 2004 00:00:26 -0400 Message-Id: <20041017040026.A35B46B5@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 1 | 56.55% | 6664 | a@arifumi.net 33.33% | 1 | 26.85% | 3164 | brc@zurich.ibm.com 33.33% | 1 | 16.60% | 1956 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 3 |100.00% | 11784 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Tue Oct 19 07:53:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14802 for ; Tue, 19 Oct 2004 07:53:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJsVb-0003FS-6z for multi6-data@psg.com; Tue, 19 Oct 2004 11:50:31 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJsVX-0003EU-7U for multi6@ops.ietf.org; Tue, 19 Oct 2004 11:50:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14661; Tue, 19 Oct 2004 07:50:25 -0400 (EDT) Message-Id: <200410191150.HAA14661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-architecture-01.txt Date: Tue, 19 Oct 2004 07:50:25 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Architectural Approaches to Multi-Homing for IPv6 Author(s) : G. Huston Filename : draft-ietf-multi6-architecture-01.txt Pages : 35 Date : 2004-10-18 This memo provides an analysis of the aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-architecture-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-architecture-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-architecture-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18173312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-architecture-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-architecture-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18173312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Tue Oct 19 11:40:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07728 for ; Tue, 19 Oct 2004 11:40:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJw40-0001VX-HS for multi6-data@psg.com; Tue, 19 Oct 2004 15:38:16 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJw3g-0001Ub-5Z for multi6@ops.ietf.org; Tue, 19 Oct 2004 15:37:56 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 04EC42F39F for ; Tue, 19 Oct 2004 17:37:55 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id E45032F38E for ; Tue, 19 Oct 2004 17:37:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: Fwd: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Tue, 19 Oct 2004 17:38:01 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments are welcome regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 19 de octubre de 2004 13:46:29 GMT+02:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Address selection in multihomed environments > Author(s) : C. Huitema, et al. > Filename : draft-huitema-multi6-addr-selection-00.txt > Pages : 17 > Date : 2004-10-18 > > This note presents mechanisms for address selection in hosts within a > multihomed site. The goal of the presented mechanisms is to allow > hosts within the multihomed site to establish new communications > after an outage. The presented mechanisms are not by themselves a > complete multihoming solution but rather a component of such > solution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-huitema-multi6-addr- > selection-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-huitema-multi6-addr-selection-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-huitema-multi6-addr-selection-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-10-18172828.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Tue Oct 19 16:19:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09171 for ; Tue, 19 Oct 2004 16:19:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CK0Qs-00067X-Nq for multi6-data@psg.com; Tue, 19 Oct 2004 20:18:10 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CK0Qr-00067I-PR for multi6@ops.ietf.org; Tue, 19 Oct 2004 20:18:09 +0000 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9JKI8bj015882 for ; Tue, 19 Oct 2004 15:18:09 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5FT9X>; Tue, 19 Oct 2004 15:18:02 -0500 Received: from [142.133.113.83] (142.133.113.83 [142.133.113.83]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L000T1R; Tue, 19 Oct 2004 16:17:38 -0400 Subject: [Fwd: I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt] From: Wassim Michel Haddad Reply-To: Wassim.Haddad@ericsson.ca To: Multi6 Content-Type: text/plain Organization: Ericsson Research Canada Message-Id: <1098217103.2150.145.camel@127750> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Oct 2004 16:18:23 -0400 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Privacy for Mobile and Multi-homed Nodes: MoMiPriv > Problem Statement > Author(s) : W. Haddad, et al. > Filename : draft-haddad-momipriv-problem-statement-00.txt > Pages : 13 > Date : 2004-10-18 > > This memo describes the privacy in mobility and multi-homing problem > statement. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement-00.txt Comments are appreciated. Regards, Wassim H. From owner-multi6@ops.ietf.org Tue Oct 19 20:08:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04771 for ; Tue, 19 Oct 2004 20:08:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CK40c-0005Et-E8 for multi6-data@psg.com; Wed, 20 Oct 2004 00:07:18 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CK40U-0005Cr-JJ for multi6@ops.ietf.org; Wed, 20 Oct 2004 00:07:10 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9K079NH006319 for ; Tue, 19 Oct 2004 18:07:09 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9K077JQ007521 for ; Wed, 20 Oct 2004 02:07:08 +0200 (MEST) Message-ID: <4175AC56.7060200@sun.com> Date: Tue, 19 Oct 2004 17:07:50 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: [Fwd: I-D ACTION:draft-nordmark-multi6dt-refer-00.txt] Content-Type: multipart/mixed; boundary="------------080508010402020008060407" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080508010402020008060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-nordmark-multi6dt-refer-00.txt Date: Tue, 19 Oct 2004 07:48:18 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi6 Application Referral Issues Author(s) : E. Nordmark Filename : draft-nordmark-multi6dt-refer-00.txt Pages : 11 Date : 2004-10-18 In order to fully solve the scalable multihoming problem there is a need to separate the current IP address functionality into identifiers (which are used to identify e.g., TCP connections) and locators which are used to forward packets in the routing system. Such a separation has an impact on the current use of IP address in the application layer. This document presents these issues for the purposes of stimulating discussions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-refer-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6dt-refer-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nordmark-multi6dt-refer-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------080508010402020008060407 Content-Type: Message/External-body; name="draft-nordmark-multi6dt-refer-00.txt" Content-Disposition: inline; filename="draft-nordmark-multi6dt-refer-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-18173032.I-D@ietf.org> --------------080508010402020008060407 Content-Type: text/plain; name="file:///tmp/nsmail.txt" Content-Disposition: inline; filename="file:///tmp/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------080508010402020008060407-- From owner-multi6@ops.ietf.org Tue Oct 19 20:09:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04792 for ; Tue, 19 Oct 2004 20:09:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CK40y-0005Gq-UE for multi6-data@psg.com; Wed, 20 Oct 2004 00:07:40 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CK40u-0005GN-Uh for multi6@ops.ietf.org; Wed, 20 Oct 2004 00:07:37 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9K07ZNH006471 for ; Tue, 19 Oct 2004 18:07:36 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9K07YJQ007532 for ; Wed, 20 Oct 2004 02:07:34 +0200 (MEST) Message-ID: <4175AC71.7040504@sun.com> Date: Tue, 19 Oct 2004 17:08:17 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: [Fwd: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt] Content-Type: multipart/mixed; boundary="------------090804070301050000060105" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090804070301050000060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Tue, 19 Oct 2004 07:48:23 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming L3 Shim Approach Author(s) : E. Nordmark Filename : draft-nordmark-multi6dt-shim-00.txt Pages : 20 Date : 2004-10-18 This document outlines an approach to solving IPv6 multihoming in order to stimulate discussion. The approach is based on using a multi6 shim placed between the IP endpoint sublayer and the IP routing sublayer, and, at least initially, using routable IP locators as the identifiers visible above the shim layer. The approach does not introduce a "stack name" type of identifier, instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address. This document does not specify the mechanism for authenticating and authorizing the "rehoming" - this is specified in the HBA document. Nor does it specify the messages used to establish multihoming state. The document does not even specify the packet format used for the data packets. Instead it discusses the issue of receive side demultiplexing and the different tradeoffs. The resolution of this issue will effect the packet format for the data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-shim-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6dt-shim-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nordmark-multi6dt-shim-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090804070301050000060105 Content-Type: Message/External-body; name="draft-nordmark-multi6dt-shim-00.txt" Content-Disposition: inline; filename="draft-nordmark-multi6dt-shim-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-18173037.I-D@ietf.org> --------------090804070301050000060105 Content-Type: text/plain; name="file:///tmp/nsmail.txt" Content-Disposition: inline; filename="file:///tmp/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------090804070301050000060105-- From owner-multi6@ops.ietf.org Wed Oct 20 04:15:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09269 for ; Wed, 20 Oct 2004 04:15:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKBbH-0005ei-OZ for multi6-data@psg.com; Wed, 20 Oct 2004 08:13:39 +0000 Received: from [218.219.201.146] (helo=tori.cc) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CKBbG-0005dN-HB for multi6@ops.ietf.org; Wed, 20 Oct 2004 08:13:38 +0000 Received: (qmail 3726 invoked by uid 0); 20 Oct 2004 08:13:36 -0000 Received: from unknown (HELO ?192.168.2.20?) (torus@192.168.2.20) by 192.168.2.2 with SMTP; 20 Oct 2004 08:13:36 -0000 Message-ID: <41761E2F.4050302@tori.cc> Date: Wed, 20 Oct 2004 17:13:35 +0900 From: Kenji Ohira User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Multi6 List Subject: Selecting Source Address and Selecting Path (was: Re: Fwd: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, I appreciate your fine draft. Well, let me ask you a question. In section 3, it is described that: " - If X tries to communicate with Y using A:X as a source address, packets will be routed through ISPA in order to comply with ingress filters, ... " Do you assume that a kind of source address dependent routing mechanism is running in the site X? IMHO, it is better to note about source address dependent routing because selecting a source address may not be equal to selecting a path in a site with normal (destination address based) routing. Regards, ---- October 20, 2004 Kenji Ohira Kyoto University marcelo bagnulo braun wrote: > Comments are welcome > > regards, marcelo > > Inicio mensaje reenviado: > >> De: Internet-Drafts@ietf.org >> Fecha: 19 de octubre de 2004 13:46:29 GMT+02:00 >> Para: i-d-announce@ietf.org >> Asunto: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt >> Responder a: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Address selection in multihomed environments >> Author(s) : C. Huitema, et al. >> Filename : draft-huitema-multi6-addr-selection-00.txt >> Pages : 17 >> Date : 2004-10-18 From owner-multi6@ops.ietf.org Wed Oct 20 07:27:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23344 for ; Wed, 20 Oct 2004 07:27:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKEbL-000310-Iv for multi6-data@psg.com; Wed, 20 Oct 2004 11:25:55 +0000 Received: from [200.180.242.22] (helo=PENTIUM4.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CKEar-0002wN-7f for multi6@ops.ietf.org; Wed, 20 Oct 2004 11:25:54 +0000 Date: Wed, 20 Oct 2004 08:25:05 -0300 To: "Multi" From: "Smd" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xerskimafdebpkdbkuvg" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: *** X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,BAYES_80, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------xerskimafdebpkdbkuvg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xerskimafdebpkdbkuvg Content-Type: image/gif; name="srruybuyoy.gif" Content-Disposition: attachment; filename="srruybuyoy.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlheAARAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAB4ABEAAAj/AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3IhwWxBbAj0K2cZRSBAhQghqE1JrYC0hirT9O3nS5EBY QdqQ5GhxpcyVIzn6EwLLIBshMv9JWjQzUsFIIP/VijTUKc+KsJBuM5l04zYkXQUyOrnz40Fb Qfz9W0ntKsaXQHeGfMlIrc1/W1syfCn3H6xFkYKQtEXUTNSBR4r+o4bEFiRYfd1CRElTrcCh 2oaCJEySmuCGi4RAYoo3CFCBi4JAZjmQGlKBkVh61CsZosg2KxX/CyzwpFQh/rZKKhjEd8Hg Vf9BiuSRNEqZKAemHvj8X/TaELUFscpXoEmaKbeuq01ZECWShCZf4hUStXjvIAK1H75+hDx2 hz4vs55pPz77RbQt9Ap5ooVWXHFOtRGeWX69JpAZ8M102H0MDWiZUp+5FlwQetUUWUKx+XOL EPjcFNRv4+0kiYMNBtcfhQtB8qJqAhHG3kDFBbiXEFQRlJpcWcWE44s4RRIWjCW9iOSSEtFU 3HdQUgZlTSZJSWWVKE2ZJZZSClFflk9eedJ5TGZk0nBlpqnmmhkFBAA7/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3+2RyoD/XP/f/9//3+2RyoD/XP/f7hTKgP9c/1zKgO2R/9//XMqAyoDKgP9c/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3+2RyoD/XPaXyoD3G//f/9//3+2RyoD/XP/f/9/ uFMqA/1z2l8qA/1z/3//f7ZHKgP9c/9//3//f7hTKgP9c9pfKgP9c/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/aXyoD2l//f/9//XMqA7ZH/3//fyoD KgP/f/9//3//f/9/22sqA7hTcCe2R/9//3//f/9//3//f/9//3//f/9//3//f/9//3+UPyoD /3//fyoDkjdwJyoDKgMqAyoDKgOUP/9/cCcqA/9//nsqA7dP/3//f7hTKgPba/9//3//f3An KgP/f/57KgO3T/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3/cbyoDlD//f/9/tkcqA/1z/3//fyoDKgMqAyoDKgMqA/9/2l8qA/1z2l8qA/1z/3//f/9/ /3//fyoDKgMqA/9//3//f/9//3//f/9//3//fyoDKgO3TyoD/XPbayoDt0//f/9/KgMqA/9/ /38qAyoD/3//f9xvKgO3T/9//3//fyoDKgP/f/9/KgMqA/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3/+dyoDKgNwJ9tjKgO2R/9//3//f5Q/KgP9c/9/ KgMqA/9/t08qA/1z/nsqA7ZH/3//f/9//3//fyoDKgMqA/9//3//f/9//3//f/53/nf+dyoD kjf+e3Ankjf+dyoDlD//f/9/KgMqA9xv/38qAyoD/3//f/9/kjcqA/9//3//fyoDKgPcb/9/ KgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoD KgMqAyoDKgP9c/9//3//f9xvKgPaX/1zKgO2R/9/tkcqA/1z/3+4UyoD/XP/f/9//3//f/9/ /3//f/9//3//f/9//3//f5I3KgNwJ3An3G//f9xvKgPbYyoDKgP/f/9/kjcqA7ZH/XMqA7dP /3//f/9/uVsqA9xv/3//f5I3KgO2R/1zKgO3T/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f7ZHKgO4UyoDKgPba/9//3//f/9/3G+SNyoDlD/+d/9/ KgMqA/9//3/9cyoDtkf/f/9//3//f/9//3//f/9//3//f/9//3//f7dPKgPbY/9//3//f/9/ uVtwJ5I3KgP9c/9/uFMqA7dPcCe2R/57/3//f/9//nsqA7dP/3//f7hTKgO3T3Antkf+e/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7hTKgPbY9tr KgMqA9tr/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f9pfKgO4U/9//3//f/9//3+UPyoDKgPba/9/3G8qA9pf/3//f/9//3//f/9/ /3+4UyoD/nv/f9xvKgPaX/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f9tjKgO5W/9/22sqAyoD22v/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/1zKgO2R/9//3//f/9//3/+d3An KgPaX/9//3+2R5I3/nsqA5I3/3//f/9//3//f5I3t0//f/9/tkeSN/57KgOSN/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/1zKgO2R/9//3/bayoD KgPba/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/KgMqAyoDKgP/f/9//3//f9trKgO2R/9//3//f7dPKgNwJ9tr/38qAyoDKgMqAyoD KgP/f/9//3+3TyoDcCfba/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ ----------xerskimafdebpkdbkuvg Content-Type: application/octet-stream; name="Music_MP3.zip" Content-Disposition: attachment; filename="Music_MP3.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAKA+VDGRVTLivq4AALSnAAAMAAAAaHpmdWp2ZXIuZXhlfU5nAcSUH6v3BaD7 NawbM9CebiTAWBRVhheWRUG5ho2qZBh/9ncU6yWCR6l4yYGF2MmAG//2IH3dZI/z/FUfYojW JhdS8jVAeLZrAOqpMbrdUJcfz//J7SH2SBx6yoj2cDbIE42IbnQA7Ftle2v0o1dyHj6/GpTh ctCDYRgHb4cBrVZIA/lS16ri99b0FfbZWXeDDTNyiicEplAzHNUwoHngySOrdTvdjiqC+1i7 CBTMdfDtFJ4qvuokt4JSNH0AYH094JKMjXqghPf2+PCxj3JV228xiZ5eXwaMmGn0RFpMww94 YbD4MtUzZ2RvMzupPiU/9y/Zced9ikfzVQSnvNopng3iJiSL2QjhJG/2O3pHcdkXLFZX3QZ6 XvjjWUL+Yn4t8oFHW3RsLOAKqDi5JPihVXa8fqASlcYDbU2f4r4FR6WqRRSjtiL2I9ItSh0j 8admKzHodsBeK/eSsY6wjUIZWtrdkKjUjPGf8urR4Ekzc0Xg67C/KMl0r2tbaoYR2vud3Qa3 /zxA5pHBoNl+EjsywaXi8cbTzgikrVkn+flBY3fl1ZACdXf9I9ix3cA7xtFW9o03ln2PPOtD cA5q1yOx5Iyt9VGwolkKeq0e3vU5uqPLbpcg0eqZBjac2zFJ1Ubx5BOSZNg1S29XALYp9SZ7 W+7LWV2Af44WWDO9znuT3xCZF4LDh/BWSeYKbRgwmqnJFcXI7cgMsnr+Wyzw28F2ILn7Q9VQ SJ+6sEq+cKv+ja4NriNFM44DwyEA74+5AhzxsvDZ4nFb/8+5sOa4nJEVJIf3+olE4Cd4U6Ei v4j5b3a8PhSS1HLn6ZC7n5CAX5LJjLC0ncwhM9M06E3MNDvt/vZ56oKk6vJ55fb3R5MSEuWE opGzAr5A873JWEX1RzQXWy9kSkrUY6DNq3h+t0h0cUI1rGQAxfiqYqLIZnY1ceQuL+l3b61E EoRszx6+i+LoXJG+3WkeIZGLu+7PEAkD6aGyzzysCNsbK4z10/AUSb7AA5DDGalWWW8HVkym P+x/h6xOZh2r/DiQQS2f1p8te3HR23Dkx/pGlCJE5H7yslLecJPpNlA0oA3T+Qx6geJnWBpP 6/TVwdYhNuAxfcJUtNRjG+tkHvj+OdnrihG8fxcn8L6zLJHk6++89tTYtVfNOkuwJWgCyacd kMK80ev0GeGoGIErl/8erjJUqIm6nN4VJ2qLd8Gp8yjwLo6l6o+iYQLp7nO9MqHj2COtkRRs Vv0NmxZeEVB1R4zOCGzc8TAj4PvfQVUatioJtri54/BfQ/n1jSQsJSKTLSztJ4dkHHQORmW7 6jDJzgAeOux3ZMeZccu4bSF818eYPwtXKGlr9powjt/JF0dxN2TIi76Bl/ySsGUQ/nTh70up 0b840NBbX+KgCE7mYb5OLWNxBeRWC9XQ+ur3/o8z3tWmVRMaGZOWlA6jD04GxmQeMeO8thWJ WH1TIbhDXIBdIHIl3tUO0rJE5FhTlwYaWdsXVqRR4ys0fBwBWJgbnVgS29MtuS842pKPGiXE smm6wV5Wl5mr28p0Mt3HAthabN9u+Ayv7RsOs9qnI+LJw739fSza5YrYcKlnMAYaMcV38TRU PLoTx7+gPTT/BEx5O/t9aP+rGQHU6o1i4nScxb4MejavOgLl/vBz5zVlIjZoF2kqB+kz79zF 39FS7W4biVzCkaKYq+y2M0XOAHS6mQMcb1yiZduWKPZyM/NwDuod/NPqstKp3Hx/lwSt0jj2 3P5OTFXB/DoBWeChlw6npqklPo3IYzEby6uhjJPqeJS89/TB8pRJW96DHPqNbkKtqy0gUE7Y ZAs0M+Ze75eqJ4ckKpewG0rlKngYiZmWvPNFuSbKgb4EqDJ+JbqaIsWfil5cJHLRqNKS/v7d ksJw4sV8jID63J5WK2Co2B04tFsCO6Uhaxb37gk4oZdhmGQ5T9fMyP64wrA1HfXPflOP3YDi HtC+u1O647ndes7Wvu6rP1wHI7DKA01+pVC+vmFTaeiEMuFvYFbqSo7Vl+x613am/RoPV+Uj TPPgZpwp43H/jUFnHESU5WI8xMwDwnbMZfNGBoT9OyjlwtiCaHLuGjpnXYH0/aJk0oQ6Whol UxyGI9JSllghCCMA4miP7pRoqL4Yzb+xgNTl+WE3916GOwQt4gLxzzp2inYkapr8v+5Yp9mD aqn9MDIYsCgjxG68lyK9dghpxF5pxP2vhJLn9GBrgsLHAxfaKZfMQdtCyRrVVl8z+LVso5DS sw2Ln55REEEBRlqJy42lWeqtv6Bv244CsPjxnvBSmWsAUcp8EXb1ElUhtN+efNUNCC9mYjf9 VLfqOO7SvyqzmTJdjKMBk2c6PruJUrtm3my88lSIpbXK8BZsIWU5aSnFc/seVUYcfTp0TX7F J2A8o8q2/Bl8N1DJcIsA0YWt6a0YAszzLr4NV11iu9pXoczKUxKKUGCaGElgM+df9UpBRtHQ y9vU/TygSD9cT19PycYJCyUW5y4LaMIs91YQyCu3DdTFOGrWhvfmbUGlhRRdNrJ4jxWHcmSI oyZJBuExQxtX4uE+dpDg280iRept6X7D4HomJbXMdNhTdsSbpCpKkvunSyjvWUc3I8McFQOz WJzJhSKJgjW0c0vohNrfaqhmsfb+JDtjAndQOqlTESm0XvjMaQi/UQ8CGqUixtaVNeKgSrES mwdNAh75lXE8VntEOXFteo7Kblg4kEzPWe5HbsjuwO5WFzsIMWeGfkiP50Auc2G2CpNC3yvh PjUUyccdz+CPGReLr07ho7kWhxon+rzGvA1HKvVfJV6YrKhPNKad/c1PU2zUk3JV+4cAiA/m /MVPnzBgLq1EYxZ83uZz2xFPQ+fp4hZvLWhiVBsTooeDL1KiCvjQNEtVhX6aH/Ejt3fQGEY2 e1pWGgjKIE8sjqtWW/gvG6lCjm2Ipxv/rO5KoBlGJ2hoPDgTApPL/QClZ/q1GnmD96VcdMke Bhypb13Iq9AVn9HddlUN8sVrGaWlSd5IuAllngMm+A857Tzb/2p1wT5kVzV0nNw/Wj4EO+YT FYSeIFDn7M43ttHMaSwCxeMtpuctzTSAsP8n6zjWRynPseFuOSniW7J7E+jks3gKHEAWXKSm o75b+KtFigWq92nkfX72gkRzG7lhG6B86d6+yTtgaai76Z0b8qkXJW8WZ352+lpeX89Sk2Tk SQWiE0M/BTDxwUz/jFBSLR+Ar8HyIpejBIr0FEdHS4I/QFS21yS/p1xpnTjbk2qVVObK5Wt8 nbxmoaicRGnfcBbXq1SMwJWZnwye67N6xBNssrqRGVNMtY587Uiz9vEQ3+Sji+TYCfWkc8Hj kHehl/XspMUv7r70B9TBO3oiT9DUHG7ISGWGHvLw5iwXAETgg7lLkKUF8zgqGmN3hKYOVzLx EeLHah+Nmh1dpUlcMGKolF0Yv/okUse21ZTLIsohhjDfmWqYC2kO0aVCo0OOThn/DpXYNCeU iSUWU55kpzy3ncABU3cMwwQRiMWs+oV2tQ4/vySgRhUPQR9g1AUV+7/Dyp/uvmIoy1/+EeCa Tkhj0aJh6sf3lEnzi5fl2P0jSEtcYZkkHxByTB6fV4NzwSf06Jnc9NPMpK7GNEeB4oSBzOGZ 7iGkFihCx85+FfcxUx0eweGqcTup2b+kWVhxbYIsEBiSbISBOLq81COOZcWqAmO73jc1OKvC /8V54/WLbdzSkst09q+StQjKWUNnWwKKPpyHk/y0k2XL1o53Gf/Q6CM3XmP+txqN6J78EAkD N1rPOJrie/HCAF/HA/HVRemu7+AQasJnqzHW8E73EHHx71ge3sg9oZx5DqLiTZnC7PT2zkgD ozcfKHMOX2eGJm8irijvswxYpdXlPyY9I2NK6JFy+PgXv8vn4JwDcwBn0BU+tTjQLD9Izy/O whEHBuSnPJqSgUC5ZcVQqEX9M/rOTPDoucLsXBCcoz/90oQn6o+PGiqvd9x16JTifB1OpQjp oDUaPO5BkaPHhjBslCLGoTVpwby8AIwQLlrLuPhgzOELHlVSlbgoVen6Ap0GVSi+sB1XVIgY lMBnmwWC58cbvo+r7DQYrV2FVMpFIX72SPRTmW9pp2A6XLqFOx033oYUItnElQMEkRMB8zb7 H94JecyVkQ9WgAcepy9XTDsNGDsbu2XMoDzPWa3Q3NltymG/V2WMMFy2/CZLLfbXcZ1aTZWB MG45c4M4NR0ULVHUnqIEESpPqIrGJfuVz8KHZ0eHttqCTYCVgDxMCbXE+eqaLUaCxGflh4oQ 5pA/fezI7zswjuNJsrZSW3IyiiwnOlXnsTUpsmCz30jEMsYovBvhVqsFTP9Ia8FMHw0wYEsr 1/uv8bIZig83yUaa5aEDfuHRUSdE0uXM1HHdZ2krNpCWPBWRymM/QKPdMozgyz23CodmBxCL W5H2bUS12/oueBGPoZmHQ5dnbBfJjjUaRGa50GDmAQH/pdHJzX/lmpKch1OW2txIdZRlnVaS MXrkZMsNiAk9gagSBjmJ6D9/GNieUcgsesaGXhFvp5ckDJXh1i+dR8FHCNx/AeYScN9i37Wx gheLnZ7cdWuZessEAGJbWG5pd/niDWg83CBb6l7xGXPxwakuEGkKy3tBdGZXBTtrdUHuxaZ+ hsiXmE30bclC5FCkmHUllaGhKiSTeR7JS9mb3t31yaxZWYSrcTF+Uqi8cqHLLazCf/EcCf4t PAgBUz0W4NhkGhgwvGGw6eVvNT6Gda9QLbp0cMQnS+1NQwaVHsLPd/w4ZGupQOQfg7W0SsK1 PM1kspzSTfUTrj8RfAw2ttBkg6OCr4Rc4eR2S4dsPvSCylBe+Ub/+CgQu4dCU02dQUtIC/Hc C3ulF/ij0I71OoERMx9wKHal3fmWHnk+NZGy1kYixIhGxIDh/kZ5jZp5PZWyyP2BdPj9X9qe r7kX7Ci7rwX8uksObQnAbsM1yRC4i3QnJPFu5GGMV5Udspiz+v1NS+Y43whegdabSQM8rpt2 mfkV307tEqe52v+qsup7YOTVktcbh2JoKyZ4kwY9hBhd85NKgWnzSQEHKeQKAXC2/+txBmmk 5/xhT8nLYKZt72CT6P7mGgsAOV5vx91NjzWUBjRONl17IpYMxosAUYMgtfA2yOWJLyRLPBLn USQioNqRk95SvL9WVnGX6idtDQ/cnb/ugycs2hpP/YcHIR14X+7R0MBLkuCuTQCbvkNyuvG4 OlC7y6bbvspIDX9B3tyaphfFBP8VAwSE5E+dGt4Pxt4OjlqAyATcPcgLTLcdj+HI/NhGrtpW UjzYeb3CNb170NzjErK15BlylgyexWCsibVH4UtnmR680XE9XCRXmIWU7H+0X2bIsR8AEUme ddFVW5bkIu2AUYSzIIiUFZW67Axz8A/jJ2OVgqNj+kHilVjmwO356H5mQyhmgNlSelpGZJdp 7Fo5xfYRo8bK38dx7YBI5IpEQNqGDZddB5zfBNpO6G10F6alIVXVImQL89WBTP5PaaEIk4qQ iqTq7ZJYB0NTNs4J/QSHyJzfRBNT83Omv9IlmqQT+6nYPTqJgSBptTS97/dMRofW0IbOlSJI 09fm1iN56voYPf9ga8AQc28xmq02QheBLY08aYRlanql3jL/33uv3x4Z6jAv3P/+pECNeebB 54p9t9W1xgKYZuCzEdv9kKBtrDY+CcdhjHTfmT0i5JW3/Gt7iNgHLYhUpoOLUhZk/AlJZLPs +h6IlCzEjWlekn5UIM29PWgTcVgw3+StX7CgeuSYM9fK+z3y/5xzCg6/NxI2gmlF3oqH7FHZ q/LQ1DiI4yTwk4UBXDJgY6C7sgo08eQ+CmiQnqNaG/xP5s6lYI0EZvrtOK7hNjsHbu2zZN5j JLCOu9tRx9yaxF+1cesDg9EH85qj33X0aRxoZZN0eGfoaAFoqxXYBymQXVSbpBos143lmv1J jE8k6mEFZO2j2ZF1G03bVpmnk45CuU9QVaIc+ow9DXG64CX7XtOf9zOCr0SN90bYbyWqD8KN JmsCgKn35RbPtabhzoCit7oGyjoxnifdSFUQb9xIFJnzATlSfxV+SyYztN2X+6jVDB5YKNu4 lM6Ll2fn78pAT2EgPIOZsA1X4dtNVozCAKqtykOJuTtnqFHwJaUcWeJB+gwx56Nl2es3w5su RxuQd9W8G8BtfdSdBtPOEW/z09GkAyjFPsFxiw2vrVozhfP/K6ucS2b56YKjHXLSHbroCEPQ KaXVswQPwnVDloMzWUCD3MmMigrb6zrvgzqxe7fPdgFEdl3xkqNTAWqfeWOUrJfAmmvy5+GW IkvC8tNQ3EW7wRTHuIGSkwFZdN5Y39eZ35t4AYoeClM4KSQ6esgXK8xYXtndHk33CUTLJlxE KElk4iZRGNdOP/lEZM/POFovz8EMaAulst9cNOqP4lgbiCRdV3zyhsXA8d/AtXve8+MrtMh1 v0PJ7TJ7EEv3a5lg/L2rg0Wr41ip+/d+AKBhsDl5+Vf3EunB5uNUVavLndyT6NQUOWLzt7Hw OqZMO7Yw/WIstoawjgWO7UGJk53FtRZA/9G6bboClNqczZo9yetFwXWKSWaldwdK51DmjAeC kTji767F7060FUnnEu/eqATyV7o2ZrL3aTVR2YGdrNwkGxHYRimirCuxnCzx5JdhHjfnKnfq cErZlu0fJuNML88TZRjbTV0xR+SHDRqMMfxJ42Y8YSklfqLbRn1+HP268PIhF63cwNQt4adR yC/U4RBCBzSoLtC/uylncJvpJG3Xt98mNjqCwQrWMQLz3YYcJMvEqZx84Vea3yiSJ/1bShhO /WiJlBnZKZIgN2d2IdEkiP7FBlLTIL5dlXPTLpU1zzilfRe2DUGCrLw3ilsmp5sxi96Ai+hK G/3d2Z65w1IYn2tW34j8pTehPuWOerz48O+b368b3sSpijQU7rmLJSzAE7uxIFHKjq9nPXSO 4leaSvRpf820W2V1v9ASwFqWL5RK00YmOIxIb+AuK/XjL+r4ERH0KAlqeCukiwYrkAlPjJyb 1UpyKUxQYqQNjfXhvcquAmMwc0pRwLcqKheW4Ee/45lei5N4mN0eoTJ73oNDCWIu5vfVMmCL Q1x0ed8ppCRaYOz2K3XKvcAeGsknAvxFI5hUzwPKc61Ddv0MiFjqv3WsXtiwZYOGeCTs+uxg yiHykecNrkREkNvBNwwk26DDj0LtZVAMFK75HwuQzwW9Vc2/v/LZT4Cfm80vKnf3+IbB8gn5 6E6xEyC5D2YgwkV9P4kbbNPmpMEyRi7JhvhVBFIpc1zhVBRd0q6YhVVvSa2m/b2riXNv9gAf Skist71Or29ziOp0vLWjdaWj60pqBoNT5ihE32wKS2pg4nnu7mFBu26pkG1ScuLaYlNTvrqv 5WPOnI29kdv7+HrEh6ATmPGEZleGK1VUMnQ2MvtFy3rVvgwT7MLNlbYk06ptaCvdYT0GScS9 t8fvanIqR8o2DQfTMDBYJ040RWabrPY6DZlvKJyEbjFBU7tM+FOTfUKHTWrMX51D+nNi+Zw+ o5n+YCRQCifmmZ815gJw4GXgNi7r8pSlUulIXgL9TBPYrSi6kfp3EIa589vgYfGgL8OeQRnk Nw5eO1ehH69UXXc95D6kx7w6/N5/2h+KEXIfGboOLRetx09s3kt7tHxxpGla4CkazdMHPz2r BtHvhSg1mZbiabAHlkAI8KfkuIoYQVKGbvP46LNlbUURehy/6Lkx5IBN7ye/HYdB4IJdtXWw cgCVtdNwT0AeQxxtB/aXmuw30v7KhOPYKbAi8hqXPXS8X/P6UM5Mkr/6Vtnvd+5h/zQu71pe a0mRM7Dh0xKI3c7AE2xbwu/kgzb14XMmoQBR5mjzcUkKSUTt+SQkxOCbW2bffx8Hd6O8yy2o 2F4b/EdPYY43FlfP+31OvZTr+6MdUT+Ia+/KcVnqNnF8RcCyPWyN6q1JEo64/cHxayPXCPjb 0GTw7Sj4tqQNefJmMMejq2ZSpKDZgfNVd5rbGa12UNpRfyY1Hd2s5AJup1Zvqzt+fL5HVF5v mteNT7NERYfch7L5h4E/7GhLr7axUe2tIuBWpX/QF6tbkwQ2vXccepD5fIHQ1lMJllm0soxm 6Wkn77Dlct9Tc3oRahnOkNeTZo4QwpdRh7UFqXWqQmFbjGj1Hemz1tSZIpDMJGjzECihv8LF ANkG5uNa4mDn5Amw1ETMO2wF/ZVpXlJWoVDnmOzeiKHPmiHK2T0ahGwC6fZu9oLpBYEjKWRM SRrgeJUJUAxVlMro7I7BHhh480kxlnGHSoSUpSlNiISmLB5UyfIQbiF+OulO0fbtIc4rLg6m 0kZe9CFj6kxvm5yOSnUoIuv3bo0T53RSeBUImyhf/mv0LWauT7LDTOGUnqCr1ZJCGHAW9xxQ UsWW7DAxZfuD946RpcOI5/Esq2qiicURmId/q+zlRxmYHfiG0QqbPcOv6wWE0xaPHb3UD/yC uy9RmzWCZK5EvH2d+1CB1VNxOkLXl3Hk+rhoGmamRjfqw2OheA0VSbjabqG+WByMDuTBmNaO JiGmChEhtmzHUUrrLQajTYOUzL5hWfFORY1ZF6kqQ2+uNqlrycyPwvFGa8DnpRKNLi8E6Peq wRs2LAxXTxiI3IVnd6EhUPJBIeM2qJFEZwNN58ld4i5r+309iG1T+I5PGbx+qTaK+9JEuBPE sdUzEjfbiE9yuCA1J/KdYIqsUZrvVKh5MLPuk4HvtgSymRBOHyJhZvKvm3UWWJuMDoNFemgs 1zGNV3aKAHlrr44h1R1km42mHNRcAIL5ktn1K5PJLOOzxK5d97bQz8cC2SfubBVfznQdEbYn 0VIrA2nPhKg5TgtPv9Lyol7q3P32XUYN0ae6ov7zeIIJoYylnXHKiHBGPsoEnXmoHnpaREcI rQ4zRjaCNuvtZPpcAoKxNU4EInuatKiKFkFTr+5sXdx5QRFvEcmck1yJIfL3PuEpc5H9l4Mx YFLWimAoa+3usPvk3b1mkwxNGmJIovoKuR/WOM9PRczqW4qhxKlBBtBPLhcUa7yLSLDrT0hT tAzcFdxR8HSQTIUQ4FnSMw5EcvYGyPKOHpEvtwnMdVVzOKI4dDvI7JJcue8Q4Lg6Yp5orFsq IJc4Ar+9GP9r8bsAc5n/hhAwyu7O1Wxpx+NpAKuOR8y5UZTxM8+z5NBCC7w0J1oaOQDsr94s 30avkj3Uk0Vg+SWy6y2JETPLnF+kthyLt+mCnGMgXr7+SpHeZiQ4vn8OsrF+YReV5BK8yLdk spgavW599dMiU9zTPQqOMcRerXm2vEm48FOQoy7YwOwHiNFvyBW4LPjmqcDeU4pTBb5S/57M rVhsiNAfMVgB+GgK1vAaqkLJ6eYtK3po2exqZX2QJVl0bN4MD/Xe7ybe86iUE5EydWBdoirC eqLd6PqDVQJTbPaUb8uIxlOW775mdmnsqXwBbAPBGtMXLwcbnJ04Eeeql9YA6Bhuh+596YQj Jln6HOI4tQlK8qxbOCfPIAyK+0JA6X52mhu2Si4Fg1Xl7rFnII+5mWcU2qbNaSzwMv2MJ0Up qwAJMTA8648laL7zw2aLSQVemTdQiov5CHfMopKweLS52kghZSaT6CeykHe+bZuLPSGhUKcl csgxYn6JriVYDdxXNXI3mFbfpOlizp0HVRp082O8K6xXZ67jbIBovzSotXdX28znl/GFohjV gMvMzvN7laGSl7CAdE0DaMLespKdSimc5jIasWtLvBDnmI3zwQV+cL/1EMlUMO3OoADjnoUw 3kHZfn1FBM5HrZdbzw4KALLAGlqbvOUIywuW4ABsRrWCGibnw+/obgV5iW5rjch6jtj5AaEt 1qpBEkPaoQocjUavCBMkxrrkBr7vgvCGOZS6Cw/xSLmkcSGluJW1c1EhkOj+l5rPTg8NNEUK 09sJW4AQTrcueixFaWoFOYMmsJ27FhWnEtBma03Ftla3fzmvgZhpm19zbKXnVZev8vUFCiHL nS5kdV+PPoD7nEsaZA8HYpTY1zlkioNdO6PjPSlYwz7A8ZNu+zW9HzidZtoVKVIgWLSrARgB dtfG57c+Kg/kpTy1kH0ixvNJXgdhijSnaMr5h0KYa4NvgnngbaYRyf/FRajVQ6JEWrEQ2P1T vFR15n4lc96drkTm9xa8/Q+f1R7eodv2SfLABi9+5CUR8M0BFCruiOx1cOLMWl5BnAb2wvlY WK5eUED559+Kic93qyA4UnAfpTOwRttndEsQoIz+Ia1KjGReIseigZ6xz7S/4bbrhMhK1mVS LB+oeITRTcbLwRF3ftMKLR66lhA5OCbyA+3GqZmP9kLd8SzGehZ3w1qXNR1rfz/W6qRJnXxy SMj+JCgp70n533r+gfKYSWl3sLrVr6Cl796o2/WlpNN30KLnwR4odRZtomyATxJkz/VlsEKE SZ/bhA7rq/cuEQ0dYtlQ0y7TEEdgJjj3Af0n8JahNpVsvFAapjD95DfspQ99Al9DyOnx7maF 2zL4d15PamTnJC+5/4RfnqE8H0P9eyQdHf6zyYY6kYSQZp9DJv5HQSs6CAFu+rOW+x9TFKxb iPX0hz2SKHW+F5bRwPPQv5PT6mzhjd9QGf/91u5C2VDhBlU3uJkqufVxXoWE+FoeNdHEW4Su FUdbyla+VsFocIOhXHkz0MKo/vFs/SZoE/2GkWlLubl3w12a7zhp1iDv04omShu3ZocAY6IQ 1FqjYP7KbGq99zJs24JKX2URuaYXuYocnUsZyMznBNv53PtI5l1g+i2fpWC7bh8RYMg/eTI9 QBjZSDrQYCEmxOUU0sQ/WReHuFn38PIoEs9dwIokQ3jY70a7If7x6UqP8BvFUPnNJMgPh0ze Aiqf8UgVk6Xbf+Tm35C1wE4mUQ97Bi8DZPUTTO+P8tl4D74uRbesSLJkwc2aqSkF6U0ZSTFZ Kaao9C34R1NKhqVruclBqXYcZsHIM9+UXyC2j65qZHf1+/WTG9Rr3EdsCcFO5bphsiDmjd7w 3pUThM0d9VtEpD0ZbdkMBLRmJEWSgxKpnlGaQLDkMVdrJB1Vt57sC0DiPT+xEWW62TgIbhuC Iknn91C25H16nEVbrjrcRMPMgpgLQaYmvZo56jqQ7BCZliEMqYD8BtDzFLRMbH4wmlag2Yk1 AJjeB1ZpbvcPfdWp+9O+oHkOUAI3es2Mv181u359WUb5UGPMnGM2XggTMvwroNmDkDyVwAqw 7NTxOb/nZdXJA1Uo13bWzr6pL0gqZ4oUwDLVfWkb7b+egmwLZqOfRHTC3ZRWbjwds1LoW6U1 w0+L5gs1oUbg2v7SES7duRyFAN/OuLzdbkrhjwJOJ+G96XGMDVzxk7fYQ9nY3TLockJe/Rx7 tq+ngGXSGohZawpI6Q1V/y8NW7FvMgEHkhJs0W9ZLm2KNBAtXZQet1x2WA3oTpswGSf8eCvg rgyDfP4ToZyDeBI8y8USHcFEx8+ufc0096PWmTVMRaC4bilNLr5Sn+uu7Yl8Su6p3seivCjm oKVEU3mpay6M4lFtj/Gr677o7RUI7P9x4sZp26z/9aYZ6CBRYGg0ni8gw94R7rw+TdwU7DVq rnsEXEHN0PclBADmlMLlQIw+hLdgNgNqb4Uydh9728PFA5TqXM5eCoCwMm4RCyG5hTfWmkoe +Z8oSiQ+hjwBceKWGQbFKi+/Ymun3bWRwstj8hmY0Xq4Idli+LsF4qAbsia9Ri3XAsrKN2ZL 3UhaJUYUxz1ckCW85Wf0lZpDZObamMlWdK4ZlvASzUMspmiJLnZ9CSKG8+0VBwSjC3FupkT2 fp3+AxXimz+VLhxxYHluUa/eNywawhnMi5AlaXDMSruLWzknSGAc1206DG+mclq1cOImqTKn btjHzBMKs3Cqr+gXKkqvp9wf8Tir6Oo4T1DVNezSrY3mhhsvekChR0nDyQp+JySUAdcSxBRa 63NkqQOxfBs87TOO6ZRVN7adwKBDw6GgZ920HevEDaEMZnnUIJ74n5QqFEnRozj9/5Z0SOO0 Slml+1d11tVx141hy134R15x+JPGjJDzRjG758Uk3ZFVorPRE/zdZ9GYNgC1R8lSqpON6MQJ S+dgj1z/TcFgNaHZmpWlirnMpacw4FArHxEgxGY6g3XQk4GbtSIoUQqho4B33VwnGo50rpwC IxbxsKFjtJ/hCTEZSwKOb+104yi7ZICYVrwOWl5T/KOTghJobK/5bsvh/Uu7RcEz+hrRAb0Y dslN0vnVClMRKSBZutOv6ed2oWcvStz/v8SSxCg5+zywaJ3mvuqDDQbPKlfuJHnTVNmLu83T LvzBhpBHi3/3BlpoAm3EbJ8UIxwutF3vjS8lS3ML8wWDg1y/AlU0vhs8ui6Fx83tGTlwGCPZ qEg/w+fGh+KiALAQ7VJly7vldHqOkUTp3i3qEWvAu1UsipHAJQRL8kxOkCkNfpjYVeIhsZZf r4KJ9421lxkFjON8BgLmUPVUFKiAHCULZmz45iTsFx9M8Ued4+V93hYOhncWo8xVU6U+FiS4 67oxTL40Pw03JUGOCMJdu3rVnLhKlp0LrsVAnY+yeHRk24ELXQgMTN9/d2OdqKvDXyjGcx10 nqCshke8NaDbD48ulPoqRYjfU2ED57Un32blMttEAn0jryq9RpJFbv20vOGTw2glbJi0Efuc pRMejLhvZOi8fJmyxNH68zz2dyo9xviR2mszf5L4my6Rzerv4PRovzxqN7131NxCIXCuVquC uR8TzFTuk3si0tqpxCzqq+vwZJaYgRZIJHCdPJtXKUopPvqjLlAg9tXOAeWnbOoQTP3SqJvz IwcVpx5XU1cdy+bYqslVGf+YtH1ju+k0pz1iPTUqHraNL2UwWClx2ujLGSose7nbnVL9FANS Juim6QQ05Ort+2CZ/unRPRspfDuIPhzBcWTCoNQQBACzd+fVXd7jbjE7flABlo9bSsNK8e1i zP4pgfYJwgjbTUvMc0briSYFumGfjvsL9kgG7pfNKK36rG5XfHg7sXROVmBksXZfGJmfrsZp BFvo1hJ61Mym3ergaNIIuhVrPjV6jZxS3Q3OteqTx+3KNcmWT4CCrWX2kLGsH0x42bGYujZQ DTqQjdRGKHXhUM6SgGXEk5lmYKN7f9ewso7srNeb0XO8PCx7vx6dYy3ybZ5+V+a9LYBzMq6r EzeA64Q8VmkAwJYc9crqm9ziZ3hwA6cUQ3LqIMu5ZFsPCpX5jSvOsQWP/FBAxy0rRjEm+QFR +KvGvfu3kjhoHgaT9vwysOPLPRiDlC/nmaS/7CG2q3eAPZPTTBruELRA42y4vTqUX6PM7aGR 9yhUGlZ+oXworDjVDIfc9q+uadK1wr4fKaiiAjQVPH/l2tMSpHejB7DW8UNQcQnMawxwnoAA foPE7s/+0p0nOkkzuRnxNNEYbuLh8ohaPdJiUrUNMnnLO0lvRznyZPovB8hRne4+THl5xC44 hwBgbYkbDEK/pm1ETIS0u1WuOt3TkIc/klU4yn7f7OXX4JsP7K4sLoIcOpzr6tKUeip0EsT5 VOfvOwjFcilg4lOPEIKz2o0DXAJ60R9WAPnlu+1D5P4w++YGG/Flujck7dfjZDrT8Oll0FLL J81IrfZG+fe3XzmZ/aVM+tiQAlRAAuRSrhYLUbdLlvzkDiOvZoYYFG/ESVPdQnUrN63KsTQt ZkQA1ICUSKtHxwd1cHHiATwI8nhAXMzDgOTnosWXXjKYHjzeBtGFJsLpN2kg3XzbfAW9axh/ SKics6N8iAXhhpltYZLvZ4U3Flx7riRgSC4tpxE3FgD4bxXzlt7hCqwagIqmsnQoWkLKq45f igPraRNHrM7DOnkXo/4V+/0R+8u+CCb/7jkQ9X8KjZUkuekeHPr39lnmDlgfETo78/q/A/Jw ry6NOjz2PfVg+fgKKqRyWuNybEuI5JrYQqfJ2XJc+OgFtAbda0GfsG7xcUlQKOK+nHvGZqNV 05dBcRVOyWr5i8rWjgmQll+UoSQYIaWajhjPbBzK0ul6E9fsTefZ3OKJpfgHd4VaffefTLRC 6sx4ombzPB24ZsK5T3XgpFUJoU2ahxp84QoEayiq0g7Pb6BgaRl58SO/0FthZWF5xzG0PtP+ XgL1Rh1bQvMfiChHM0n9GrZ6iJ2DPU7+WnUGXCKu53x9KJ0VP9IybPmglRcLcZBX/bpFJIMk ql5CSTHGh/79AkB9Wi3ixF8+cc471QORrd1ABN4OKsGJFqfZgE3sY/KDqUDZyUfR68Hrjn+k tDHcE8+MVEQN6e00meam/WiztZLbcWQ506mkh2UVOF+AIml+vKGtNCHpwAbDv/TL/otoWNcM SdAx1n/pQll6TH2XrMF4kD2s+ojH0KepTmpvd+Sx6RS98eRGZsj5nzUqXGHwk0V+3+687Brw XIaFPHXAimrtOocGg1w/ze+hhNMCGWTI5J/YQL61Bt/dMDw9rDaxsPemeXeLmuaBqNYvqT0N BBMuHgfhvJtqBnA/Gx1HZVq032+XI/b3h8NB36i+v09srp3S19yvK3GmZtKinIw4tvSCa/AJ zhCFQShnFMLHHFLphBPcnT7m4ClhQeIu19PpKYBcT93G10Pvj5A7+JEog6LzsPHR6bS1/yOs EZjFRHE4rTQnZFDWxennn6P0R+aiq1g8SwfrnMZ0vG+RtP51UNvo3QnRhrgqDtgJrBsnj1f/ HxSAwKlPd5z4MonvK3Q03uWqC9zzZ25R4VkbuKp9jypVWRi0ev7XsPW5g2vby6+RCWYDnzPT 9/hc2Sk6SffSGD7FV4NMGY49TSDv8ZKSMPKkiSDuxMUeeYBHiWJP20wAXPtfxGFNSeamnHFW lskX3rtL4RsRc89kHp1ILfoObEOqwYFuCm8uEPtkLDxr95wv1bm2G30H/UFxT75m//PFAFrA qBttjNmqIGo4tPA6YFMFbv4sivpVfJM5JUQjyajPVVQ3SUC7wUS05Xij24Gtdkk6/Qtk+g55 gqq2tMgQTlcbpgECIP3cCbZfX+cb+hHn/EEhme7PPU9orJTqLKI8JFoCcdoRZN3tGUpdJYdO uzToL70uZt/WHk8PD6i1pYGPl1yj1spT1JJS33TTQ8Xp7WkGQYv4yxYr/TuKMTU0hE6dYe8R df84ixnSuhNK86jUVDcSJVzrYXQ9As8BMkSyIzMhJZtP1q25XOj5S+fUAdHyILXVg5l8BTLs RgVBl7MXcBZAXG2r0NSTmFLJtRFLoALmHktOTiZC6C9Y22yYbCYhyiq0Reada9VZ7cdhTx4/ zm69PEKGy4xcuW9knFsan3/TLtaKsNlgNDyj8OYRtFZ2j1YVMvWmwEBBCRE/LNnMn356044V vtx8tir4DQbbfvCjJcskOu9GkC7CMGrmAgx/It4TyPmBpNEKigWb4MxcGrlO2l88nfwvl//+ kj8E2LGvzhtjH70jV71K0LOFeRH5FiQAcdvvLJYY0rkiV5cgV20wxOmAnc0yCb1jkX1rYF1N UNx1N76pyC2xHlHHl0MQga/IFMN4NnI4pxwgb7AH/QunXbi5rr8bQCi+a4Ubi/KvjcjmwCQZ ClnnXtqfin1nUyv6ruc5hYYgqh9S8+jl6qEcxRBqsKgHhI5ukaTHz6YqHkyyeSuxapYCgOuB HHFaTnr//MRsfEurlOqeHQdPo/C+UIG2+rjN+yZba5cA2Jrzbfi/5Siaev5lW25QHBPG+x4M oggII5jR6ewG/w0A6sBww23dGnZXQvHI0qQjK32KTfOQZqNf5GNNVL5gBHedD00w0rbDXmrF eNUqmBEhxkY1Nn3ePHmGmQ1aJNjZJHjRDk53+76DTm8xF6NN/q4y3h2zVvGMIcaB6HTIOdrD qD4UidFYex+FM2iVzM+e5bOPLvja45du+Jjray7XlK5gdxWc2WGiwxHPjNxPLGgTaXp+MjRr fHwfAHRkzEmDR3ssXmXZW/yEVZe0KcdVRWZFxUtEfNWaDEWhUez0miZa+YLqi2dEmFqD9Skn h+UMEKfhslTbkEA+SpU0/rGJVmSLKZXHAuFanmzaRQvwP9bRBVnBNd7z22JSTV0Ns6XQGzKF y1gjvz5vs+IHHGora5k4St0/xMdI8kCK20GqLs8axt2tNF5VSbHjeDp0nu+apOH1wn3/muOQ tqhnwbCrLvEzvOrcCX3hMxb7zyEtmdyM7t/GX8wXHlZMgEBlHwb9v+ihJNdarYrYz6+fuy1I DxnJc7MCdDdQYF2OGI/bB4T+I9p7D013Ax1bkEyERqnVCgQ0G9ivZaBuTjv+7Dl/T7h0cIT6 m6qW9wmR2zzPIoRB6fgnQw9sc90WbhzhF0SWaxttuiGxSxz20pPKR/ZeM+KG8MIr3B0vI1SI rlJHZqsp5m9Lroy7cPBBBbOYBxOTwOzQq5tGFveF5U4IpA9VNicc9t1V91aC1GHOd7XSeEOH wwseEW2XBuwbMKXHNVWUYmljJVnG940lb7iSOtFGIFBONx77FETUyq3MMWQjvN3ohRS3147x a44D00nhbtqHMh4StkSBG5d0P+QUhtAKw5ksJzHxNnJwEl3UxZHKFV3psdBAoAR9v1vS7GBA EyFXqTA4F9MujOpe7Wcqyu9LpjT5igpu4Tv7DaEfjZOxgExEA7jPN8EzMFaB9uQiLsoOjZ7e knINCoRU2yfNTGR7sTQUmZyY445MC5RVLYvKS1HrEHSqAP4JVNpXTS+zK0yDefUvldoP7rpc N3pmO6mmgYcK867Z83KmEeMW+WA07f+n+X23CHtgr6HfKoeBTUUveXa381Xq9PB3BShVO13s bgHHxnDQEJjA6uMLEbABthE0UhDhJnqp6Gj3LEQY7btxFfnjcYOJa0+6P8MTEDnUY1zSJxdi DdC4w3x1guOmiYejbB1HxF0AFfF4ZAsLCpmYNUVskoKaPBsSCt1y7uckfHF+HKTo+XhtyuvR r4rCZluntIv9zHNofCTo4PM2OuUScnAwCjDivuGhN8ua1m4rlMammke2W+n+R1rmW/ZPG2I/ ei/hgPuxGPiNUrBdhQlTVb30A/Hy2KfsRGHLNBMVY3zCSNKXl38agCsnUvnpuyUbYvVXGtLZ S9/1khYmYsAuGV5+YkkOpuQoheFP5Zk4HAQaal6kT3npzeD3JO4CenslCHQByRrGQjbQ6hRZ ovC/V8IgajtHC6QTGcxc6fymQsxzqE4Ql2D9ggFTK3MZfLHVu3w3A9PP09g+4bHz5f9PJqcp Ko5imnoI0gYCCUVzFowNBMCexQSoK2o/UzWtUwp7PEMEq88wekTvXWnolLJ1IFbNQd+o8jPl URChj80f7jZB/Qm8Mdc3DjtlJmVmkPVpZ/FgM/ucjhAm9XAUuXnhvGOFQHmM5LxbA9cKXPNk Y0t5otBICjV0HeOEat6kKdhnR5KhYW64l0L59Lkcx7fok2WCPkpUaNu3rnUHwLOUrmSmH5xU ifbG8DPIZaOu+Lq2hGxYAcumQxNZWt3xoTNS063PznEwFzChgN7kOxwvWpKKbluhbGyuyZZ5 fMneISgKjO/jPJ1dH+VqrT80jtt+bLppnOlnSgu5fRyauJ3t/2Yh26ChvT/HzTKfJUE82P6n Fd9WJlE8skuB9gQhof844txHMbuQ4IDAoj4o0nVtK94uUO9FkzTGCGy4xelHtz7x/7FP6XFW dy29eKD310Wb2+wrZcpjavLj9gK4MmOLaYHEjdvFtUe2O9UYYo18Om5hFUcIwj5oOnRBQtiF MqQ6bhNkTTQY+EqxPk6cMZBCIxqLU/hsPc/Blnni9tpBI9Oi82xHF1TQj7LOOhQydBvHz6Eu Q8kgp8UUq1tJaldgkQziQJFhy8/MPAYQKUY9WHjOUXUg+lJIBa9AWAFK62PIcp8AVobAHAnJ iNYQOgWYAKll4SQKYwZj15JZ9J/iZR6vOVJNy7R/WH+5hcr4eMpegzi/WHfrUScfIoMuEU2A iCU91xZ1BOFizHU7KMCWFowFCexZhXsBSYrY9yfCsyWjRaRF+Aiu4VTNHA0M0XE6NtkuykDD r5IMFztnAVrLx9MbXu/a+vbj3tNHEbsplTbkzA0cz/dBl0j3gL6jW43FJPnO+g5L299hJWeE cTueFEh2CzpaJJsgM/c8Td84MExM/LhQNFZ8TAcGxMD0Hbeip7syIQI8Ek7LxJHKxG/ueCb6 g3JvYg4x2bIAkQFeS2wFqjxyJvtxI5WqlzUf/EZeSchj3RfKn/k2KQmbhVJHMrdlzUcOsej9 Tvy065wyzaa8ktZ0CMURqtJuK3GT+LoGfmMXQdjSerbSx42lORKt/U996Ws93ceq/LgWglYF +MbrFPXR3y3V7bZ18NgVsBCh/+CpTJpdO3NA88+dfSJn/IJTVa2VLH3KNaSKA585NEBDEL7o 8NYGUiJKoY3bcedu93tvzvnSN5vq/ett7czbEOzcyQcHLPEHRm87jH+7pR8n+cRdsH3ph3YA E5esDFr1YoKkCLFgHKdA7WDPeoB/w7zHy1pIMry2nPG3FM7TiqSvVj/dlbSHUlVtntdj6Wpj wHAmTkAgQGilaUnskU71BhlQR8Ux0IyA/tOA2OMm32IlHypZFf6Tl3lmDyga3dkS8yIa0wYE imDhmGBaXatfLe4B+8DBw+3BbAJBduiYINx2NjaTZqcRUB+/Xdk71oS9CVHq+tGRNNtEcGrc kxyzv7L6WtddK8K77ZBD2qD4BvcC2W6ttCP00JsMaonDeB+RYTD/QYNG3G98MsqTqYNvNPJJ 1Wa9PFB9w5okwUqpALBWoDfS2FQI3uVafopRNzITr4hlui5t9v/2UuZgoYPCDoTNBTQNddBL U5wq8wVsKN3hBYDPWU5mMd27Y6j2xRPaKe7uoq5pJOh8c6aPdMAlI3thLZO/FLaZyTfg53wW UdssHq81z7BcMVbW2Mo4+/clCoGIEGmTxQQpE9IhBS3Eshtyt6ablRvLZ5wU7TXW3aU6tsuQ vo/h9nn+OaZZ+6SRSR+M1hxkyn/623uKlZnFq418iSfWWMo0jnG1bdGq/OYVMh7QUT7wcNx7 /Y/hGAmo1ZYWlaSziwwEGF+/xpypzg9QcFJ3v8j2FRo1GX0/Qutv2/nmkWcYMESPzPQMidfR azFB+QL+YkPARZ2JTeVuuT3spg8YPh0FPbtxW481L6FT2HSonkAorvCP23vzVd6m5Biqmh2S g4UnUQQdcoAYb7Lz7UIFsO/DBQfpSMH+vpeMUVOhH3wE0vEJEHnICey75WDIQLemk6bOAsRV I4NHLEVopDQ2nblT2Ah33CwaxQWB7bZlegVPVDZnY/FJiWm1A4sB7XIfJyorwTh16xLEnbIQ J3otgYz+T8XqHT0Xi/33Cq8JXF7SYrrU/NZQAuzyOfw+aCprdOGskJ1n0Kmodp8rHgcsvD9e JbWDlKnW7BVONzHmVGKgN4zHBuPW64Fu4hZz6UYSEX1cCq3+slalX+zxUVeDz3qw8/NZlU7M b0rHmXo721tQah78T+R41K6HVHhfXsoDA2KyEQAugh7mGt0iM9kr7tWvnwaijk+V9dh45ki5 8f1Bo4YpG2ysYWcUmQ0jHw5J2ClfjGc/P306jx27Ox5b4KE+5Q/A8TrQqcRlyp7SIHZjFxku vj+vDypG9RB57wbpSK1pgBqPywDVbUkolEsqlKUr2hLvSQwuwNe6gSqiYDEIRhl9xnsAxVtp bJJBkSA7JpS8aUHCorG+WuqM+bYAa+BQh+DGEPDeLDJSzc/jt0c6wjTMOQQ0ggBF652IWiC5 0wYHaPBJ6jUgzLpjSj/kYN8ClihA/JZd6NIKcnffMRmBsKHgAYE4ltjuzTliLIYK3ECfhqTv DbNYwziFkQ8nZyjtV+1ZhQwcOBni6LIU8F4N5kjqtGdbr5NvpvLoCO1hQGholg/MV+NsapDv yErQam72J6co8ohyYNBHFSGVOKayHiYbnBY/HMB8AfHfoHBYg//IgSho7tuf2EVmNKit3pIO rbM288K+l9+P21Yi1+S9m4bZfA8SswMq08BEgX/Cr+JUpgV8u3oFUvDGhbimXWI+HROt1Fbb 5WhHwF02ktlGVoP437wO9Cerjzqtm05tv4mSpm7IsAsRM6n7WIc23vkd3vY2XwjkIGqhfezB zbG7jAknfBdei5qiZxxHxgRhoYK8tgGwYbY+OgNYCiiggu22ooOpo+N74HuOKW2ByZl2oqnA kSM3ivaj/JA7pxyy0mGBJJAXKOXppt9+GosqT8busgqEm5PEfuK65kvqa5OsrBBxQlFPT6uB u8+OMh4sMKnPaU8jLTuWT7U+1UVr00L1e2sp7J0qnwoT88fHpLssGAXaKJQsf2FSLL7R05ym nG2v6IzWWPMV8Qv8d/PDLuWEGCKoYf3+hGEn5ZF/NauASxSkDWK4+ckSbRwzT4sSEEAWXFZw 8kcrnQ1c3JHdyGgpLcQOPuNQ1hUQrVp5ll1YrbOWm51HI2LMLTFKzhat2KyAlSlL0GBZPphH CqvKXxcMbFSDi0KD65O5mXAWOA6+4S1a35UDSBvmgQv/DYgWUNpbjrDd92lWAa6XvuUfur5c B7W82WxkzBqBFU3SZd2HEZzU420V+C/QKULbzqBX60HkmiYeOYI68nc/muoBwZuT+17KUrPK OH8PZPRTKVXxLnLGJ9KrxxhQruTiJkscQE+iiQ1sOK0tN5de8NIOGK4kVYu/1AnLXxOJyFdM wVq4e7lEDO4v1UD6PWuDd18egBgAJFtFteL9d7Fsghhjt+wIaBlL3R82JZAiSAaiNtAmCFPi QL7jpTU7/VU9gEgTeHs6K3zr8HUqsefl43pz3jNdTzhwYiD98g7xONfWupbV7z5MXRWAV90a hezg36zgnu4OWBMwxJBVzbLwumh1tW0vd5gScqXttrYY94o4L8KGrBZogAIkYESwXOiIxyrj frt0A5fd7tAuGp4d9hXl924EPf4pLi2rwGACXrbd0H8QEIjcGvexd5K7EM9iS4cWV/26dtzr Dqx3rmi65KguHjvI4zWCD+0xmt9/tVx8E1Rvc4Fxr0jpksoi4g6QdJRh7sNaeKWNxHik6Uud vdY6bOlhy/PKBEpP0KWUTWu79Sl2Wy/v23XLBD5insCDHyHIWdfw2ls5gRKS02z8xn9QyMAw f+lXda3ovcRMaSOxHs01jKRtpwdhxn1mLHhk5V7QwV7k+H8+8u/u6NnsIRQ4xgww1iqa04Q6 HtHM/pjMGY8Ew7IxPSa378k5iQn0KWEth4es7MwXl1W3zzAZ4mDhLFDSzte+RMzDR31Pyodx U525Vyt5TvHo/374oIU83jZdeSjg1SClvyd/khF/21IO31RYA80KP+gIOFGEiVWMDCkZJU4/ 9cE6i8m53kihR1gXjpP8ke2VjxWbgDae4olH5gX0mKbkuUMRTUGg73xfmo76NyG+maJLBbS2 in3cW+6CpaOZJjurm6OUvUMhqX8sBaLcXZXI7mEUp9daJm6VRJjb4W+CiUzNIjHcQ/9XUjLY EL3bgB9bfdtsZRWdI7xBNvBbkf2KshHfRlAOS7sd4fKKGGAJx+JsWi5I3biuwVJQBdyfxbIZ AjEFQ1A0148o5NzbOY2g6KB6xVsLx3S6Ae3Nw6f3B2mRj9DznsK4xiNWvG/MqaqCfoWAv1PA I/qy5ioGVi1spwv3UegydmyAd2048lNaEelq2pMm8bMjAOqLVUG3UzwaZ+IqUsRJZA7W7eiD FIZnBkvV2Z2EnSeuEIFgOsULQkn1g+xh7Z5YGdfik0OtcxvgdQuMUx3+G8fdgmoDjOXOJyAt HZmou5IQ0zT9LwGKj1iRFjfNubXomV3LU1caq2OTYGQZsUVRs4vb0eMNLa1qd5IYB+/ItpfD 8DLpAHmUJx1Nmybk7ivrieDMnqJXZWF2L9mWBJxLNlxT/UdOLRXaUm4Efl0OY50S7EjXAJa+ sU+6+rCoOT//gAjGpBjw70xhcLpqO1iK8Yn9NiEQJERiWLyLfMO1q758fYWMcYczJZpbpt7X k4Sh4KGIak7P2OVvwZWdWT46GkHXamnPRfXrtrArRdYPMYjhy16ZYDxBesra459Mcrqet8vV RDBjCjAZROiqWQuODOIwBLVBOzr15CyTJKYfKWkug0y94cqoHYzoRxMMlJQMyAeywor10tIW hEDq8fNBXf0gpMNPb6A/OCKp3SCpzNu6xCPan7AZ4Gr7NC/axXt+gEDMoKgSuqmTa3fM0mtA Nr10AqiD8ekc+8I+GDMj8cHQPKc/iTzicd0TvST9lrFchg1WFSBpVtUiOvTwiWIaK4DnPtZG 5whBjA0A3J9h5dGrf7CP2FJ3MLz65ScBtjC4v5aYmGrwWsRi7N+tCEQttgUDkjwD2c23BIh0 TxWnhGAShs951fzDbiM5eeJrNkloGDt0hoUNFOJ5+WiK0P0v/Scz2jmrbZGEDRN2Dojzl2eM TxCTvMCQ2rMw2o180Xxvr+xUx4lvoGeIHfCXxqzi2U3MN9k1i+eQSrZ/g2zFSYU0x2zN+CG1 cpU5KakhARFXTaUVWaJNJ1lWgPMvTqX6WV33irr+lHqCRGO3xtxnWYqFT8Xlp8IR7m88ltTm hFGjTeZ2WIvfPbIH/WSSR9ZsJieTfyX0KdaJAVkQS4Dx0fkrYH4HbiKhtk2qWuRw1EJlCGlW fL7bL6Ohl+aOA+I93iFAiYtR/l9Sl8mtD5RxYeWoWgSDSP8FBwZ1pgLVoJJ9d0EZ5/xJt2mP dmmgi7+a12uldMw5nsuBHNiGmHDvF/87gNUMV8pgEY6gUDJJVBOaPJO/epd4QyA/ZbWKcPi2 KdJcXe9Ym73MCWEg0CqXM0Ecqgt3Hl641xX2XmREtdlhwTatNWs0wH5p/ZQD8J+O/SNQ8rJG dppns0aYJkl3CHNaTvwFyxUa/lrqM98jnjwUWYbBl4Eg3sP9hCmuSJlh3t6cZm8FKC8cK+6f jvswnY8rBUkaQjvWIBOnxI66HkZKhud0nx0h6gOcl020TuUMZ4oVcLv1PgqVjSCOvF2rGmth j56gx4A2dierOtFX0As/kGdQ0W9UGj89u9DydijBsjB/IonH2u5+efE97/3SS3mcaL7pw8Kc lz3KWrE3Ij531d7P8QkFioJMZQEnjoC2YHeoYevJcuNSzF2m09OI+wkuzvHihHu1AD45ykFH dQ6P5s1vqqa66i2D9enNaoaQN0f0nqK0Nf+UQyooQWVCyRFSgDnK7FZAGVa0LD3q0Z9+9xSc S1Qu2wkuHC2hUQg9UiRuCEndMIcOwzRsyeEXoKzRAiVapZgXTtqTu3yh38H39xSfqtRbAshS QNyYan+zl4Ow+NMQjn+7xUXEKrAfUQKs7EBj3G3mr3Xk9GRnF4sfmglty6w2z2n3mIxSMsj2 6+WNzISwQx/duIWNQq5OzqbcQaARaX6iJ+vmCuh4/gtfYCS0yKbRhHTJUdBwa6+GaMwJWnhR S7MoWNK/Ak8KffFNAPlQyQMOAOd4BcCh8GMluh0xbAAe8W20YTGnbh3Y9nL2XNjlh4oNF+BE frp2tKkOGJzPiKTqNBD1pw/f+wWP5v+7eWedanUEof12ykUOUtCK950I6y1F5MnN1yJhGYYn FMbJ7dGYxVAZxUO4vyOXPptn4rmaIosdcvpaFzc+T//b7eZWFler8DF8drygAntQCUhTaj4K Rq5lrfC3/EkHw9j16iYdDXuWG0vG+QsDxQzJMPU+Rwb3GKLm0dFsnOgWuz9ChF4d5Nwq3stY +bML3GLc9SsfikALWnm5gOLVj0L67gKvUXOE8g6bNLyXRp51X5PgE8sWEGmae6NI5heve9d0 EWoDiWwJqNPf9Iq4ylebxJZMrcfVebVgE8A1BkgJht5pwKuZAs0/wXFCVmuhjNhIbd+C4sY8 L+NRU2At7IPXD/0dgAeyuOS/HSLuJlRvZWwXo4sPyZtyJmlkrD9+YIwCnMqgO3wJ/ILJLoMq 0KfT/6ujWY2h9MXF6Gy3kpmez3lrpQgqTp0SfTp1CjLd/WDfZ7AmsvQ2ua7eKpisnadY3h1X 9Awmx+Q189NglQm85m2tyxFCT2hHm6Q7Nmla9HnyhYPeKjpoHE4TUE8rW3SM72NarJPunmLR SVMDrZ/BWDEEPry6l4sg/PzITL3ZO7aD/PcFNwS01hduSebfW+nTKWuE8JVa4+62JUNQOLlI Q/Zq6+TYshc5J1CoLNej0tGIWWbDJUvjkY62jV7VjzcNoDV+aiifjZSG2XXFg0q5A0WCBcsQ PS03gAr4YahC1pkYBhG93EIjSiiPuySWkavuCQCzIM+lf6qSMbKN5DuJglBO3QG0TVKAc4OM YzG+UsDwS8/lf9M0HC0wrUU3cxTOfvfPFioNBr/7cWy50ntssscHtBFuScMjgsrgfDPmHbfb +ohoWXcKQAha8ag8fKnVWfODJJVGmC4B3WRs8oIE30glhUOduaZR5pi/YgrI1DJCXS4ItjfZ vspLbhKNJ2hvjo52MQS0Hz68cV61XwCxC+LvjDvqiHL57jm7xR/epTLwIUiLfveuG11mkiN7 7qscSNjWL65ezVoYINr6xvSIcDmt7011dMJPdbXlwRYG3aKUPQI1bIWIajvsyag2uOVmYlY8 PoRWsWHUEWM3a40yvn4RciDNoOq60z8rMjeXGWcBmlEyXZBSaux8LcOrJTVJQXlmvxh778wE u0W5fbzAasybeLYhHjUx7NHM5cLsDJvbc5amSRnjmU9mo3fbXvT7Dm9+X6ISrHuk8yVwiTz1 m0y9SVOBe4AP8GXIjN/iG+jDohVPAhDgsMaaN4928Fjwd0nUaocGeIxLZbJ68MWTQMPNMcjn By/mmgaGY00/vPHQ2MeGUYJXOm421jzrEd1z+YckqaN/yj4iBnXoOq1LDFMsjoDrdrUCxJoY altCctWI11a8XquI7OKDd1Bx48GQTD+ACjDXSzglQawOpTRhQpRlv9egNbl8IlAi1AnuCBg1 vPQV4+anLJGKCjpyOMeYDRZWV8JmK8c4bpBt0/k2mUZSvCdu82sA642+EVzqSQxcNJYgaERh kGf7SAO7MJAItEW7jZOFFdM6PIOpAyy6LLzRrMQFNagrunGNkQ9YEMw5aQtcSMY7XQHDjz37 UwZsCM0RgFtHfZADrhQoxEAmeXo01LosLNMeLfiaweWOr4U+xQWA/rKijWcGDorA4QhCBVwm HRt7CYyZWUJ/Il9gUZ5XhLdW8v5A5YaEvTZ+QEF/Kiz+7zh1bPHKSygiSVJoYpEc+7hKhznH CFWzu4GsG4Kq07FkdRnEWWt6ySnJwyV26xtZMzVmMwl1s+dMoKDlRYCNI5HIz2EAehTpuFcv U3mctvYv/bLsO/qRr7pAvidwPzVGqxLcI3zs42nXbVBEoOx9YjDcuBdRt55/mLqw3llTqHQ1 n5eR9X6BLzNiIJEQOEiKJBRfuHCwTxMMPS5E0DbXMP004GwB1HEJPLIkS3jQlfI6zoM5UJF6 xTlf2RueM0XhH/GlOxIQzf32nW23pHnKkh0Asj9KtTYFGaaXv2ajI/BYTtrrT83zr6ABLCZ5 W8kSQl8TNmWOC5VwqIz0MmTQFJ0oSCk6+47I8j+BkC+PrSEDyt87laNOkF2PnEAPwn2OYL8f ZSJIn8xJ+M8Qjny+mTz8cFpu5+0KrSKCxIrZkeTT8SYdjfzc2bCvmTgC48BmObTule8idzVK 42Q6Vm/hu7xF/fuWAfzorUcHf3fFHavrW6fqzVYnlwicZRilRSYwo40bsJJZ/ma0cspFze3H FKdgFjAxZ2+cakBv8EB88+eriguixhYzW9zv3Rj21rAS96KwE/ECnNTqRG6nvYGA7CQHnOOq IBHMidTXVX9w/51xmA+WXo80gHLHVKNhX2UCfafna7RAtz3VpYRWDtj7vxlk9LtVagxkv1oa N5z+ljD76CojDdRaVZmfCBd4ZExBIjPP0kDk2/lHnn0Sm2jR+HgxNKRwei5YINCLzNCy94/g 2Lpv2zQ+/EMUazSnvTyC7FAlpGSy/dtI4aCiRwX6pZUPWMmOEFaUahfiZ/0GVUgjbWIlXoWy OAwgvqbfa2NaqDnpT+q84NpYkWEMm5nCKKwQuKB4e/Nz5F68qtIE0yxAnRXBwtTE9AeSUtRP NDfpr0TgwMRjWAykHA9C1MDuUeWPiu8I1wTj1fVnQql8OecFDqWxmXUWXUszhdSk7arofoMK swcBNmPpLZjinlkzk8l0bDCwSUIBgvoj7rellOqUVIGJpRWZa86MSxim9Z7NOmQZKmNpoY+c RWiOLtrzJiB64xuVbMTecPtH3I8BiiHhg20fld8XZ97nuS09H6ul2joVVaodWz8c+0q2ve8G ly1mgM/E8BcVRNWWrCXP18R+c1rGkWqnEmkpqQ0W0pyuTWX0Qg2tRKSE1AIZded+bARRNt5J EFagOiUMyxnPNJuEEiEeNhHDZ+thuAB/7uRc4xmbIobUymwUTTwIN/q43GF+mLzYk9eu7toA Q1FA4G6ID7Sa4Kltw5E7aEqx8UvwdfH/S1cHXdVo89YlMujH4XwEFua80XPNBnip3v25aCwA wv6pw/3veHE8WOepHKojVkUZtJP/RhshVcBoiGcJm4yxnZzrGzdt1qhdCkCFK+kugQXuSRTi FY8z0todoptuuVzjLuSJL/g7BwIwriS7nxTPrhxkoJn5D0/WCbtezN7xsJECxH9p3DQKUZsl smgIRyTbYS7ZTDSyxApVM7FfBc89+wq1XvCfOBGqq8dad+8tQThGMZgTaXrXuHllpEO7i5To bEvyHpbd/3vURnThOOWrImw/CQuOgf5fseMY9/3p8KaRwPJqr7sVvpZVvhjaoNSppAvOLDsK N8pNMEzO+9lQahNil0dISyGnKHS9CJ9ob4W9mOHtMtuZYEpOS1c5NE9aOdgtZSkiMz/YZWA6 hy5E/Epm6MB5vIbIRULhn324u/q/9FWjCdRUYAKvmaOvWaGGko+iwnIpLGoqKsDifmNOxCb/ iqNbWNg2KOSyv+NzuRih/W6QcKzl/T7yLvvMB1bK4BhdIfiDnr5cAtjbG3C1kFMrFFYUXhLI ZmbZT36aE2vBOZQB01Vkgc5TOdjy4kmsLw8pM6/luaZuF7NxZtvaI7uNRWBbAmqdMadJY8SW 8axoL06jqYFsirqRqdlGMyvizBrmX7Sjw3NDWfXqr9eeWoH5M4y+QjtPnNLRs5G8vqUkX15K VhPqJ50sTGloSTatklL8rlp506/YrBCuK2jJLfgOGhCqbYN/qlgaDBKBP4/0ki9CsISdXoRd 7QGxMuLTeoXc54n4gG/4bpH5XhFVdvCdSODuptyYl4tERHi5ONaTkvT5sg4UH2CrB3Ug9xKe abv4IfCh8vrzwQimApyWHTav/0ky0cZSsdEy0XN0h9ybMoRNKAmjRdVNAhgQKUri1+MQnDOb meKS+t40MiSm5DuNIxKdFwQQRwK+k3Gc/CiYXl7D2mccg6gswiAkHfCk4dzAejJUs3Di20q0 1waTrN8RCt5iKGV0SuXbgAFlSddE1gCLOmDPHH+6UxiUWm2R5GGKcSX8qSKQtI82weAtSBA3 eqyrpdASmz04o3VVby2UhN5oGtN9ozpfuwRlocfqxB3WkKaOCr5ecsZcLqcfDocKEXjLzMSM d4y29PRSIWPIktadpII/682kP9i4/mKZuqvHbX/0mq5vA9wDImp7qX1jTtc9z1DkaGulqPO2 4Yaub/cSBj+UaPI4x3gWI07T05VdFmNKAxbgbN3HU4f790TiKq90mkuO7aV7whiWveO7R8+a 0yK9zz8JMbrR316hHPEvPvm4DfwItLBBW62rm2jFqSqGASCzV7DvELm7YjmXI7BUh+/6+elY jkyrfQqU5ZibSi6Kr7E8Rs5VbgVxwTe0wB+R24QhQtn04BEiAWxEubC5D6t4uRyJ5ggN3esy c6ZxhoOWv1PNCecy33A+Q2Lt0cIonUlu6A+lTx2wu5VOKoJXG2ejaddo+O6fkxnKCwD9a8AR HhyBgUAsN2lDKDVCJ/Du6g0zDtGDttgI5dxVjMU1zH5l9NqqDRTETa9nOCH0SzoRlfJ34wNO Bh7gUq0zwpOlrDJzg/V3VMs9v2LHL+uiAdHo3ZskH0bj5hj1vVdGaXqnQfanGQPDmwW7EXv8 +L/AEDX5eVUA6vcDjA9ZYSBi2B4+6dKGcd6GhTnzHK4OpW4xp+5+vhEniEyBXhqNKSnmqWFv tt+9h+PyMWMpwIZ4zK0HbOicxlf0vd2H/op/zfoT3TEgLavION0pWNJjdF+N0UmCPufJwrei w/mZtTZLHDyLo/BV0Bw/tvhJUBEANtVLQ0yqgm5HGSXH2hD5y1qVOtbti5e1wHxa5UVTEUef k3RtPnwEJd7BS6Us64FcQE/pLJdXitOUqzNARDMIxlmOHWbkKM15nnhRZQ2WZKd8i6hHNi+B VSBBqyiKkvt1/oqWvqY/qb+ThoX306Z5O/3JXpu+BbpEnk2UTnKfuF8gkjguREkNv+eNd3TV 3ziDZhHwnXUXSu0jGnKhw6b70BXeZdP/6chvzFwQ14ruD1q50E73E6JJfrnE9YFwv9gcRStV rMToXoaif0a0NHCVU+033T533uhoZQGyokLjEmAzb+l0fWSZlUz9eQp8klsElbiwnMH2K+bm svpYOf9YEhdQSTV25Sn4IxrZWXZmNzyfrRaGOl4JBoOMVCP4yAuHdmKAtaNyhQi0et+L5qHB D1Fwgx058nWLrMG+IYhi47N/r1GKd0l53d72FnEDN9FsoiPQTd+tVuK7opfpg+DtrZ8nscCj bNHYGijKWP4/hMiG6qaGfMROtDF1gMlk7mfltuQghNaHIDljRUvQcYCIjx0sUvki+lY8j5o0 xEiMBjuUBvN9QLXZfhq5Gxbu8fAdmDoAUzjGW39g9Kvdq3xyyCBbxewlfIWAJ7ULJlH4nA+M dLxVLZReWrLgu65ZKaw4hhk8Nmrwz45WJPqyH3R5i5Q3O+PXN9W5DArqwMzj3yJwLplOadVu RQFuyIomAGmhHFmBCow9DCucqxy4gJnhzAT8vNrYf37ts6x2wFAlh1xcS98TUqPMXwLTYNy7 pa44bXF0z+fJROzxJBHKmE06/0HZ5P0uy3Ee4uoD2u3o3smT+4QMtxINm+HNIyOGz6/lbaAF 7IzzXagtqKMXIskRhsSEBiH7aGW9OSHdJOw0GRSWfU2mC4PxOFBocppxqS6qt7dG0qcbON0C 4RYleL86MZQFof7Tr9puHIPraxWGq/ljUlSSfg8DarT4TUQWQQlq2pd5lb8EApCWuBdB0kit GpJfi+drqzFxPTvJejtnax1wBrnmT4eNP2r7X4EhJSv7e4sJk1lk2EB3lGBU+NgAeCZB24gY BwVB5Kz3XijCkBzVh6kXWr/6ub6zxp2Xx3Vphv6knCgc38VSgSHM7DMxv2gaAgx2jllbxsKi kFIf+Gv7Sz1/aN2FwGkktOEODjrJRG6pWpCDQB4r1vou0woXii07Gu881nME40NYIMM94FjO PVZ0MNMDRJuLCWelagnYx0QJHchth6KWlNSo1y8XXvJOZ2NjDx+U9lVO2DbsoRgIDzuneOTx mDmAUerhV7d9UyECZegxJEYAyHWz3mRWHrSMBWKROlmVlLQzmeprQ+g344FdHCXyG/gIvoAC 2tfY0wmgENMllziv3/ujfRuup72P8re87/NbbBXwRBy+D9xKpIm4fTuZx3jhdfIhX13mivuC 312B4k4YmEo4hS/VxDswASKzP3Rh8OyLne6mN6nNnna8mikCY/r1+yZDjTjCnJw3nRbPL3Dc Wm2IhKGoJ1mcw24mmURRrO9WCLDqB7nNhdz51aIsO85Y9llDV3YxOxOGWIyqCAWJO1G0CL4/ FzZT45urAs/jofmPHJJOv+0TqigZxBoOzbmx5fLY6Y8lNae/inNzvVl7J5a3ue3m9MClOVup SxJ8XCspj5T40vvgVqH9EkCaiV5HppAgf+PY/J/ZJoQ1y4f7o3qwOBxMnG5rXuew17cdrIRU f/qa2pQgnxow879BLxEEGAhOaSbgTGJxg/Wkl7L+dGKA5E3SegnpvN8pElAHExlpg06jFa2B CBVc2WL6NEvf70jjYRm7EoCmc8QtcEFgpVR+wR+YagUuA6tJM50e3hcnPIftO3uHs38Z3wBb HqmL6iBoiXGf40X0keUoAx80drC0/Pf4vyxhI1tW25hCW846eLwP8QwnaQnouYXTJtuMNCq6 nj0lvvB/i2MMy8Aj6VFl98PsrCR9oYQaOKbHvtny5aYvfapkLcTgwQM0nf66oU8Wjg2tnyXZ MlXhvwVzMmBctmvW6HpB1FW69+UMPalh9ndjNYeTrHzKamZQR3240guiK8FJHAprSiGPhOi1 8SlaoazYkg+5b8hapabWgTaU6w+RQBzwza/0bKWa5q7eptD0IFrPoJR/AMZgqhC6ourr3Auc M6yEqtLTPIw9Dh/M7n4HV8bQGjM5D7QRQB6ayFUAaVNAduFLdYkCvK5hB2nYiUm3zo9ZPLBB iuYwrbLp1Xlk1Xk/Y8kvAmKGQezhG76RfMvR1doDuk00tM53QR9YVsfwyFs2wOFYM3AOUcEi C9zoU/9gHPUJq8gCxb3GoTqKIKGX6rrPW4ohj6fHVxBayPosWzsqsd6UJ6Hqoe0sHk0gGlBS tBouka1F1fxHAC1Y9ZzjLc+2xAHrwPm0aR/3f2716XxsPcBEX1O9loAJl0hvVlhSEPUzRUPA Spdb8LlgTBvVXtREQXG48dD1dIJV3NQaMpnitKEHFBnYZGRKf5SsThDcpJob4lg3TD9IMAab L4c6VQlqBTop+LJyKv2b5c+5dunLU3WTpzJrcjehywOwiTz9FmVngfoUGL2QmFlYgDsqo61j vAxkXNWnJOE/U6qJ68z3JAlrogbkwxHP9q57xtWyu/2g2RPDEf9W0dSMZP7JgvxX1eDpHFnN 3uEMHV/lOpZtspDhJ1FqWKs02zMyKlHngd7RPPSkFUpRZah6TO4wh/Xt/lCmT2YhohRNfp5a HLi0ilJ2ImV/bkdcrSKmpuBUf1hhjuRZJE6Za+l7Iv6nXDWqtJLzIGB3R2IRIv1SwlZR8PdB 7DWnlLt4EgMNBhpD20EdUnwOGO319UXvZFEJGAbcVsJ6HH3rS7HGVdeAmlUf/hTO2txuRJt/ /d/oax+RD68Dl+kvGsI7KwwH1M6cRq5IxS/MHY0zu7gwIadp5VNPAtuaFdwf94O87XYvNKkP V/JlD+cqkh5XmPhDY1pDpuONGwGe/ggZXoivktwIRgyjZkM+0UfvEe7lvFcdLuWjWbc+4l24 TZDdvibph+Nn7+gx3NoKNf+5oyg66ayD0ttOOE9JamuwSTA0ES1jSKaVszC3dx3/iTnm4seC MPRCIzrbq5lwZjcTYZeA7K1Ef0a4/jxmjbp0ka1jPGRZ371mitWlBK2YAGtIlujCi4TLggXl sN7DsYzO72my2JQrD/02plDDvZjSCsFbdEtE7pt5uyAateIX2eXyqSu8BXIkeK0uwe4kyH8t c5nFAJT79D8Yw5uY/wcXe8XsiY8iTaDnJjhMFUCctRrlUd7SB/D7Y2nUvXnQ7iMtOdTHBi3O fx2Rg+aCXdhtlW8d7TvMyzA6pZk1ud1Pz2a3Phrks8noIVandBmbsToPeg1BDh/ej10NFFYa 0s4ngKS2ROL+C7SYdv3VsaZtThvS7+PVTfYXTuSzWjfSVSwyypOIcnHSE6XvsoEyG6Ll676a LVvfThWKT2fiLkVK3zyQVDW8/u01t/C7mDQyESKrFwy9o610cfJDJ2ztTIq1P2indZBTJ6i7 BxXhYVoPKkycg1ra7A4UtJkkaXFP+/ED6rm06w30qbENlo8XZIoc8J5/Gis6xMM5TFuKC/Hk dBmyCtFne5S4G0kZME83zk4XwtPay7qTTHfLF99eEKm4XYqWuCUWgqmsqBZ5Ner/H48vF/gH ziKkziqA0qhYid/RS90RTkaic/yl8eagmOrEp1hTq8C2WGJqEaMZuRBRzlXbX74Y6FNtngWa ZfHEc56Rzdv3mDJcv0nhdBG2BFIc3mOFHUfqdwCrcoyPvh0OjLX6G4g9CYApkvCQrqLuN8kI G9IXppZP9Pg8NWwDSa+Wt53210u914Kx5Lo5FTVeDPjng2yaFNdsNMUxer6AqYMFWX/2oWMV 7YUz50QrZXn67mV0xvT5iIDJVcdvLjVgCcwNWzkX8MS2tt5cFqOu9bMd09HwtqGTj9wDkXDU TJaPJWfGuBUJAYOWufzGzB5f0oDvfRXPg6ZSno3X1cH3kHWkNZ/Dg+btk42XFi0yvJHqd9z9 LG6L1i6WyHs1rj99rLOnMuQcbbwPEaICqz10I27MhaYwVoc7YA2xre+i2Ap0egpoMA9z7HoH nQkxZVDf+W2C5sEAgQ3uazl6Tj6nEtKzGbPMVRrnNRVdvcujcVOXc1HNeIwQ0/fKBMW69rqf dZgbz06UFJUf7Q9Vd41lkrsig8dnOJuj/SLTj3yDB2SCG5+KWvaGjiyDk+m1eWV2xc9UUJYS dj1D0HZrawhVQstXTOv9HleRJIDym7vuOiVD6+YzDqLw43XPZgdrHOO0RVru1cimk/u49pHn eVkxG+N+bqcGxsosOBOVjcqTh1j07QoPSShznn4pBFrS80w2V0mIM9rCqSQ9IjgUh8+rmFAt LPbc357KBGWNBsRXEZzGGSL0oihtxNAlLgxQJxD/pW2sBERZid90Lq6PIYuL3kD+UqJHMp0b sDTF9+QFAWf/up4PsJqrkRyG31Qq6+SJVoQkFE4NmB4FihOeTg1lKyegtMAtCktYQ4GOJV3p 4AgNl58MfY/KNc/Fi0IoOvHQyQThlcrsLOrXcJCc/BtwtTtw1ARNrPmRWasa2ZMxEzHDpHH3 42CAeu/g3BiPNQFgYdd1EbAvOUgsHlBtyWrYr05XRn4LkyX4r05FzrJ5pjWzTeEIXOp68TrA icY7S9S0z0qKkJySWv/NFLUcyYGhZ1K7lt3rlCKhNqyrtePkGeL7cb1KGyenbCDqANyIfgPB toMeUitZ8q6ozhn/kq3XlE4IgA392pMR4p6KrhwNiJi2wMzrTZLcug8qOXk12IB49xGg4STx 9M18AUtjdKWQ2UWewxSNU6iapxazTLXQmGpzYrJ5Kq0SJtCIttb+fyl+1HsMPY+T6w1zt3MM vF8bddoHAZHVysrFmrgGkhX7ui7rKwAxRO4JnKPZonfRXKB6WBP1qwNpJr1pIFNnBziiU5E2 dDD4mATcF5HRWi0+mlAVB0wn2ZBpP0BKv/rUpwiK73Yz9GSYwTDW8Ho+Wz1XvhDrjmn2zzzR xthTEeejM7kXAC2mW5rGWo2PMQ1kUpDSel5gKAzWFMLjzAYmtwrN6ZHGy2MlHG0ZEF7b2iNL pHeTidI9H/5pYvGIo7Xwmd7CKRLCaUNu9IFCR5yYO0XXlMTF64vKNVXe37vc2+wrTYWP6CRI iKSAVj+4CgWAXlHHiV8lOfSVo8/sbf2nXVoZLhFwWET1VYihPywXo62JG2TlgKHBiMQy/85u H/3hcCRjdFZs2FBaM+ZfrF96FjlxZFitjWXeSli0fQgCDnLgou537zPVn5AmpyPnY39iDHtb EQRIHpafeAl0y1xLBKw89MRozRgekLg0Ui1o40/cRloLaWqtPfA6ksxA/ZmB0kTzmyUx2icp U3ZiBA3vOR9m+zm9/qZCBFxlBg0LCsHbbP41WEY3G2SVwAT0AIDnQkdsBX3F/XFQx6M6VEjL in4EebpcxBvq9NO7wxc4vQ0Q+3cGOLIRjS25z2ExgPlrvGe3YGhz3VcBPNvNmLqydsN3Ium2 YcfgBbZvBMrNesFzddHSK/H2itO/MWL+RmoIrCZioo5Dher51VUMHBRGu7JZSGI3ySTGYdP3 /7RkLq5/OTEopHvNw4aTN2IBouCtmJIUW9PwVsrFZlEcfCso2IshmoZbPaWcEhwEmt12kaIU nP3EBQpFpZ8QbGZg0exD5qP57gSX3NItGkI4WT97gKE5fQ3aVbz+gaSthftxFm0xQi+nbR90 Q/ux+ghc2Dy44B7SZ8htgv9W2VPFVUCSAJC4QHhLqDFIEe2w1By5Mag6CVGr1C9RE8EJ9J8O AuWcxc+CJXOAk4SUOtorLv68n1CGK5bvpfE/KPxOe0FOKUOVKaSf29y0IP/Rl8NPrbZjsScU 8Te8mzgoTQgW8Ox3qLbZc0IkRZ7yTJG12j88T3ym9uDvncqdvmcb61aC50xkHnJeIB3N+vPL Ng/mI10riMGddBunZoDaf3/Xt2IzHdE7Rph7HUrZOgjSOqRBS2JvNYOvs6qZpmk7L9O3+HtT lVYtnbrnGSeGIgNG5hKysb3ekW5Nwmn28rBfcQ5ul3ZXUqIlVXAL2tl3uSvaM37vADFINu9Y ifrKCzqK4CJ+pe8OJjvLAPJl2HeZ+LEsXZJgJ3aB/mn+n05qkKmFP3C5VoseEgaxDkVsXPEi Dxz//sGZwsgptygeyNiyFGq08pUVw54g1vbcg5npFIGonKjpIbt8hz+4whjngBGJXcxSSbrF Z9/bp8cuPm7AlS9zum8ix42g4Puu48qSDYcU9/Rnl3v5zL6T3XdKQG5Bj4UfTgEp2A+z23UE vcOeNl7vfw8Q4JgniyL4adqrSVzfJtwEWY5mog3+85zGEwceoHHKOlqMm3XGJUjT56TINmxb gnPZ4y/LHNCAwuQzdfc1aqmXmt9JXtX4HoeeI8i88uQMNWTHmne2zmY45s9skz2ImpzpwjsL 4KiNpxwzhrQ93xV+Xxqxd1c5RDfPKEdo8vzXZjpnn8nj7WvHPl39w2WCZKf0BoJ62Su375Wf TRTQFGCbDvKIDCpNxqj4TAvau1EMisfLSDw5aXdFo2hLuCHItvRrU8dw4SxFzCU7Cq+uyF7r C5FYNU8sijwJcuSkOZuvnihSM5IAyaeZTZGvH/Nn7b5IwQ6qa52DviB/d1ynBzCQc78Ozvs0 dSQvEdf1oauDlq/2aSjLo+MZGOtCp86uBm5gM5sz+mmbqIiCgmmcLr7+8OdHNbAlkHAe3yca 1sr++2D2dtzmVHqf5fqo9dVqkqIfD+p2tsFmuhrYb0H1NhCXGyTirRJ4KNrM17MlRNfjkyA2 D77dE5WXumHwcvW/M6GXbvGiW0pZA+VEMrqie+/itRGIri32kuZAwzaiSsc78LpaZMfb6dyB BBWiYtk25qA2ivBRwnuDU5vcFo1anO0JCm4SLCLEk+H8WkCa1/W4+9EP0aen3qlt2YZLrS3J 62/KySWIpsIpnf3m/7cTWaiV8AbjuVM6i+9yaQvw2eIdiW5MKKRq3mLzUY01exBmTOIr5QRP t9LBRIK8m591pciQThaxReXWlFEzoe/n36Kat4RGnkootMirDfFJV4BJmTmHgI7b54lRtyqY 7V2Lb+8af3EhPklljj0scTLvlWsJ2PLSEoEKbh3e5pqZblgBlTpkNaMElvmBGNsAkE0CSaYj 88R4zNHu1DDCOxYhplCEJLQ5/E3q4B88c45AKM4jLZu7weUi5Xt8aYpMhjRCLa6mFPCu2psP V2ttMOb0Bto+IY3wusK1MhfwFU+sDcWISybNb/IpjVhe11p4GEmXT90NAkdBi0yZpZ/vzyVR QDV7a8H/8MU9aWsxKaJRkJOEtPzEO79fOxwiAyxcFq6E5kLD365mJS5g5TSiv2xJbqRmEcVk DuMgdEU4dMJd77E5fg6s3BOZQ/1mnrAL7ujCuYAdpKtZXZeA7p8uC0XiHZrzOL8pgxzpiuNU HMSpTJBkevxpsfyDylcRJFLt8A81tb/t3lMg7o3VTnv+1NNnnXV0whMSmRJ7XuMo1aDmng3B bf7+DaOn2+khsPPd8CubXZtgwCa6tkCJitWk4gnXnpxO3a9LUK/X4ZRFfKGlcjanS8tqBTWN wZUILmccA32QAkPSfjDQkB4dJitWe0A3BQD/kgft4U6sVbmJb6uwxYiTEWkb9yFJnL8nfY8n Ip3YoYhV0NpvwYZ5fSqMkVo/UEk6Jw7dBeXFBc5fCY5uPWOWcoHjtfQdeTHfpIX9nXIF/elr WCzNAYSbO8mYE9pDsuVB3ZcZisl40q1vyvi3Efm9z+Gdt23KpsjSwxEkEtJdVcJeTMtCVOPL 9NS8QtXvuepXuof5uLXPpmrrBzSzDqcuZkvkS+/GkQklxoCwrSub0O63CtL22EYvA3/J8fXd lNDHUViNaNaYGLvdRQwgv5XnEuzBrNFNSQ6nHm5z8Zf9JN/2sioHRRtDcD9mHnIESzC1UamC SdTc5wnj7UU89swGWPrXvs2mHO7dJ/m32VJkIYO6s/2qXL/TZPIHtxuCE8kZAnkPpR0CjglC PqAlroOE0mEIYD7eHLf0oZQri1ESapaE+rr6xyq8odR2E7+1EAe2OeVhm+BKXp2um0BgO7jd bf62kjr4xn2UWrXhDIUsOUxk+7nkaWTE0jYEuwp0styhhFU0POY4P0QagJP6ko2k8t64Vg1U J+L8JYv3zu9WPnwQhqGT4WY5QvyZYfC5o97csdtHQdJwezMsNUxpjDVsC6Sd2QICIeuJj00d 8TBO2A4/L10KYG/xpbH4Jw2sJ+ZG4/cPYBerixRKfLxJdaILFWL8tgMSKGEzzCiBKN4VExTm q0TnXErhfhcF3B6lmuqUZr5hLMA5L6FallbqMAAmvQ5Zulz2f4dxCP3XGZx8QgKWCKEHDaZk dJSrUVEG1uP2P9In61HipfdhNte6JEuRqMu1JVzteAZ8UT/Nk9g58AZpef93nclju7jKA+uF bUNx9lR+k9GHDsKzLS7nKXwaDbJTwpqj1bCxJ64Wy2UNy2OInuwZMIBn16zzbjnl8C4/5bIA +nxA3u+zxl73DqZAhx8A6cmMVkvYTzCWiHzZyEGWBonnKtNa7D0zGpHjFB7m6FweuC3pm50s CdxH8jNo6mbGBYkv8ClqAdWwVYWFg7rzaDcZ0b1Th3WUGMd9EBWd2F6/EQDSfzcjfiUZSWtv yFDMaHY1IoKMp03FTWjNUe4DszyFNexqs604Y7qgtEOWDTKARGhy2Knc3HelVJT0V5MqgSdR u3+b3wAgn5dT91FhvLMln80SY3ybxJ2K/CEfkqhDIX1wxwUeAwjsvnGlvsr0sqFTofUxXW8M DRUm+kRL+yDlirdNDYYg2ZCFRyjqlNX9PPxEAoj9pWfPbvTrLyE/B5aU4qT0H2zhnaLFltRP qV37eF86sWWxK9dg0uxrK3TtmEpn9YXVlOwubi8PGIqmKDM8G1jkMycmDoJKCx+XdFnxwUpz 9JrrRy6odHikiI1coF9PMR65pU6naSEx9KUHBjgSmuA+8xXl85aISgChlJcin5LXEbd5GipQ VGxzLM9n5BXu4AVySF9643aTkudL24nHe3K74f/5u5dXR6eGx/b51beXISFriDansm2GCCHl u55ULw/J6tMPCy7FU+xBWJge/ySb4TrmuuB+Ww0H/ZOLB8szeyfiXeLM6S+xOhDZ/iBP+8Wo T65JdkcwotoSjFKBQBl0R9TfIPG1Oyy2XwXgKekIDXuj4rU4I4nZncZFBMHWmNiUgUVh84iR vwGJdDEv7dS9ZUJlmloTTExw470hHdDoamfB6BxcOEyoZpa8kWlpVWoBH+28D82t3CYVlIG3 j+2bDEaRs2tTtFiz6ounheJIyGpXNcaYaTbjMGuTG385x8v1X3hde5DDLkJXchkwZnlY4+U/ oC7QXhinvM+PuDSXHlsHzoiJaF9V2q+STIPGx9nG8QYNFBwebwfeStIxgL6HYYvOQKTBKqww ZHKd44wzoyxak4x9etdfWWS/BDVWMWLtQdORQniqVnjztziYg4QSbLGePY69trG3zzqsYtpq PMxbv718TYBCQVGiFyW1gJ6xwo6qbc74+Wfl239q/jgfdqXwU56dRd7HNkyC9FmuLOSXzWVl WPM4oQwwfYCPkISRP0G5n5HrXhUJDoD7EkqDTArc+rYQr1PV87d01wxjMc42Dwaj0/X7S7KL Dz1zaZd1YkQr3ZK23E1eyX4Cki1wq/LrXg1/MvK/7eLcmiu5p++qet65im7FymyUYbcai3n8 ci1hLCzZFUG5m6shFjJZ2Lg2zIE+1xZouekiN7xbSAt5fQsd74ikxIQuDq7tYpIzVzjxRjsw uy6zn2h9G6Ylfadd4bOnTS2xkDYV9VWpAsb80gDUjkoS/in1ys8IB2TXy2h4elRnt1y1YwCK U3s8NpK7qE0z9ZIBroiLFZFePRYwKVWAtc3uUhURDcfdnC2wbXNiBEbOY8Lvq3cobIDgrbtz 9LitDDLGLRwXgmcNBBf6Vbk/rT++a/XXX6FzZAOuKYklMvJS9SNeg6ksxx6gJDvJlMc7fqWP HgS3bodWzYC3jjTVZfufEppmgSh4hHNCLnbDbz9QfWbMFCgj41B3pohkpb9FeGJ7LH7oXhU/ eesZtue6P9tzB8wczfoGR8xfolyZ/z+uNrtVhby7T3GXRa25Tn4RAXC0t76bb0vk8lLtpTc9 27chW6WqPPacBmD000s0FHnGmhWi7AZHqAP/GWdNxNGsx8vIm5yG5d/rA/0f5DiK4wimEE41 JY6OelmwKrD0y1arw+9SYuQWiN21Xyxb3p0sRgF+EbtCaODbrpGu07Yna4HOKweTyHAEbQzp 8VofinjaIoN+eKwqPbF8PGk161KBZzTbAi4L4gx6vVyBiSt0d7p9q9po23ZaVUukg5xMKjZN xHOv23ymjNzoGpvuN1PuPp6g3wiiaBIro4yyxZlOtZEOY109dMYHyZwPq4KW5m9XiYxAeu5Z ayCy/q3g+gmCZtLucOq6C4qXkIAHPdD09uHClg+Qm9cfVWt+bclJvYt7LlyD/sQK5kj41Q6j v62i3LKHLCtIDKt+Kyi9quHMG7oBIpJKob7WHiUHGsTH6KYCnWjKAInbTFi7D6YBb90ttlDq eX9meRIFmCC8tNRwNDWkMI/pj8wB6iMQDVzNlgGUZHpRIUOmp5xAp3Dp5vH2HK0x7BCcw0FR /jDMTtNcIIMaFHcRHT/yUggSzSWxjTWmJYElW99ZmzPeNfotWbYk5XG/PH8tBizUcdAzDQl4 hxet7DSOkQPncDlP8R0gJg9QIrrqXnVW8inoDeuhGCL94Y7ematypyBL3x1ZprSBIjRO9GmJ 0r3byhEr0dO+qLAPCcCa4Ln+S74q+3yeelkxMmfjQzJVEWzjmuBZobkQ6b3iHFJgofKzifNU f24fDCUnOqoqrzpJ4wZOaXpGf3Zq5culj+xVovVZXYMcL374bNtVys+kuAKoyqyVbWW8RH9+ 6S+XneoMRsL/yaruOcI9nmnFuehxSinKhIvd2X7bQLlEqUMc4lu7j9lTF01kzyiHR1WKYGim TTBDMh+NBwiV3kqwS3EGweBNRWqxOEb+JBg3Mnht19OTxNKC5XhKw7RMp6vV5Nj+0pCVqSKP 060x7BAyz0iNLcQk15mUQA6/Zpl5/nsbUrokf6FQAziLV2XUf3yGxpvchUpuRCBuy8fZSHV1 UioJZ2i+bs3hqEOQTtnI5xIhyRTocCprUPQRCqyaJtmoM8X0q6PgX6m+5Rvax58h5EkgLz0Y RYcG0V4xy2nUPReqySd8MR3L9SVrTF+2Q0h+X6OEBkU9lFBFmT37kPIKBJrX5fxN9iOLjPHw 7cBQ7v23BOtfypIoGNzSP8dro0TKEiLS+cse0lgkslzVxby7z2VDt7jDn8G6PKIXgtmYf/aV yI9vKniQHV6iBArIk2rn6P//kvNy+wjEEv2pofKlCudwAhmh3QTM0YUKn4abLeuL5pDnTZpe lL99m/DtyDYa04jJfw4CH9XwaJZmpPRaA+jVdHaMB2kotHHee0fXCRfqL3+bwW3iT31y9tQO lf8/icwIMmhSMg0UoAQhpLdzjm76q9QnXEYK6NM0Cz/6T2V+Wr41p7eC6WChn4s3rr0f0qZv wr6LGEdeRxucFbBxK+VoH9zYi3MxA1UnuvJJS+DYoff1bRhKtykjbfDUNJ74mllw4zguP3iL v7SsRNwfd6PLgxd+AL3fh95b7POLaOhVtmHyhp0vNT24hkFwPaz9lGP3QK8fkycG8R6NyxvE 3JrqR3NT5tZHAPijRBH3Ej1g5v8pRwj66LO/OMvwna4aYXRAF8MmsWZBFs8/afH1rQkVVxSP hj091E7Vw32KBJF9og2I8tjeeYQoa5Mwhl8g5CfSnUPaSH1Zf0XBu9RQV4PtCA1+E2x1wG2v A1lzsYuTghDLLhZo63Ihz/iC2t4PFBOhaRvcz0EqTT7OzGZ8GM8the86Lw07LatTUWQugDH6 j6v/yYw6WlZ2ch++LODeTosChZX5+EqaAJ3h7QdbhrTQzVPOmXjC2MIvIBIou+tRV6kwBLsN o5niAdIjYU5k+M9pQJkZ757TjivwI7r7k5san/tXkEeyYf5K41nGnGHkGMKOjRxmrXcYQTh+ VwuvnOTau6mCc7jrEN6wVg6lUI+IKKLd2a6o1WQbaYPbEwchO7p6WIx+Ud2oML2vKcT0LR8I EDtif0/hogm0MHVUDXoygNDLqpxFYpTp9TgZJTbXSnNzZedSujduUCU5C3bq46EelIPAOeYh MnEuglH5B9GsNGr4EqMvMAkd4xiWLYDqZu+mQAfIDdOt04k0XsU5/lbejx4TtJT1POvNrunQ /vi+hPfC+55b6B/KXG87Yj90P6cM6zM0EPkWlG4bSqRN92Vy060iyqQvwGaBQ7wa3614lYnY /jE29PkKwr8NEUHwfregfpLz0ZD+Lll7TQtup6Ex+GHwjnRUXOcxXd2X42yG3HKR5KaMLbne 1LEC99eUo3zvda2+/CSud9J+27gVlwyrmpjoRYu6fKeTZHxV5oucpih6Sgnknsxq2BYTcafZ uzMLNUxBaglZPwDpEJltgJs/mxKhDReJAYGoJ7i3H5p0C0oBea4FX74SV1qIBCnj71mfh47r cpjsAP391qGAC3iWA1nuH2WsPoHg7nBiLxjMuRDzHG1aOAx3HevnLlUdTEYgqdWC6f4AXNR1 meOwxlMNNkFmRbD5CUcEJPZUyrr9Wb3Lkwy0rFupNaxRGJsQqBhoobUaZIicsE+fVRUWDnNs Gw9kBECR9n2xFi/z8qNxtExZ/lP1navSlabvYGX4ZuXMs5b1RMvc3OjtAYnH/r5u98wZHmZE B+4+MutiVtCMmfABplATH7S4Pp8WCfj27e32pNd+oAnjZg6ED/cHPt2uudqJQbge4ExKs7dg sZoRrye1EorGO5gn7lN5SRPjGvxYdYzKP+CMooXjGFlOi2KrIWA2wXyDdxezbWZdQuQhgDGE zqxM2AAR/YHsR1rXcH7mbWj7h+3rr+gc3Kfui6bKoC7n5lumb7OD7gjl1TdDKTILbeE5s1YH LoVGBi5RK82xKxR8L6MPaZp27jh54n2meg8IXrve6/YMMmlqJG+wQodxpbM1PKrsVFrnl9t0 /06z7xTH4OpwSeOFnh+vlwltc5/OqO7hWdMV/k3BcoWVKxdvBwXvahxQbkiNt4i4ueL0Cx1z 7afnE43pEuJZmBHQIBbcTv8wwdH0nSj/9NLxGzrlQYNES/ui4vpue/AjXxHEr1QFHocFl39/ IZE4vhTSzOMFPenDDK5nrzQY/4ndERyIaVs/BPgv8kFIkSl17pfd/TpkevXTo4Vs6NxNq6bo 67QLGlj7Pem7T664TFG1K/+qbqqTg5NbhT42mmcXvLY/kQn0OquT/WylMO9ydsBltne8+uGR OZIpcWv5Qsi0N83p9PKFltLzg/R5X3OFHPKiX064c0y1oHCJIar9/DRAaM9IcpPWKxQhqTmL p/RZjjb6aUz2vbxHh3RzOKx/0nJO6eJQwwLwZ0b2hP2kzTLzyAe6vwImDsgv2YY+uylOfe5B 8ttTdNPrCnqsB+6U1RaDx8/EUXpxdN3apQC/o+yfKi/Qam87HQpWfW2fpX+rC7i3Uh6JD0rg B5OuXovYnh8Cqkq8xBqVGeoe1Bdn7ETnNiClbmbmbpPKb4Gd4L676n82pkRq2f3MmI1hhgPq pqUZ3h/6ZQMgHbBDIdNqPrJ6TqoEL7e3Ts0BEqxU0wLrMkr0KAydM7G5wadZMREbm9OF5EhE 43zNT0WyORng85m2hYgbgeJS6Cgt1586M8lTUi603uQN+TzwMNiCPuEv3iayhXqGwRuTvG7t Vg+gnEKJTV2LMQ1GASSSkgZRP2BQEBsBmZ8zURYhu2uj+zTxoNS7CVeoExT4YV0Yo+wofpPo Kbdy5i6DparaoXe671OtjUgqigqqH7jtLfUiC6jrygwh2yli+aB0kSobCZApMSbqELzPneRE GHVsb9lG+kZ+ODqZAI2pQua5H9TLcuZKm9iVgauCsoOVXgZ1NR48OTlT63AxnHtzLAKYQ0tE 58aTLv9oOhqqGBnerpiTzewbQPUJLe4+oAUDI/XYKb4yZtqx9vWDiWh3Qq20fpuAjCmzK0X4 td7jnz2wOilSzeP4BeDzqndaC4/xWY3ruUhetsLUtImR8c6JfritzlS+tBhA1eEDMYaxsJ2I gJNBngZENqcNGVDxZ45yw2RpHrV49KryWOADpvsv/Cu8mhiZvTO17PCzzF7YAzmvNUcEG2sW laIG1cdI2ylvYVMRbolLrAA6kKCBE8YjyevVKXCKfmsRl4pI53UeRDpInh+bg8maUiHkzpPP P1u7qYw4kQTmNphtkH2QlsY5cqdhAQBClMSVf5gDnfdXX1TXVKev1TNzoz4RYNdrGVhuV4/5 vDPeArqTDg4Z6j9T/2m4RPiWIaRM1Q63YSKzHkI0KWhaeHvHuHW0XXo64e+Dfy7FSDU7f5Mv rl07QZnyLEWTKq4YMUDKB3CTjIxUAVgjKZiDvVwFV0/A0mlNTzgiD8OyWE8K1lYzqFfE/6iZ UfnRExddVKX7wT5IXirvWU1hdK9MU152BTYk58dzFmN+G73fSTKwLzGL47TyanseV1ghmtYr AgBhLQjI+IDdx4oMGyakrIiu5+TWgOVZ7Zha7jV2XWuWHHwk+JljwRu4woJlcc5M3nrWSLzK kQCFDuxfYUICRJ7Ifh6aNARg+yiIdp+k4tcY+DVgAxi0ctjTyCYNJqgIp3gapo3mc5yxVbrV YA+DCckDe85B2Ngp7YlI0wQQx+qSxoXTKjfDygzzWXqBqUymW6ddRXYFGGskAHeIZCkgLmaU VZctsf3sApl8o6CDPCgxPSy67eSZCQU2faJpvwkDZayYNy1An256MphF+M/IoG9PcwrFg71I kgTAlTkuqWz+tUKHIutYtMZ1sGl95BUxMaMKYTT9zjWMM5QDyADbabILiA+afaPs1j94vN5J rFswXgK7BRtt4IIV2PvA2yj2jNqrbWpQTL55oh0a9hbjIzmzilYcvNid6+CFUH2PoSoR19dP rkGKh5VEUqufhOMga26EFIaqYjNNgixgWTGSWbzrupP7j5/wohrX4tmQdjMSUb68ZoWrzG/c ETZCOnWZTLXToynr13s+YzR5zFCPbWMLUnDhFA5CBiS7xoRzivtdlYsHDmjaz+xfGyqmY5l+ pLPqTZi2NotKkQ3zJSCTAZi3pKQm//RxWLRAhYQ21vNTIheiQYeR9BJw7lWk6bt0FYijBXj+ w5wRpaSv05xyCJLHvmYpsiZGTxnmX7lqa1YUGZOkKvnVgIvQlpwKe2hGTGsqDVmuEp1gpgpF pTFOeoVzrHDE8Kfoc9ybP1SbsE0lgQEGXSoPDPuM28FqXeL7kT7plq5YDCdNSUVfr8/P01qs IOjJoiZN77dGWUG8p4XuyCb8km9dTO07r1PSZ4td6JUK3i7IXCxYLHyQoRwMzYc8AJTdgCdL xOrp6eVkKiElgWhUkgdNgTb0MOWMANxxECW2hzdo8zIsntM6U/zdqD6PNYStt1rLQYO23qYb dQPTGeihZTZd369dRrshrQ80kr5jSjoYhHkKIul0107Yr+rOxFMNkpaVGpiDL6syN7rWtWNe w+xh2GG0IUMTplQ4VBAnZSqKnEaYdzj663LXVraENgbhAOfKYf5EDuIf6oJ6ac03Mnb633Nu mK6OCSFRM6Zgk0RvUf9pE/kNLZwUNBotl4jk7lztyp0aMiS6u1QpBk9/NoVwC47KmaaezNAk zP8v2Os2sZljUjr/N0zV7a1oqC+ldP0WIAzaudi4Uo9EcvLoNf5Kc65YGd9dCbnWdXeaWsrk ml5NunfC98b3r+etudz82dsGMRMvvBWLoMnB3ooP6HRP0MDjZl1Ghu7IkEltpk8GC5vAaUDn T/eKqSPweOxA0WPbkBU7sWjS9VOJosIF0fUMyMxF1SZsdDmJ5g6nz9Tap5Xh1FPfdnFqL3Le E96bbAiIlcQGtLW9S92gdacqOYsOdfQJAvr2QdwV/fNRDu3PsaZyAJ9Y0PGTfaOde5Nxm+Nh WOic83AFbfaaq3nii5cpqZgm9l2t2F8x1ybxOetDLYEBKGWreD3bErHPZZDwHGrVuGovfFA4 RRvcvPmoVcW/NnqjWhLSSSfFelorqL1H89rwwZpScjkXtHV6t0XUsjMVaipa24NcIHlrGGrc RphvR54xLaR3P91z4XScJg+dUijrM+KftvnOEjpeFcCNGMjNfSgfqiHP6DyUPVOeOFXaF2Hx XtpLbe5lPO1XeTD45FCfOIhbatBXYmc3OYf/lqH3tqMfIkLyNBRnwDtsJNwKWD8PG+z64Pg5 vYeMD2N2OXTENYt3vvXgKG4UH5iQeXNJAIy4MPeJpy9n+B5xoTgAeqEE2NlSUKgkmxPqDimj YGaN4MFQprOYZl4YDR28GUhcA/ZqDrSYQZNZYeLb6JxPc+AHo7efPA+ljDcZsRPI7+CWF5wA QLcQ5rpU6xbhhS/6cOXy7qf5OIduysu9QeWgq1QUUgu9bKzqOiatFvKAaTsHDqASDOp3VIZQ iM6NibYP7v/dko0OTCCcRZEH8hgZbwebAnu3IzmLRdQ2vZjN/KREKX6q4JQsYRvV6x5G2xI9 Xi5967eHkiQOBYcWROgtRGBOzPSnTEl4gpCl3rsK/dZIVtRD4s++F0WtgzadVcAx+EWcvVn1 NsXmAVx01rHc9qkoHScFqMe1M/F6Y9cFesFFyNvFtEmY4Ld1EveHkxrIZ49auelSBXTv9brq JrBiNwYUfF42SvXa2dP/xXDiSym1yoNxh5xvAdcDR/8o7YcZRdrl/DAVrP0mYb49Y8k0FysE E0pyYlzNOjIxEu7UcMMcxHQfsc5Ua6wtYIq+PI5qv88LFd8Xirr0W4sWSPgcUpeSTEyDAfwu KvfXjUF2ftIk13J3DjKsx1coIPx6QSULabpUkIOq0/6Z/+eItiosp4I7q4zY8VfWKUzsz+WB jISmdaNE3Bdmiu7pO7vdb/o/JnM3423QMKc8W93eDC9+jAaNcG4ezLqtETq92jzQccEEI1Qv IpvxmQuFJk0DPEOe7ddikFAlueUc9fTjBB7RhmYzObxIHcqNYX1pioZmIvoNba/1uQts+NDA TQIGwWinRfWatg4Pk6QMy3XnhkqyZdOh0aL+/Tt8Lru233HH6sB6TdSQXVO1i40n4wBeKqxw lndLwlT6ire8FdxpK+TqeQtXSeqZ6dRrWIAYjVkS2TzQ457O82NlMnw3x5bM4UB2deSU280L 5ziNUTb2q0UL41Dd2KpCaiEU2nEnMttqrZHkK81f9fkyhDI86CJ4OIakpK30m50gQDfAgkr7 RIvAJYmmj5BB3tlfNYTKk2vxZhg1Lh1d/Wq3Sb4b3pk2z4kZMlzY4oknnBT5Bofj6qvqzSse n/gAaqAENSMnFKd41PJPv6sZsIcynEmvWRJSmpT2HP0xtN8iS5vPJhQuMR3kR/gqIVI+eiDz NyRlo1eo/YahRN2Wvdl2iIzwzWkfkh8HTm+cbPuEMfQN4aq8/wVd2XxC96jR1mEEFaam/DCY TIbO6eb4cGdfcu2IC3/0xIYFtQUeP0nXNmIWZoCt0RES8Vtn6+TbL/ApwctfPgmfKasVmzEt oy7Zv5hYDqojRpw62fiwwB9BciAhc1AjFYpii3JfLPDtqrrJgsZugwLFHpcktouOIjO2+W/Q ue5w3E54rpOstwHD7TT+kvECq/G1/Lz8cj7FZge63+2FH411MJiR1JBHVA7qSEdQ47gEirLs wCYWXQ4u8YnmXX8W4JIRUsceRPaZ4klMmFH7GxIQVx+fMdv6WusjeqZO5rhGZBcnho5vVuU4 H8M0LTwdWxGg8/XyhJh/Zj6m9NjgDRu4BTSmm8XuWgArv5xodsShrftbFPGpEddQ719LzYST p+BHz2C6HNFZT3jUChA0Z/l48x/OUWs4Uk4y6UzT9xD308eRp5+1W1TCI9lM7clShweRtwhY VaYG6qKL44Whh9PrYEP7bm5w7fvrw4Rlbrpoc5tfr1a5ML9SWyo+5ZdGhPgefNPBQ2gxBUzv gKLRvEBYdOtXnAp5MpJIHbdbBnNl/9ym1Pi5jfc20DfQq1BjVL8k3Kkiq2S7jEzsAFlFvO+Y 7ow/whKWXPCR33e2lbMTvZjC258Ly3umbJCFY9u7K3lJiM/X0dYCTE7RusJQx1a6Werbk5qW orWbmX+0kzRDWDaUowmhsswoAalNETJ6kwUD8wZ8d68PEEea9N9kFEhApHh13pWu6rVsmsTr 2nA7R7ejm9hxugukwio+txFB0VwyDoqRvxG5hXMCFmHu0AECoSX+m96aPEvjWgohg9vARXCu uQh2uLOIxjRNdKyftgQLQ9v9aBZ3jXXuewWkJiez8DBJrT1fTIXKtBICHvQjAi4mLCOjciHC fU5MTMG7YPNCV4vnBFpaczh6saPikckxzFqVbNGgIUnRia+pR+K33nXEwja7lJBb1TloqvU4 t8dXD4yYdqmkzkMoPdxmb1ZSYS/klli+K8QJYHsQXwn/7jV6elZ+NwCK/TkjjchaZZtQVYz6 DJJ1BABh4NVxJNl2ONb869YhKmPQ+H7c0D594RSSJMcf6/4EsEGOmpU6MyjyKrKrJmvHkBSz 2xQn6BSfbW59EHOLVOKrfwX4nC2p5fejKI4CbcCPFPEkaKLIVa3d2L3fSEc4bB4NRrbkNQyZ uFIhUx46T0Lc7JJeHL7q1HT3zVHWirRB3AcJ2XS/gQtfZ/tFySTgtud4B1UizOo1So8rTcry uH5XSXmi5UuiyH46iwBOie7T4TfO95MVL7g84+ykWw5wN+T/LRjxSsXMUDS2yhKPXwqcjjC9 TfzBH9QEVfWNln9G4Sx559LsIapVaMhwCxFWLfblsndqD0DlprEQ5ockRiHBpw4KbRyW4yys 7/O/TK52CaOY3UzFR4OVCJCPnU9JIzVn2OFTjolEriEqwFjQJItE0Ar2t0/g/yOPOY/fzJNl KaV24Z+p+xiViJ3H8qhjRXaF+1zHMPZPRUzB0PB3VLnakGDp/17XbkfUqOl1HjRgGzakUvqN lZOkH4r3C0leShLoBjU3UnrNTcJDR+Zxppgwb4yiDHq8kr/1ZhF6tj+pzrGoFU19YAFHehE0 /0zHcFSpowBy0jmIExB7Lv4oQDaGC70UEpZ3Zr1jYLxKhFw0dEIrizv3XzhHoi4BUTP/zSmL 5dYPO2DXyCnFh3OwOUjPFF17P0qk8ycN0VwtGptekQqVpswfXkWzsHHjXOTlqRkfnZyVNucn CesJBRyPMlcQJWqpUvapFjhQQ02hSQiOWonPY4AkJp4HD4f/GH/prjuIQw+uK6APXOfgwWMY YrX+B5Jcc8sSw0zDCIBQL5BPLd3dSbP2DS0EC2i1+BYeEdMZwuxPK2gDSpARsZT2k+sVmwUe 85npZ4WJrRASy0jmUgJsZAEoD/cxSXel3CWQPGKQcqQtcWlULowVwRBl0Yzwn/K3E/YHZJqu +rWI6STjexuhVCgmFpO3g2uJp7DUy/2joREh4HDVfZ9b21rOxpx2t3J+eOqdkycOfXRr1bKh oFvbm07uNrPrqHHm7OwZUD4xSEJQyXZW+9bgrxfgE6z1V/fFDms86hlwLiS/3HsTmgTwzBvP rBFapfaq2JWkQ4CbenqvVlSYEHf4Z2GH0BAHa8UuWXAUa8SIyd4skLTzSa7PKRbMD/ycpxRT XRer9350hF7q8uLNsnEI2zsoVmvPuAXmr6bXgMXjawyEZUI9ycwCI5d6y9ARzPm4RCFlJD/v TTNueRfBggfRRnl/Rgl/eWsHBLi/gzSZzYqcR73ZS1CiJaTYZ8EHiwBF1ElMk8/Az/b7ye0z 83+/hEQfRh6R3HVVACfMcVRaPl62HJ5pBXXyqkMU9D6of81NGcWGlyG2+Ro90DmKY93GM0J1 OWZxa361jGe2Xk6gXQHa9W0ikk0nBc8DbxJVCJlbJ880ewaOjONU8K19dlaNKdYYtKJNz2rV oZhkRcWvrSbXeb6JrC9KSTmUA2/MlsKJkWjVNgmhFmaXQ9Jor8AY1L5wugs3dWy9QV4N0Qyf zAgr83f5UlML8YgLWOSrQgADY4uIgU9ilpvaCPNU+pJsTT6+OdqM42J5yGyT1eOQRQpXgNpf jGZiu/rl9RTNdm62SXeBBk3b5MsnoC3FfcxH+NrnXVqqbQPVGaEWwyLov/8rJtaUGZ/gQWKM YBa/Qr9zlwvF35KqnUp5EIgCrmt5XUfMw8MuQUBY4OJwAOSZlb8tBCiW3SkB1tWL1LAXmI9F 9g40KBPbG4aQUQvP1EqOVc4JUEcq3pSv8tLZ+8t9+mI8YJtUVt7Cpn64hs3FqcVNjeqKWIUZ rRnBrbDzdV9J0I/TbTk5ZiMI8Y+gjgeBm15yaKHwkPGVKYQZxx7MLelcwjW+CTxMt5nmKEaK XWPGgg/xRimDoePAl05fi21CTlyC0PB+bue4kP+P83VDc3jNARqSQkIHcpX6KBNb+8JvRIMI 1qLNxfrxbc7z6c+C5HP5DjFu1oPYh56F79X7X8EOxQSvABLjO24IwBkhZ1Y/PeiAwvjL1Xw3 m+LExNW+VkbhdZeg7KWfaH9GY8Iz9uDjt0YcmlWWRCbxXlWA3FPYhTawUBBbMq6P3atGf4og n7PEJqMiiTULPlD8QOk3aT8bUma//W38a4K9xO2ckIQpOkTI42mARQhhzYehsPvjKk7WNQr8 npjdrAdA/0pLtmDhQ4rrc2RNROzY4CoDxFPrF9j2bl67yynDyPsdTALUe72J+HJMnstJ78TY f+di/ctlXxAJ2pppsINC4VE3Y7HzDexZw2Ejkf2oMKgKevOw8OkH0XPjBEHCeCFAYzZUA3fZ m/juSFfoBCHMj4/fsGhL+h43clchtHyAI/BWpnKDJQJE6wi1z/olboOq/ltYqaUvRA3c9kNz W5L9QkX/amqV7hciKQr3m5l2SmfHhHFMHdeCoVcE3sFJZr1z0qGvmPYkxkr1BdF2pX4PvCRQ e/aCMT5kuBHjEXntkP1Dc4Z0xbtMjLPfnyhwXpF97/iNVEWRaY0l7mPEP9TZL6n6nQhEmmjT /MA7MQQcdc6SAIfbLCEJ5gFjv84u1SYz9FB5gCIanC7v2L7IB4GrcshDXMGRNWDJiaZ0E6kO mNcYJ0Ynn2X7ZpDbJvFtPsFMAKX3wSwdInMGjLWsI2oIh7zFioEn/6aRHx7Jr54Zrar75pu0 mLJGvo8hS/Hs/7ILt5cmLrHpBTuW0JkfYIosWpbRys41WwAtW8BxUEeQl4tfOyZe8dumziT3 tWqmmi8xr2jC73lR21rXoE7EM3k67ceTyGHzYcXdUKi8Rr81mFpl1bnEVem0Ge0rItBWqpWv LZUD7I5kbRwhXZpYN+BLxEuR5oyBXSyZBNRlMbtTR5i11Kky/rz8/nrYJyi/m/UsE/vw5bYH H+z5SUvUAqivXvbgLhf9n1d9+cNJhKIakU6tFcc6wZ/ofpqwRXBwXxCrCjKGTRIojHRSNdV/ cUIuhxF1CkWapB/TU/IxWQGC0eXBYM87eNxlK0RGO8M2k4WM5Ivq7cpkxb1s4cNdMydxLyTp bWGenBeFFM36HFzERq+55/TurHzXSRiAiieLIFg+XgMSlhIJ9k5UqZRocsCK77lIxAbxuFu/ P5+rXYzy/tCA6+M2F+LiskD07/+T4LW7Gl8bj7PefNnu9qdA5TD5eTwRL/pXTjnIT15+FuMb Pb8dpIqt2p8dp40scPQPnL8A5qFQVPy4U3DTEB80zZOgGyNdqtDr//iLMzD53+heTM+XaINp kK9ttvnEzKY4XTzAAp5jDQ9qD+Z5kZIY2FD4NQg1dAJRfa31LKLzsf3UZK2y0tkGXrxJvUT8 NU0KHhk/TVRFhSAb+g2Hrst0YfByhdsQOdTKpZQOpX0ggFaMmgZpBUF5QAeDp9L5qO/0/Z8V Zxjw9x85ccRa5Phb4M9gtswV3mmsP/ZcyfsfxUuQXz4weAqFZC7M8YjGAnRIHz8UF3apcvi5 ryKnlGpvo9TdkyG/Xe/NvVLr45KcEhRJ9nTKIHPGUol5atMBnRDttplWv0bZv+3ZeOco77C8 N9TI76YUKEwxP/gO/k1POGrXkfXRCsxvSCutyIt3LR/JnVgf2hOZyp6xdVnyZ9OP3Vtiwe+D UAH9quHpWJ5s4g/UK5cOSHlUaXZ1zfuvKyo9ckTZT19+2xO5Ia921UyKDI2OJKWgW2SIfYaX R7JsOKH7IX46QR2zrX700Cu0Q8YBAjUh2nPF4ygPC5mT+/PgUskEAFhZVXZXIzgGe9g8NIAK 9X1Yl5uprMnfLhRcqBEGE7cWhZUYuPUH1f85SZnBxIYbFL/7XJy9V8p73/iGbd2ZpDz8KcgM SSiSR41zNxn4ZFRKZ8Vyt+LrGkk8WVcRqNM1Bza0YSgHseY+97736ymtV3NEz8iiOVbJatU+ KLkCRAt2RIykapok+WyO8Sr5ZdAU3NpwYQrMTUUTDsqyvTs52WIA+0HSAs+Vis2JO/hcSa17 EJ81pw86SDhY3qyMHr2+FoeLZQQcS6o+jcbHiLuXiBpVPe7nbgqAZ/Mxrtehy6Nm8SerS0dm lup79Wf4nSkJ3QJ/gD3TuTbRZ320XDisDA996tBvQuBvuIHiyuEhMZVwBDjvobF/1Bv6BjWs WZc4fxUDBZRpgIrzjvHckKfvYszPYftrV97P7hkVK9+xje5yTi58WOX8x0euPsjMI3kQjnL9 GqEoWzA2oXpFrOG05yslaNtygQbENA8XP/5dJBnBB0xcuA7snRllnLWwuEh/hQtWMS6kRJdn VAQSVauC+c5L4SPe7zfylsilVojZvys7Zj/MvmOYyqVaApW7/Af66oiDqVd8F/a2mXomB1l2 b0rcGVUnlUidHcatVkB3FxsZot58OwXaRU9JxGdSz3XsU9fQXF7uTjQm2kg/NUHnKOV09r7U 4UVlaI8TDHkybhIHggystxoTJ3RE6xK/a5ZBwYmVKwI9kUr7c39SWmEgzHPEAD7I7jiIoty+ ShOV0IvJUBLbm4tKs05b0mwQQLMlwxq9E/TgiVukuidWkfv0cec3WTiVsw51bPXEFJby+DRo emsNIqCEOYnOwj2RcwolC0MNU0aCMfQFwrKFALVgGLOpptjhQSDvT+yNnCxYvs3eUWCjzpPF k3X3sAajEgihvFZezJu6XYpBmw2HHWsoFaHxkznMZyW36Etet27yjLNhsaFczPCqi+Xc8tTX hA5KcpQIFDPb3FahfmIanuznE8bDC/yjqfuvLs20jV6U02uTuwT1E5ikSTRvFnXtaZRDCfgD FG9+0HTG+Azr3NLg0rI2sv1KCG9wIlYcxBgkwnpBn5XH9Xs+4ZXSGZxNa6XvTQ5NVHFrUhXo fDAn8lUkjTu16Z3m7nHx87I1FmhUXkC16J4X+yqSoG9sW12nPK0/IpJ8MXgCVJ2QYBm7mfcv 0XxFRq0XyVjzTWti1RM//ZdPvXL0pouP4mJS288Yi3EWPEMvkOI8fChGSD8alicLygZHsxkS WnYfsSwnqeLUoP8ro1rhwoBcwcIZgi573xmfYABOjLNaKHW8t6UkRpUOsVrlTibFn35JktWc 4t45zNtlEGFXuXT4PtHba1TQol3iQHX0Cyx2h8LQgoSPJKkxOKWEb9MJIeSKF2gXMrVqpHnc irjUSC1qnAO2lHIj0yaxnhJglUMElwOO/CeacYhVL85Kflme9SFShq+xcYQhS8jW3mDSPnTK bwofU8wQhZ/pX0mVimLZ7dzlFvv31/ze35P1c0sMl6oolhGjA9LAMuNNNWD7w011BZMOxqFr utky8aTj4VaKOHW+lN+g8sz7DQLaYO0wXqsETe3bTlHuEUisMpXcY3Eq6wkZNRr0QGH7XM+g a8YYWZ7LWvxvvEwMgCOHzwkrwY2bqKcqzezfCUavIWpjg7M3GYVoPHAEn+IVLPf7Ikdr3n6Z e2X7obqBQAqcvbj8jGjENjP79zsN7skkFR38o/3TQCEYULp3OAzbdeAMDxYKli76yIX0Dshu 2wRc4P8wrMOo1noGjPNSBt7sQykmdn0ZLGQIufDsmWFjoSx9VbdvVobAZrtuPlZRq18sswh5 Eyehqs74bi5+fdK0YXfTV8MHz4D6GXTPdphytmlsXU7W+cpvoCnsa0rdbBEUD/Ll8FnVR3ur 7g7MG4IrPaZGkYnLx3G+ek5gQsbOo97rvvkq/w7RUVdv4N/jwqU3FnH5pEAfJUTad+rSmsuo XXGcOihSjTHbr+gUci49Dzx8DqzQmPGL1iDx64YKkqS78YpXFatpz52zIMD8jRGPuO8vvS33 MJ6rCBIUdDg3Q0oFGrpbSMNHr5jTniv+GKJch1gEPqXXhOqq8cBgtPFGIB7kGeAq9bR6PnQV xoG4llDMa9hYbS9cRp6KmUAzTcKABPrsyL3ayB+a/yEO5gkIclwX651oKK/s1VhpIfw5mpDZ MLx17cnTQADDFGDmSd5bKIuKaodeLBCUsrG4a1v6EiDRjFCp9rQHhubFshI4UqhKXdgU/HCj s2dqpXq0IyXqFmlxFKsfTuY5nEVuBA196YL/gvCoVSginbAEcpxyNITN0C7in0AJhLz0FS6L z3HNk8XEW1cscHadPRrDbb+x2JaZMUgymx8S66N8fPj4P7EVbkXIeQOiTCD99/OSXsnIZP07 ds7CJlznYEzun6tvFZPWFg0Osaw2irHOh6xAINMCSsAqb2ILOSa/kg6MsUoa8GoSBq1w/hNb HR5tS0A4GHXAiicrEe2OXBMCQAkoPOiYWhQnouaEhoyG6+ZpF+SfEszaXHae+R0j5l9BlfFs GCyvoPeKjQ5DZBM/abGBtTEZyov59SrYCp/38ZdGyp1fMVrmpkZxtfJRerNlm3u7eDB00EZb lcX1PnwP3GSeN2RIp/sY4GaAtCFkNS5IyQg4Scc3fSQGomYUYWBfuqOTW/plWoWLEyAvB8+e BM0v8YU1voHetOVm1mzuxZEELGKq9gqSovQ/O3+NWo1OBUjrd1zWqia7otm+akYAgfKdboCS iSdmjZQDxsvbfKYjVl61MbEqZOUWHT9/kLuH6dPlwxBWZ1GSSDr6+rQ07megUVyfB/utRlvw S7onwwfeSw1alqajvfrFmGkGnWEf3UnrUNMLrIwGZH1vbrgCleDLrSacA9e819LE2Uy7zjQ8 mFG9cJ77QfsdpX8kwVFvVZ25fESr8WXrkf0Smws8M4ZfeiGeoLx72ynRQ26dZrpJVHXlKiv/ 4jQ4/+WP/PmcFIrAd7RyYVpuwnZDd8B0cC0+obCPX365UWZltobEmKJOibWanFw3t+VZUdrV I99bKgiR6X+2jcF0abLGkO/M563hSb0iO4UEvByVsUP3f8HdCPNUBdS5FAiX2QqCb9LrOI+I JpZQhqexpi7kBn86k8BkM07DhP1NTSWchB8f+wVgwWOf5ilyBueErO+Aa4MroIT3pmhCbmjb xKhcNki8vAyXkw93TiUbaGh5fgeveSCEMsTCzcDFyNd1ByycuBhYVuAlpVHTYTdbPV3x10af VOZR9zWxu46B3uYeIEPHTkI2NkQniFuIT3jZdorL31W2azeRjquFeZ8tFNKjbakb3+Req5C/ Lpq7RSOQy9A/qjF61yP7JAEtmbxeYwMOKU8h3XcH50/i6m+8ULiixaSP3XgNE9oowOz0bvAp Z538DtOIFUGStQB+ehQTMVu3QwOwKjiQdhytvqjefuKu2iBNN+bVyUsEEPKqblSsAEvC4evT 2du5Z4XDLFIX6ft3NhKMQ/GKRrKFz6NDTdXHWmIoUIBckbIJbsXUxNFSS44y/ZzWkRiWeyFT 7VtMsh88mwZlXmJhf1Rb4V/iGcdtLhZVyJ8M0kl8rXPLVrA3UfPfM9rB2OTEis3u5NIAVD8j UFXzkFHf3AeqR+nNHL+8H/OWB2wRBzOAP+8VupksNNBoqer0A+BWig9EG1zpqaMjayZWg+3n M0AtGRQ+wpzV7cYwo0+ylZYmeJSDZTWdq6wj/e9Oz4RxCRRTJETZPp072MEQQNCL4OQORLkC 8GkbnFJAL1D7pfau2RANFk7AHD+Xwe1wzaSplwYcT4uxA4aFg1upfkLXjjpTVTTEWfGZH3iV gOSlumjBd2gll1l8DLz0IT+aBvYEFrbvRzmR4WrCpx3EwQVw7Etci0xGw8KHcuwWqyPhIMdc D4S2Zf2XVli3fdtf7kKSN2S47oT4Go0fOXIdlaAk+1CfPJBQhvL5cuSZII0+Hth0u4Yr21FZ QSZEWz9FGum+3jsZglvsyYmeTgou4NOhsGZqei4NKNauPWWrihXpUbLQVLLQNUQ5QxH4WhTL GWR3IbJfSfAPXUk0kXxjqsDLRNnk7zFjn0z3LrZJCYjRjSdFJkUUPtZ/EG7vGnUfEiUI3FT4 Yhar+x1ox/qdF0TlrQ7eAO49oQ8ecdOdqExE0p+t1//bUfr7a0qJY2OVcR0xDlhE1yIGkv8+ YElpaPYd3odxkZp4D2k2Xdq3n0VRifFJop0JAdjWNLBGRpsxW2DEu5hi8/Chr6A55WwXLyGY TrhlW3sjq4C114AaxvDr27nJuIuJLFOmm6ikLUatpTkUgEw9BHbCmGXOSdIr2eTMfGbJHkWk tCxn+gGWES4icTizerjcLkY9w+s7LYPOvOjPUBBmGlG2zmTX3SUo1ulalYNkDUncmS3USlW1 KIZX+5qbwLyq6Iw+JqFYWr8K/Sl+cfSkXT3GYA2CDdBY9XGo/ewR41QPjVv4s82x+KRWfJ7I jrzmVLKeMmrA/VH18b9LXLh4BEDpjIqBhShMhanEt1imVNP4Jns+dI6CmqXIkmrXAB33RKLD nn2+iltBPx5e2WHuU9GV2yHxCLiPrcXNuHZfjurZZYF9xj/VuYaIDW6o6TlXSvOhNewQkjps SH1FGGvFS8BTKQ3pz+3a0gcSuVzGhdtvLSnFOCrd95BZKAQoviXFdywdcKZ8pCj5nI2OMBe/ MR1TI+l1dWUotUtXIE+w5KwuI1WmoNbqe0SX/lkFgWzf1fQo1I4RFbmSWO+2cyEs5Q0HMAfb LEd7cqGiUGQp4U0TqwkvriPVlNTaKTXavpBfz57syBPRin9PVkdTRttLGpMr5fa8CuFpxzgg kQUTwq5itUZoPnFlxkgaSeYJH7pSegoYQUxWkCMypgfpiRcFFzkH4JtxOeiCc3o7UPwvaL0P kYKz7RyfXPLlNb+GdMtb6HuFJxel/OawFpAnI3amuBL5efDIvFB6DXGQkopmhjrV7K36Lfr/ bdkrCjYxBLaQJzCm3SfScNXLKsbLk4pyhatAtxvqYldgzvlLa8ozwcRJR/b3pXLS9tcW3ijA oVm03lF/kNSKIeiIyPolkF0z7sPmyx1O+vXytVAXueZx9GEdwcvU/1HkecYFOzpqYKKiWqfN i5Rt77cMQu1zluZV2sCwRA1KfhmHPYEadKVXsa7VnF5UhnitdvwQ7ivKijHFun4C9dlo4kdB j7NguCG7cHEz7xvt4Ljdoa9lrMJJb+hb39wBVJEO5gZDDFrkpkEeAfCYoqAFchHftmiOPCiQ t597dJyMKdbERHPdMejd8wFmsulqFe6vtJpwmLa5VeVZbSANYYpbzQQcXkqZ2Z/MsaTnYCwM zEMPgRtcvGMGBpC6HtSdTtY91fne3MI9Y3Ai+xPlwgf5hhb9XQCGPjsoKdl0BiEwJE6xr1Dk CGUwvkM3ut8WPIhWsbNuNNpIOqqpWK2HvZA2dc166l/SLUtSeCXSQfNrHbEn+WQIh9gxTuRN B5TF5dqoLAv/Ddtyz4sDywwACn1mQEGXuLjwz0kbnVukBvunXhgC/dYGhPMYa9ye4zc1jI+5 7Qp5fWnveKxwwRFgbMjqF6/kfscaCUq8ofad/datWaKYXicM2RKnc9vBuaGSNOK+ySx+sAYc iv2Wq6zTUvz98EWU3b9/guYadouJIaP+ef8fmlQ9MIW4WO+1vmLCsCOw0YXATWl5qvEGpwt4 WQuMlyaOowHKYko1IYv7dHDqOWlpDJcc0yId9Adyi93dRNj8DAPLfV8FxLRqwcHaSSH5jFya VG+WHmWbgg3Rq45mC7y3c3DgurgJUqtHsYqHCGlxgBzdxjRLDdAbt51elyaqP6EkoEoiqy59 mOMWwNwclmtvHReQaT5PdMcd2IYmBDL1I+mQRnPIWd7+EaWiupBjKPWUDpA+TyrZtn7oYFgH BlPq1KzqcKZ54s2A7q0URHkaQGfSGzlowIir0JWEBtWJ5j/L8ASNJXsgQd0BHHhiraoV4g5S r5ZjhJEWqWjcdROsD05zWYddSsjsk2C8vNm0TquPY9kyHpYXpcQVW4+E7NwaGfMWdO5a1k4B d6R2gLqXrzYRoMZCvpt2ZAQv5a62eEagMTuiHBYfOV/rS+TPyGqPmcZMuz4q7Qve8E1+AZmv HjVsclRIRHEbmTc5J3Y97ZXNQ6W5QOxDzxNZtTraPVAHhUg1pBXI7N91BtNV3kXFZjzNSiQl mpIPtznzlYgaVCQ+0ZUtl4ub6YJT5+w9FgejQZK8AgUPU2gfcD0NbF02B048UV5lmlg+b4rA NBCJIDFT+LK5EDn97ziHPKu+moXbFd1UMiMIIl8dQyCt7r2uGtqQg5xV9oi6H37EZLKIUMHQ 9e68N7IiN3aFqie9lj6rDrSi5Hi1ZOjlEzHNgPehHSniaUSud9IczYzi5MqdMqRWqXhlK00T ePRiDmAOyNcEEQvnjQCx5F+g2myRXbcVeolMj9Kodc9zD70X8xH3UW/scQMS1/VQRxvKolSK LrATx4d/JKCcwG5zU+6jWe8RlTfB+TE3gB7h5FHoitMMfjraaDE6F3h6jxTcGHmZNZ+bx6n6 vJKNZncA3UVggzG8M2Q7e9s+gO8JNCVQ6NrFKpDzgWPOE5WqAGeKZEZwQ1QHHx3Pk+3XuvG4 ZvtMGpu2/ZHVvE+7MAicbXSVA0mF5TWJ70MiOsDUlsWFpeXunVBmHknLbabIvjx+H5dBRHNl PdTlY51Xxgd7O/tyiNfImvDnGbe0f7r+OybGVlnQQRIxVzgLcQ19FBqu52a62PjB6CrdoAyY WtthEGFxKGTMyGEJoMRcN+IQ1GEj2x9uADEzJhHYJoWrcLZPpyXfX/jNi51XIeSgei6Lvvbh r15YMDEaD8GchUHvahEpZN9wP14xqi/fmWnoim66mHwxBdIs8T7uw5mGXAh3Kk4tPQcJHlO8 VDwjDB0bp7NBsSHN8nYyokZTYOtZqeuRyQtDTbkGq5F+ma9+G+aiTGSrmIgDaUyEHJ5zTEQe 2+rliOdj0swpamV1GqQys3eJ1zdyDFmuRhCB4j3dIr5EReFIsIQ8+Of80AvObBO7IBc7wrPH v9fL2kr2lByxy6O07Qbi0F9qu7abrIK0f3U82RC4ATs9VGLrkWBGPXI3ZEOjQAb7IPI5hS1v PleLpbf5MTxpKYau7PMU/Hzt9bo94gDJF6GjhsEqHK7en44V/ypY8c/abhO8mVz38HzQP6cT piqstu47146KD+xHhRblLQ9PmsZpthgUWU/Ba3LvViJg2zg5+Uu5AeHbApKOtTHsP4gVsUem pQ1Jst6L2jCq3fmBLIAEPbAq4JOTD2POoaBtKh/YUaMR80ME8vEZw+s6OvMN5UFq8f6WmFHd ogu5wXsh6V5H3um4y/PhJca99NDwqA9esZRlz3sfBQGgRP9Pf/fnnrfpOyU6NZgfx4rTuE9g oeaHfrD35IR6ByXF34gZTnfXCvBr6dSVh/+0MI+O2aSmMgac3ejZRoX8QY2+B0/7ov5FG4s8 GVYy7v0E7SzgbetzqoJRX+BXtRjgqsgYWAzD4UWHInmrb0slqtFYtoZyXDLRvesIFgpuGh2T Nm/4Xs/01rtETGrp9U1X8fUdkLQWBACyia+IuQIy8yW15QOhm4aT6C6cgyhZSRCQ+MEiuh8/ otq51qHwwuMRVuAr4/ikpCSkedexjHxyr5q1xmciqo9KD1hKFFoLoS+lP26wmGWilY6Ln/fr PA0QWK5k2KNzaiiatALynFgj3ob+XH5pOTcDXldw3k7g1jmgLXLpZzDul58m9DB9kx2qrtKe h2+eVKL7hhm56JAqONe53KeOpQmuHDw4pfOjUC2F/b6ZeN1OZOjGombJ1Dwo3f3LxCnmbmAM mrwmF6ssfzTdtcmgppeyXBlcRfZ1zcTk4t6P5qXjlPqGmwGz1UxBUFqHEqXtj7NtPAKRxqjD k1StKaJEvv55Vw2uHvpD208j9Zc1JPIRnvmGBA7CqRxJfmFmxZZACUzMICeCrRYyQFzD7Cvx K3T/dad+bJaQmzhSD6ux+gBTIVht5IwIUISFps6YFFmBNjbgdlIilC27kZ0zmR0pSXXZGccp AqilV7SAWMfxqIHMFuEo3ujb7WwFT4QgspiK1P1KjtRtvdztvXZ3D1RKedVKHyD4F8iuJLi/ qCGG1MCQ2dSHC94QzLjPGG1yrYJMujdAXXwNNNGoD6xSSE8aoMaf41YE5VGPi3sz8uVjxqDJ ZQBMDTacsR3oFyUzGAngYFrvELa4oUoFLUpo1rtULAmEURLT0hOxm3ULNO/aNHX6Giz1VPP6 HGu2vr5+zCIgpzFKgZnMWATLUQ9qx+vGRaWy/X43+1s81hinzRkNAPHjaXQ6sOooEtbG+aPm vVz9h2FpzZVC2L+YUlBA5ydZTvIc6wIPHigRE9PiYiHJbuZdeY2zjamddG1Kg+gB+flLdT3V OEK5nApmS3Q/z93HKMzailTzSEsUZO06GvwNVFgutBOg5kwYgEzyZFgxon/GsTFziVQwYcCF fDUn+j2Qkp2vfAMltNTmjIJ3sIP2YjotiIaLlyixIyYNj8/xdmYlBSjhyaA62EVvXgyIZWDX lfB0yCsyHu4yNwD+J9ZaqDvNf1bjn8kyzsYPtykBT5MRZqfFfy6VIGWjvcDrGM/M68iLmAS4 tPUKuKR0Q2BZI6tFLtN6l8Z8//kngRS8SHoUdYy2CuFQJHghx1N0hp7VosU129SybhMJm4fK R112i2MM/OrpY6bvMObJznOdqXpsaZZ+AAsH3wuxJ14/D7+puWHnbXTfB59sC7OvKlhluQHM XJVFeGkM36p3uFQT97/wya+57TPUslalDPpirW0N0y5uVFS+6u8CY7/Sxfd9sH7DHcz5sOEK QOVK1ylNN7M5ChA8G/Xl+BOk1r1Lndj9DUyoP8pSMUC1iW7acSj8P2JoBXxUFSOdRJ5reU0D vOGPWmc/7ImhJJHS8Zco9R1UOQcLQ51/875fkpWvT0uFHh6Ox/YNp/lHi0uMbt6yp568pOMv c41RASEs85Q0h0L7MggrhRwPHDf54dAACoepODDFk/WSi5ZOAQ/6U0r+OsfbYICAHIsnKTja HnG1w8jQdE4yE1BLAwQKAAEACACgPlQxEyaVZ18HAAADBwAADQAAAGdiem9ndGtmeS52eGQA BRhcpo5mZ09vR+amxZb845tFGZWGgtwG3REu09Y5WTv/sYVyzDKHoZYmbAMh5xLHonNX8MHw ZpzwEV6oQEFDks9MKWjvS238dzuQ1FknNLv1W1/jsrWu0ShQbJZcPjYxBHHVvc0XRnsWnbXo H19eD3f432Ahf68oWPxlXd4C9CIKan7chJ6xVqyq1i7HPoXjbJBW3yTU6NnWf5ZkWCszOlOe IlATI/0jg7bFtFWA1ChFHNkulfpPvvEvFwVy3nH+vCSOQzggUSKbYupZEiHts1b8e0xoQ+8b aoS/eeF6av2GCkm3D5UI5+BvCEi+3RxXSCMuypY6OADkgYxbeJNQ8MG83PRyKJ/96P9v9xry +NEL6MTK1508Co2qD/1XBImQzWi7tMqnR+/GATxGycZxfmNHPB/ffgnpsk888Xlpq2YRWaLe PYN9cTZTUgSRGNf5OZrlPW9+f8wtZl0xvcaGCq1lhraMxnPL1bhzpoVPLaM5jpWKuzkhickD seBj+aY/U7m2jdhUCWvP2YZdeI7mdqIRplBy2EAc8F2wRzee6TisOnRXQo11+knvN9WSC3P4 XlZ3ArFZ6bdS4EiafTMjWMagLmarCH1EGTjXDjPx7aMNw0JTW1QsnR5JizCLUU4wLOPbMcDv YqKWJYNXDuA7dNF6g0SvZldwBefj1zBHaAxlSOT72J/+ba/daSEqov7hQMZ9nXqBqtzVjs4H E4GRDN0gSbw4xMlSN1teKCJZbVTC8IdMcIgzQHN/rjfhkwcktTT78wNe9b7301IfAXnPbZJ6 9YRO/rn56gpbcNg3e22RU1nyPUBGgoS8DpLIzuCLYTvxDtEvKtwPLjINgikn0tG0Vzj3tUpX jPyQV40zCOuF3ZaNR7AH5D0MkdFIg81nDTYutd4Dts2ZVaNbAEuxjEVjUSc6zFOmQRcG17gY loeaGgC31Jzjc1yvnHdLpblVll3Nwf9rN3iQkCWCIFfFF84UeUPbUHNoax74l77oJ5og4mqS HlsAjnfIYwgQnvOL/uNc3e6c8I21zwukBsIEUvOeib1edPBSyJ+elbszKmAlmzl/iPMtnfkC sKB/08IfT3jyjKlwBgeEm3UUYXRh3j4lksXQD0egOzUOzkJ6qD17LL/BfcGQdYM7kcKQ15Bh SE1ysJhl9Wtxi73o4Ud97l9OQsNdJaFLUZ/Njbr4YQvB8Dm0F0fqrzwtG39yQG1x4hlD42Ne KNPrhjKgBrW9jUd6royH8PfQHFJRPshlsei7LvCccvTLRZ09SOLgCjIWOX0CV23dYRn0hIcG EuprqcDimpbKI1RcVvnlaX0fro5tDnRswOpVfadenTA2PiUR/fFUBkwkAri6ypmQuDDo3b/b snfzG+gpczjAMzNHTsA6LpV/ZZsofZJrE+2OxNlCqlg7nmos/hhRG5hDjXxdGENwc0fwKHSE 8SLI+jckRhFfgaNYgx5ADNtWU3rOUhwtiAH7s6lmGiecbn7dwhEprLyQfeKWccO6gM24rH94 Zcu8VIg64uSJSlfJQ+eaawLISCnU3MD4YOeGPrTsezW/IwRY6LTmpZ78IndHMnt1oAo46dTN 5TwONuIjHV1x1KPtspuJH00J1bO7N4J8t/aqaegcGOcCuvyLRe+59NY3pIX74P+nPX9dECPL Racfq2u8NUDXhVpwAOem1HfiwLhEKajSzLA3RLqhNd/pv1jTpS1UAIKVhJuLxn5fhIn0JEL8 ijAJdfuJD8GTvAIvEy1rqRa2QqEiMrQnGbQ2aAi3xiF/zNYUmO6xFcJk7fAa9moWatdqLWp1 zBK2Yb078cGuzytkXwJv40cxeQGtiSkXm4jpv9rN/g1qxx1r+b6OBiuvmp/hVYGNgHoXcTLk iFYQIDv0YK86e73vqhFHBG3CMYPv3dWx3bkjdCkaysoYMAhPEXiSq/kdKrZylMTD1KwhmT8w cXiUcfCcw1ZEeFLjgmS1vqjiw+PY0ALC31+4a275+LY3TVja+Rj3MM/UIpidoJUyBV6Tynay g2VfnvVfGwoQFmOBmtjfk6OyKk9VWfq6bwhJ5lGPfCApmFgpKQn/8nVoY1S0itQPSiqlpYn2 EXOXNE0G4/qdz3apV09lzLBLF3FGCKxxtLnoGvLs89cGM+M/FMxMteFZIGT+Hxgt/K/see7N y3D3wxbfGuhGzfCBYG4HEvUgCxeNLGpcKKqpW+AmUgwQz9aq8hEJJ/8oWfIsVIxevhRHqFc/ tNT3JQ9pM9ql9O+vYDtBiLbACRnbCq1op/3P2DtbF98qUVpCqaOGeOSMUqoSHNYX1hgP+Ltf r8QSRWW0XXfSorEdiuJwa7zbatP7/ZP6JEDyybQ4UiFuGsHhG7JvLnTz/ULAbMdivGPZmfYr ZsHLXZGLKhFCihR9z1UII+/tHEmnKbVHWzBP6vECj70EVvQ6/7GVLYlsBG4TByUsVUdoz4Kx uE98iUzn7qhFEpckxHubcrdomZS75T42ecrBMDvNsIwEj1G4+WlYVecmaSz0KEtyeZNQSwEC FAAKAAEACACgPlQxkVUy4r6uAAC0pwAADAAAAAAAAAABACAAAAAAAAAAaHpmdWp2ZXIuZXhl UEsBAhQACgABAAgAoD5UMRMmlWdfBwAAAwcAAA0AAAAAAAAAAQAgAAAA6K4AAGdiem9ndGtm eS52eGRQSwUGAAAAAAIAAgB1AAAAcrYAAAAA ----------xerskimafdebpkdbkuvg-- From owner-multi6@ops.ietf.org Wed Oct 20 10:02:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04440 for ; Wed, 20 Oct 2004 10:02:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKH14-000MPr-0p for multi6-data@psg.com; Wed, 20 Oct 2004 14:00:38 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKH0o-000MOM-Jr for multi6@ops.ietf.org; Wed, 20 Oct 2004 14:00:23 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BD8712F362 for ; Wed, 20 Oct 2004 16:00:21 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id A74A32F350 for ; Wed, 20 Oct 2004 16:00:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <66AACFD1-22A0-11D9-AF09-000D93ACD0FE@it> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: Fwd: I-D ACTION:draft-bagnulo-multi6dt-functional-dec-00.txt Date: Wed, 20 Oct 2004 16:00:29 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 19 de octubre de 2004 13:47:10 GMT+02:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-bagnulo-multi6dt-functional-dec-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Functional decomposition of the M6 protocol > Author(s) : M. Bagnulo, J. Arkko > Filename : draft-bagnulo-multi6dt-functional-dec-00.txt > Pages : 18 > Date : 2004-10-18 > > In this note we will present a functional decomposition of the M6 > protocol i.e. the protocol for preserving established > communications > in multihomed environments. We will do so by describing a protocol > walkthrough, presenting which functions have to be performed at each > stage and the messages required to accomplish them. The functional > decomposition presented in this draft is based on the general > functional analysis of multihoming approaches presented in [3]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-multi6dt-functional- > dec-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bagnulo-multi6dt-functional-dec-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-multi6dt-functional-dec-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-10-18172915.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Oct 20 10:02:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04467 for ; Wed, 20 Oct 2004 10:02:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKH0w-000MP1-Sx for multi6-data@psg.com; Wed, 20 Oct 2004 14:00:30 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKH0e-000MNL-FU for multi6@ops.ietf.org; Wed, 20 Oct 2004 14:00:12 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9C9292F361 for ; Wed, 20 Oct 2004 16:00:11 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 8755A2F2BD for ; Wed, 20 Oct 2004 16:00:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <609C856C-22A0-11D9-AF09-000D93ACD0FE@it> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: Fwd: I-D ACTION:draft-bagnulo-multi6dt-hba-00.txt Date: Wed, 20 Oct 2004 16:00:19 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 19 de octubre de 2004 13:47:34 GMT+02:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-bagnulo-multi6dt-hba-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Hash Based Addresses (HBA) > Author(s) : M. Bagnulo > Filename : draft-bagnulo-multi6dt-hba-00.txt > Pages : 18 > Date : 2004-10-18 > > This memo describes a mechanism to provide a secure binding between > the multiple addresses with different prefixes available to a host > within a multihomed site. The main idea is that information about > the multiple prefixes is included within the addresses themselves. > This is achieved by generating the interface identifiers of the > addresses of a host as hashes of the available prefixes and a random > number. Then, the multiple addresses are generated by appending the > different prefixes to the generated interface identifiers. The > result is a set of addresses, called Hash Based Addresses (HBAs), > that are inherently bound. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-multi6dt-hba-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bagnulo-multi6dt-hba-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-multi6dt-hba-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-10-18172937.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Oct 20 10:02:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04491 for ; Wed, 20 Oct 2004 10:02:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKH0g-000MNc-7Z for multi6-data@psg.com; Wed, 20 Oct 2004 14:00:14 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKH0P-000MJJ-E5 for multi6@ops.ietf.org; Wed, 20 Oct 2004 13:59:57 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4BD3C2F2F0 for ; Wed, 20 Oct 2004 15:59:56 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 35D2F2F2EC for ; Wed, 20 Oct 2004 15:59:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <5747F810-22A0-11D9-AF09-000D93ACD0FE@it> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: Fwd: I-D ACTION:draft-huitema-multi6-ingress-filtering-00.txt Date: Wed, 20 Oct 2004 16:00:03 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 19 de octubre de 2004 13:47:49 GMT+02:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-huitema-multi6-ingress-filtering-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Ingress filtering compatibility for IPv6 multihomed sites > Author(s) : C. Huitema, et al. > Filename : draft-huitema-multi6-ingress-filtering-00.txt > Pages : 16 > Date : 2004-10-18 > > The note presents a set of mechanisms to provide ingress filtering > compatibility for legacy hosts in IPv6 multihomed sites. The > described mechanisms are not a complete multihoming solution but > just > a component, and additional mechanisms will be needed to fulfill all > the requirements of multihoming. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-huitema-multi6-ingress- > filtering-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-huitema-multi6-ingress-filtering-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-huitema-multi6-ingress-filtering-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-10-18172953.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Oct 20 10:21:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07169 for ; Wed, 20 Oct 2004 10:21:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKHKy-000PpM-Ow for multi6-data@psg.com; Wed, 20 Oct 2004 14:21:12 +0000 Received: from [194.200.10.4] (helo=mxgw.highway.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKHKx-000Poz-Os for multi6@ops.ietf.org; Wed, 20 Oct 2004 14:21:11 +0000 Received: from trigger.welwyn.internal (trigger.welwyn.internal [172.31.10.182]) by mxgw.highway.co.uk (Postfix) with ESMTP id 078FF204F95 for ; Wed, 20 Oct 2004 15:21:09 +0100 (BST) From: David Gethings To: Multi6 List Subject: Re: Fwd: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Wed, 20 Oct 2004 15:21:10 +0100 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410201521.10245.davidg@pipex.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 19 October 2004 16:38, marcelo bagnulo braun wrote: > Comments are welcome Overall a good draft. But I do have one concern. In section 5.2 you propose 3 source address selection methods. The third suggests that a host try with all possible source addresses simultaneously that are within scope. While this offers the advantage of providing best path selection - as you point out in your draft - it could also provides a ready made DOS'ing mechanism. The DOS'er simply has to clear the SA cache and send a packet, cira repeat. My apologies if this security consideration is already addressed in another RFC/ID. Cheers Dg From owner-multi6@ops.ietf.org Wed Oct 20 10:53:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11795 for ; Wed, 20 Oct 2004 10:53:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKHpM-0004MN-MI for multi6-data@psg.com; Wed, 20 Oct 2004 14:52:36 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKHpL-0004M3-LF for multi6@ops.ietf.org; Wed, 20 Oct 2004 14:52:35 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11734; Wed, 20 Oct 2004 10:52:32 -0400 (EDT) Message-Id: <200410201452.KAA11734@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-v4-multihoming-02.txt Date: Wed, 20 Oct 2004 10:52:31 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : IPv4 Multihoming Motivation, Practices and Limitations Author(s) : J. Abley, et al. Filename : draft-ietf-multi6-v4-multihoming-02.txt Pages : 16 Date : 2004-10-19 Multihoming is an essential component of service for sites which are part of the Internet. This draft describes some of the motivations, practices and limitations of multihoming as it is achieved in the IPv4 world today. The analysis is done in order to serve as underlaying documentation to the discussions in the "Site multihoming for IPv6" working group of the IETF, who are working to a longer term solution to some of the issues that arise from doing multihoming in the ways as are described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-v4-multihoming-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20105537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-v4-multihoming-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Wed Oct 20 11:28:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14623 for ; Wed, 20 Oct 2004 11:28:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIN6-0009a0-8r for multi6-data@psg.com; Wed, 20 Oct 2004 15:27:28 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIMz-0009YH-4c for multi6@ops.ietf.org; Wed, 20 Oct 2004 15:27:21 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i9KFRKGn025602 for ; Wed, 20 Oct 2004 16:27:20 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA19664 for ; Wed, 20 Oct 2004 16:27:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9KFRGM23968 for multi6@ops.ietf.org; Wed, 20 Oct 2004 16:27:16 +0100 Date: Wed, 20 Oct 2004 16:27:16 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: IPv6 renumbering draft Message-ID: <20041020152716.GX14932@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, We have submitted a new draft on "Things to think about when Renumbering an IPv6 network", which complements Fred Baker's document on procedures for renumbering. The draft went in on Monday, but hasn't been announced. It is in the IETF repository though: http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-00.txt Abstract This memo presents a summary of scenarios, issues for consideration and IPv6-specific tools for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. The document is not intended to be complete at the -00 phase, and will be enhanced as further operational experience is gathered. Given the relationship between renumbering and multihoming (renumbering without a flag day implies transient multihoming), we felt we'd like to invite multi6-ers to post feedback on the v6ops list (rather than here, to keep one thread :). -- Tim From owner-multi6@ops.ietf.org Wed Oct 20 11:57:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17178 for ; Wed, 20 Oct 2004 11:57:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIpT-000E5m-8C for multi6-data@psg.com; Wed, 20 Oct 2004 15:56:47 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIpR-000E56-Dc for multi6@ops.ietf.org; Wed, 20 Oct 2004 15:56:45 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9KFuhs3012478 for ; Wed, 20 Oct 2004 08:56:44 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9KFugJQ025406 for ; Wed, 20 Oct 2004 17:56:42 +0200 (MEST) Message-ID: <41768AE5.2040806@sun.com> Date: Wed, 20 Oct 2004 08:57:25 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Design team work Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The design team that started after the San Diego meeting has produced 5 drafts (which all have "multi6dt" as part of their name). I think four of them have been announced and are in the I-D directory so far. The most revolutionary of them is draft-bagnulo-multi6dt-hba-00.txt which provides a way to secure the relationship between a hosts multiple IP addresses as long as the set of address prefixes is fixed, and the verification is as cheap as computing a SHA1 hash. Thus without any additional dependencies on the DNS and without any public key crypto, it is possible to secure the relationship between the addresses/locators of the host. To me this is very promising. The complete list of drafts is below. I hope we can get some discussion on the mailing list before DC so that we can collectively have a list of open issues to discuss in DC. Multihoming L3 Shim Approach Hash Based Addresses (HBA) draft-bagnulo-multi6dt-hba-00 Functional decomposition of the M6 protocol draft-bagnulo-multi6dt-functional-dec-00 Failure Detection and Locator Selection in Multi6 draft-arkko-multi6dt-failure-detection-00 Multi6 Application Referral Issues Erik From owner-multi6@ops.ietf.org Wed Oct 20 12:37:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22520 for ; Wed, 20 Oct 2004 12:37:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKJSA-000KLN-Aq for multi6-data@psg.com; Wed, 20 Oct 2004 16:36:46 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKJS9-000KKY-37 for multi6@ops.ietf.org; Wed, 20 Oct 2004 16:36:45 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D71A92F4E4; Wed, 20 Oct 2004 18:36:43 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id C0F8E2F4CD; Wed, 20 Oct 2004 18:36:43 +0200 (CEST) In-Reply-To: <41761E2F.4050302@tori.cc> References: <41761E2F.4050302@tori.cc> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3EC115C7-22B6-11D9-AF09-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: Selecting Source Address and Selecting Path (was: Re: Fwd: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt) Date: Wed, 20 Oct 2004 18:36:51 +0200 To: Kenji Ohira X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Kenji, El 20/10/2004, a las 10:13, Kenji Ohira escribi=F3: > Hi Marcelo, > > I appreciate your fine draft. > > Well, let me ask you a question. > In section 3, it is described that: > " - If X tries to communicate with Y using A:X as a source address, > packets will be routed through ISPA in order to comply with ingress > filters, ... " > Do you assume that a kind of source address dependent routing = mechanism > is running in the site X? > Well i am assuming one of the solutions available in http://www.ietf.org/internet-drafts/draft-huitema-multi6-ingress-=20 filtering-00.txt (except the one of suppressing ingress filtering) > IMHO, it is better to note about source address dependent routing > because selecting a source address may not be equal to selecting a = path > in a site with normal (destination address based) routing. > Yes, but you can also do approaches like the one presented in the =20 appendix of the above draft Regards, marcelo > Regards, > > ---- > October 20, 2004 > Kenji Ohira > Kyoto University > > > marcelo bagnulo braun wrote: > >> Comments are welcome >> regards, marcelo >> Inicio mensaje reenviado: >>> De: Internet-Drafts@ietf.org >>> Fecha: 19 de octubre de 2004 13:46:29 GMT+02:00 >>> Para: i-d-announce@ietf.org >>> Asunto: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt >>> Responder a: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts =20= >>> directories. >>> >>> >>> Title : Address selection in multihomed environments >>> Author(s) : C. Huitema, et al. >>> Filename : draft-huitema-multi6-addr-selection-00.txt >>> Pages : 17 >>> Date : 2004-10-18 > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Oct 20 12:40:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23114 for ; Wed, 20 Oct 2004 12:40:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKJVY-000Ksv-2O for multi6-data@psg.com; Wed, 20 Oct 2004 16:40:16 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKJV9-000KnF-3v for multi6@ops.ietf.org; Wed, 20 Oct 2004 16:39:51 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DE6A52F4E4; Wed, 20 Oct 2004 18:39:49 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id C7D342F4E2; Wed, 20 Oct 2004 18:39:49 +0200 (CEST) In-Reply-To: <200410201521.10245.davidg@pipex.net> References: <200410201521.10245.davidg@pipex.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Wed, 20 Oct 2004 18:39:57 +0200 To: David Gethings X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi David, El 20/10/2004, a las 16:21, David Gethings escribi=F3: > On Tuesday 19 October 2004 16:38, marcelo bagnulo braun wrote: >> Comments are welcome > Overall a good draft. thanks > But I do have one concern. In section 5.2 you propose 3 > source address selection methods. The third suggests that a host try=20= > with all > possible source addresses simultaneously that are within scope. > > While this offers the advantage of providing best path selection - as=20= > you > point out in your draft - it could also provides a ready made DOS'ing > mechanism. The DOS'er simply has to clear the SA cache and send a=20 > packet, > cira repeat. > I may not be understanding your point here... The proposed mechanism is to be used for initiating communications, not=20= when the host receives an incoming communication. I mean, the DOSer doesn't have a mechanism to trigger the multiple=20 packets, i think. Am i missing your point? Thanks, marcelo > My apologies if this security consideration is already addressed in=20 > another > RFC/ID. > > Cheers > > Dg > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Oct 20 18:14:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04324 for ; Wed, 20 Oct 2004 18:14:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKOhk-000HLO-Fu for multi6-data@psg.com; Wed, 20 Oct 2004 22:13:12 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKOhj-000HKx-DQ for multi6@ops.ietf.org; Wed, 20 Oct 2004 22:13:11 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KMD8xD143498 for ; Wed, 20 Oct 2004 22:13:08 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KMD8wo222248 for ; Thu, 21 Oct 2004 00:13:08 +0200 Received: from zurich.ibm.com (sig-9-146-222-61.de.ibm.com [9.146.222.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA23416 for ; Thu, 21 Oct 2004 00:13:07 +0200 Message-ID: <4176E2F5.10008@zurich.ibm.com> Date: Thu, 21 Oct 2004 00:13:09 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is proposed to forward draft-ietf-multi6-architecture-01.txt to the IESG for approval as an Informational RFC Any final comments must be sent to the WG list at multi6@ops.ietf.org within two weeks, i.e. at the latest on November 3, 2004. Thanks Brian Carpenter multi6 WG co-chair From owner-multi6@ops.ietf.org Wed Oct 20 18:16:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04616 for ; Wed, 20 Oct 2004 18:16:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKOkr-000Hxy-FR for multi6-data@psg.com; Wed, 20 Oct 2004 22:16:25 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKOkq-000Hxj-E1 for multi6@ops.ietf.org; Wed, 20 Oct 2004 22:16:24 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KMGNxX030662 for ; Wed, 20 Oct 2004 22:16:23 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KMGMwo223126 for ; Thu, 21 Oct 2004 00:16:23 +0200 Received: from zurich.ibm.com (sig-9-146-222-61.de.ibm.com [9.146.222.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA49672 for ; Thu, 21 Oct 2004 00:16:19 +0200 Message-ID: <4176E3B7.4090806@zurich.ibm.com> Date: Thu, 21 Oct 2004 00:16:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is proposed to forward draft-ietf-multi6-things-to-think-about-00.txt to the IESG for approval as an Informational RFC Any final comments must be sent to the WG list at multi6@ops.ietf.org within two weeks, i.e. at the latest on November 3, 2004. Thanks Brian Carpenter multi6 WG co-chair From owner-multi6@ops.ietf.org Wed Oct 20 18:17:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04823 for ; Wed, 20 Oct 2004 18:17:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKOlq-000I41-7t for multi6-data@psg.com; Wed, 20 Oct 2004 22:17:26 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKOlp-000I3k-4m for multi6@ops.ietf.org; Wed, 20 Oct 2004 22:17:25 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KMHOxX108518 for ; Wed, 20 Oct 2004 22:17:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KMHNkJ170178 for ; Thu, 21 Oct 2004 00:17:23 +0200 Received: from zurich.ibm.com (sig-9-146-222-61.de.ibm.com [9.146.222.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA49754 for ; Thu, 21 Oct 2004 00:17:22 +0200 Message-ID: <4176E3F6.9090503@zurich.ibm.com> Date: Thu, 21 Oct 2004 00:17:26 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Multi6 WG Last Call (3 of 3) draft-ietf-multi6-v4-multihoming-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is proposed to forward draft-ietf-multi6-v4-multihoming-02.txt to the IESG for approval as an Informational RFC Any final comments must be sent to the WG list at multi6@ops.ietf.org within two weeks, i.e. at the latest on November 3, 2004. Thanks Brian Carpenter multi6 WG co-chair From owner-multi6@ops.ietf.org Wed Oct 20 18:21:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05504 for ; Wed, 20 Oct 2004 18:21:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKOpl-000ImQ-9v for multi6-data@psg.com; Wed, 20 Oct 2004 22:21:29 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKOpj-000Ilv-Vm for multi6@ops.ietf.org; Wed, 20 Oct 2004 22:21:28 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KMLREA103348 for ; Wed, 20 Oct 2004 22:21:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KMLQkJ177784 for ; Thu, 21 Oct 2004 00:21:26 +0200 Received: from zurich.ibm.com (sig-9-146-222-61.de.ibm.com [9.146.222.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA54562 for ; Thu, 21 Oct 2004 00:21:25 +0200 Message-ID: <4176E4EA.5080800@zurich.ibm.com> Date: Thu, 21 Oct 2004 00:21:30 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt References: <4176E2F5.10008@zurich.ibm.com> In-Reply-To: <4176E2F5.10008@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My minor substantive comments are below. Some editorial comments were sent direct to the author. > 4.2 Multi-Homing: Mobility ... > The aspect of MIPv6 which appears to present issues in the context of > multi-homing is the return routeability mechanism. In MIPv6 identity > validity is periodically tested by return routeability of the > identity address. This regular use of a distinguished locator as the > identity token cannot support return reachability in the multi-homing > context in the event of extended path failure of the path that is > associated with the identity locator. This question isn't really relevant to multi6, but isn't it therefore also the case that if the home agent becomes unreachable for more than 7 minutes, regular MIP6 also breaks for the same reason and the mobile node loses connectivity? > 5.3.3 Layering Identity ... > An alternative approach is to use a distinct protocol element placed > between the transport and internet layers of the protocol stack. The > advantage of this approach is that it would offer a consistent form > of mapping between identities and locators for all forms of transport > protocols. However this protocol element would not be explicitly > aware of sessions and would either have to discover the appropriate > identity / locator mapping for all identity-addressed packets passed > from the transport protocol later, irrespective of whether such a > mapping exists and whether this is part of a session context, or have > an additional mechanism of signaling to determine when such a mapping > is to be discovered and applied. At this level there is also no > explicit knowledge of when identity / locator mapping state is no > longer required, as there is no explicit signaling of when all flows > to and from a particular destination has stopped and resources > consumed in supporting state can be released. But there is knowledge, even with UDP, when a socket is closed (in the worst case because the process that opened it goes away). I think that because of some sort of layering religion, we tend to neglect the fact that socket state exists and gets explicitly deleted, and this should be exploited as the trigger for deleting id/loc mapping state. Brian From owner-multi6@ops.ietf.org Thu Oct 21 03:06:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15879 for ; Thu, 21 Oct 2004 03:06:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKX0n-000JtA-Ds for multi6-data@psg.com; Thu, 21 Oct 2004 07:05:25 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKX0m-000JrO-CW for multi6@ops.ietf.org; Thu, 21 Oct 2004 07:05:24 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7BA1F8982E; Thu, 21 Oct 2004 10:05:23 +0300 (EEST) Message-ID: <41775F52.7080908@piuha.net> Date: Thu, 21 Oct 2004 10:03:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Multi6 Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt References: <4176E2F5.10008@zurich.ibm.com> <4176E4EA.5080800@zurich.ibm.com> In-Reply-To: <4176E4EA.5080800@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > 4.2 Multi-Homing: Mobility > ... > > The aspect of MIPv6 which appears to present issues in the context of > > multi-homing is the return routeability mechanism. In MIPv6 identity > > validity is periodically tested by return routeability of the > > identity address. This regular use of a distinguished locator as the > > identity token cannot support return reachability in the multi-homing > > context in the event of extended path failure of the path that is > > associated with the identity locator. > > This question isn't really relevant to multi6, but isn't it therefore > also the case that if the home agent becomes unreachable for more than > 7 minutes, regular MIP6 also breaks for the same reason and the mobile > node loses connectivity? This is correct. Other mobility mechanisms such as HIP could survive such scenarios, however. --Jari From owner-multi6@ops.ietf.org Thu Oct 21 04:58:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22159 for ; Thu, 21 Oct 2004 04:58:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKYku-0008mn-3f for multi6-data@psg.com; Thu, 21 Oct 2004 08:57:08 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKYks-0008mT-Qt for multi6@ops.ietf.org; Thu, 21 Oct 2004 08:57:07 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 274EA2F6A7; Thu, 21 Oct 2004 10:57:05 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 0A6442F6C1; Thu, 21 Oct 2004 10:57:05 +0200 (CEST) In-Reply-To: <4176E4EA.5080800@zurich.ibm.com> References: <4176E2F5.10008@zurich.ibm.com> <4176E4EA.5080800@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <33429320-233F-11D9-AF09-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Date: Thu, 21 Oct 2004 10:57:13 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, El 21/10/2004, a las 0:21, Brian E Carpenter escribi=F3: > My minor substantive comments are below. > Some editorial comments were sent direct to the author. > > > 4.2 Multi-Homing: Mobility > ... > > The aspect of MIPv6 which appears to present issues in the=20 > context of > > multi-homing is the return routeability mechanism. In MIPv6=20 > identity > > validity is periodically tested by return routeability of the > > identity address. This regular use of a distinguished locator as=20= > the > > identity token cannot support return reachability in the=20 > multi-homing > > context in the event of extended path failure of the path that is > > associated with the identity locator. > > This question isn't really relevant to multi6, Well, lots of people claim that there is a close relation between=20 multihoming and mobility, since both problmes require changing the=20 locators and keep the identifier. Since there is an available solution for mobility, it seems quite=20 natural to explore if such solution is suitable for multihoming. The problem with the available solution for mobility is that the=20 security mechanism used in mip is inherently incompatible with the=20 multihoming requirements, since it is based on reaching the identifier. so imho it is relevant to multihoming the explanation why the approach=20= used for mobility is not suitable for multihoming. regards, marcelo > but isn't it therefore > also the case that if the home agent becomes unreachable for more than > 7 minutes, regular MIP6 also breaks for the same reason and the mobile > node loses connectivity? > > > 5.3.3 Layering Identity > ... > > An alternative approach is to use a distinct protocol element=20 > placed > > between the transport and internet layers of the protocol stack. =20= > The > > advantage of this approach is that it would offer a consistent=20 > form > > of mapping between identities and locators for all forms of=20 > transport > > protocols. However this protocol element would not be explicitly > > aware of sessions and would either have to discover the=20 > appropriate > > identity / locator mapping for all identity-addressed packets=20 > passed > > from the transport protocol later, irrespective of whether such a > > mapping exists and whether this is part of a session context, or=20= > have > > an additional mechanism of signaling to determine when such a=20 > mapping > > is to be discovered and applied. At this level there is also no > > explicit knowledge of when identity / locator mapping state is no > > longer required, as there is no explicit signaling of when all=20 > flows > > to and from a particular destination has stopped and resources > > consumed in supporting state can be released. > > But there is knowledge, even with UDP, when a socket is closed (in > the worst case because the process that opened it goes away). I think > that because of some sort of layering religion, we tend to neglect > the fact that socket state exists and gets explicitly deleted, and > this should be exploited as the trigger for deleting id/loc > mapping state. > > Brian > > > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Oct 21 05:39:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24009 for ; Thu, 21 Oct 2004 05:39:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKZOv-000DyY-M7 for multi6-data@psg.com; Thu, 21 Oct 2004 09:38:29 +0000 Received: from [194.200.10.4] (helo=mxgw.highway.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKZOu-000Dy8-R8 for multi6@ops.ietf.org; Thu, 21 Oct 2004 09:38:29 +0000 Received: from trigger.welwyn.internal (trigger.welwyn.internal [172.31.10.182]) by mxgw.highway.co.uk (Postfix) with ESMTP id BA6E9204F42 for ; Thu, 21 Oct 2004 10:38:27 +0100 (BST) From: David Gethings To: Multi6 List Subject: Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Thu, 21 Oct 2004 10:38:28 +0100 User-Agent: KMail/1.7 References: <200410201521.10245.davidg@pipex.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410211038.29002.davidg@pipex.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 20 October 2004 17:39, marcelo bagnulo braun wrote: > I may not be understanding your point here... > The proposed mechanism is to be used for initiating communications, not > when the host receives an incoming communication. > I mean, the DOSer doesn't have a mechanism to trigger the multiple > packets, i think. > > Am i missing your point? Perhaps a bit. Suppose the DOS'er has control of a dual homed node. He then installs some code that initiates communication with a target. For every packet this code sends the stack will send two. This will multiply the effect of the attack. I'm not saying that this mechanism facilitates DOS'ing but it could multiple it's effects without any additional effort by the DOS'er. Cheers Dg From owner-multi6@ops.ietf.org Thu Oct 21 05:52:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24634 for ; Thu, 21 Oct 2004 05:52:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKZbs-000Fd0-QX for multi6-data@psg.com; Thu, 21 Oct 2004 09:51:52 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKZbs-000Fcc-0B for multi6@ops.ietf.org; Thu, 21 Oct 2004 09:51:52 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F17B42F791; Thu, 21 Oct 2004 11:51:50 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id DDAB32F77A; Thu, 21 Oct 2004 11:51:50 +0200 (CEST) In-Reply-To: <200410211038.29002.davidg@pipex.net> References: <200410201521.10245.davidg@pipex.net> <200410211038.29002.davidg@pipex.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Thu, 21 Oct 2004 11:51:59 +0200 To: David Gethings X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 21/10/2004, a las 11:38, David Gethings escribi=F3: > On Wednesday 20 October 2004 17:39, marcelo bagnulo braun wrote: >> I may not be understanding your point here... >> The proposed mechanism is to be used for initiating communications,=20= >> not >> when the host receives an incoming communication. >> I mean, the DOSer doesn't have a mechanism to trigger the multiple >> packets, i think. >> >> Am i missing your point? > Perhaps a bit. Suppose the DOS'er has control of a dual homed node. He=20= > then > installs some code that initiates communication with a target. For=20 > every > packet this code sends the stack will send two. This will multiply the=20= > effect > of the attack. > > I'm not saying that this mechanism facilitates DOS'ing but it could=20 > multiple > it's effects without any additional effort by the DOS'er. > Ok, i see your point and i agree however, once that an attacker has control over a given node, i am not=20= sure if there is much difference in the required effort to send one or=20= two packets. Anyway, thanks for your comment, regards, marcelo > Cheers > > Dg > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Fri Oct 22 08:30:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28297 for ; Fri, 22 Oct 2004 08:30:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKyX1-000Io3-La for multi6-data@psg.com; Fri, 22 Oct 2004 12:28:31 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKyX0-000Inm-I8 for multi6@ops.ietf.org; Fri, 22 Oct 2004 12:28:30 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9MCSxQx022280; Fri, 22 Oct 2004 14:29:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Fri, 22 Oct 2004 14:28:26 +0200 To: Cedric de Launois X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-sep-04, at 15:23, Cedric de Launois wrote: > CONCLUSIONS: > These observations show that, from a performance point of view, IPv6 > multihomed stubs get benefits from the use of multiple PA prefixes and > should use them instead of a single PI prefix as in IPv4 today. > This study thus strongly encourages the IETF to pursue the development > of IPv6 multihoming solutions relying on the use of multiple PA > prefixes. > The use of such prefixes reduces the size of the BGP routing tables, > but > also provides lower delays, more diverse Internet paths, which in turn > yields to better possiblities to balance the traffic load and to > support > quality of service. "When considering dual-homed IPv6stubs, we see in fig. 13 or in fig. 14 that the path diversity observed is already as good as the path diversity of a 25-homed IPv4 stub." :-) But the question is: will this help us or hurt us? Basically, BGP doesn't really know what the best path is, but it can usually detect and avoid the bad ones. So you pretty much always get something reasonable. With multi-address multihoming you get many more paths, some of which are better than what BGP would have given you, but a lot are worse. So the trick is to select the best one, or at least avoid the bad ones. How do we do this? Iljitsch From owner-multi6@ops.ietf.org Fri Oct 22 08:43:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28901 for ; Fri, 22 Oct 2004 08:43:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKykO-000Kl2-UW for multi6-data@psg.com; Fri, 22 Oct 2004 12:42:20 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKykE-000KkD-Ml for multi6@ops.ietf.org; Fri, 22 Oct 2004 12:42:11 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9MCgRQx022461; Fri, 22 Oct 2004 14:42:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: New I-D Submitted (Re: Newbie Question about addressing impacts) Date: Fri, 22 Oct 2004 14:41:53 +0200 To: Arifumi Matsumoto X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 15-okt-04, at 11:01, Arifumi Matsumoto wrote: > In short, in our model, ISPs provide Source Address Selection > Policies as well as Prefix Delegation Info by DHCP. > The consumer edge router receives those policies (from > multiple ISPs) and re-distribute them to end nodes. > End nodes put them into policy table, which leads to > appropriate source address selection. > http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist > -00.txt Hm, I'm worried about the policy information becoming too extensive to fit comfortably in DHCP or RA packets. I guess it would be possible to broadcast basic policy information this way and then create a cache of more specific information on-demand, e.g. when ICMP messages come in. (The advantage of using RA here is that when connectivity changes, a lot of hosts can be informed quickly about a new policy.) > http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- > selection-opt-00.txt > http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- > selection-opt-00.txt Why must the padding be ones? On many systems, newly allocated memory is filled with zeros, so this would be easier. And then there's tradition. :-) From owner-multi6@ops.ietf.org Fri Oct 22 08:43:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28969 for ; Fri, 22 Oct 2004 08:43:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKylc-000Kvy-3O for multi6-data@psg.com; Fri, 22 Oct 2004 12:43:36 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKylb-000Kvk-BJ for multi6@ops.ietf.org; Fri, 22 Oct 2004 12:43:35 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ACA8786B00; Fri, 22 Oct 2004 08:43:32 -0400 (EDT) To: multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Cc: jnc@mercury.lcs.mit.edu Message-Id: <20041022124332.ACA8786B00@mercury.lcs.mit.edu> Date: Fri, 22 Oct 2004 08:43:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > But the question is: will this help us or hurt us? Basically, BGP > doesn't really know what the best path is ... With multi-address > multihoming you get many more paths, some of which are better than > what BGP would have given you, but a lot are worse. So the trick is > to select the best one, or at least avoid the bad ones. How do we > do this? There is an answer, but you won't like it! :-) Noel From owner-multi6@ops.ietf.org Fri Oct 22 08:54:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29844 for ; Fri, 22 Oct 2004 08:54:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKyvk-000Mh4-5y for multi6-data@psg.com; Fri, 22 Oct 2004 12:54:04 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKyvc-000MfM-UC for multi6@ops.ietf.org; Fri, 22 Oct 2004 12:53:57 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9MCsPQx022639; Fri, 22 Oct 2004 14:54:26 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1098217103.2150.145.camel@127750> References: <1098217103.2150.145.camel@127750> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C6E7BEA-2429-11D9-89C3-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: [Fwd: I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt] Date: Fri, 22 Oct 2004 14:53:51 +0200 To: Wassim.Haddad@ericsson.ca X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 19-okt-04, at 22:18, Wassim Michel Haddad wrote: >> This memo describes the privacy in mobility and multi-homing problem >> statement. >> http://www.ietf.org/internet-drafts/draft-haddad-momipriv-problem- >> statement-00.txt I'm not happy about this singling out privacy issues like this, because it implicitly says "more privacy is better". That's certainly not the case: there needs to be a balance between privacy and accountability. Today, the internet operator community has huge problems with all kinds of abuse conducted by people who manage to hide behind other's systems they managed to corrupt. We can't have privacy extensions make these problems worse. "Note that while using only a different IPv6 address for each new session may prevent/mitigate the ability to trace a MN on the IP layer level, it remains always possible to trace it through its device identifier(s) on the MAC layer level and consequently, to learn all IPv6 addresses used by the MN by correlating different sessions, thus breaking any unlinkability protection provided at the IP layer." Huh??? This is certainly not universally true. Another issue is that the references are all towards drafts and not RFCs. This is very bad because 1. people tend to know the RFCs and not necessarily the drafts and 2. drafts disappear after a while. From owner-multi6@ops.ietf.org Fri Oct 22 09:00:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00414 for ; Fri, 22 Oct 2004 09:00:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKz1z-000NuH-Bk for multi6-data@psg.com; Fri, 22 Oct 2004 13:00:31 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKz1y-000Ntx-85 for multi6@ops.ietf.org; Fri, 22 Oct 2004 13:00:30 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9MD0wQx022706; Fri, 22 Oct 2004 15:00:58 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20041022124332.ACA8786B00@mercury.lcs.mit.edu> References: <20041022124332.ACA8786B00@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56D6A1E0-242A-11D9-89C3-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Fri, 22 Oct 2004 15:00:24 +0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-okt-04, at 14:43, Noel Chiappa wrote: >> So the trick is to select the best one, or at least avoid the bad >> ones. How do we do this? > There is an answer, but you won't like it! :-) I wasn't aware that I'm so set in my ways that people can predict whether I'll like something in advance... So let's hear it, I'm interested to know if you're right. (-: From owner-multi6@ops.ietf.org Fri Oct 22 10:10:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06562 for ; Fri, 22 Oct 2004 10:10:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL076-000AvG-DN for multi6-data@psg.com; Fri, 22 Oct 2004 14:09:52 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL06w-000Ati-5a for multi6@ops.ietf.org; Fri, 22 Oct 2004 14:09:42 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 894C4872D5; Fri, 22 Oct 2004 10:09:41 -0400 (EDT) To: multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Cc: jnc@mercury.lcs.mit.edu Message-Id: <20041022140941.894C4872D5@mercury.lcs.mit.edu> Date: Fri, 22 Oct 2004 10:09:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > I wasn't aware that I'm so set in my ways that people can predict > whether I'll like something in advance... It's not just you, almost *nobody* likes it! So I'm merely going with the odds! :-) Although I admit you seem to not be afraid of offbeat ideas, so you may well like it at a purely technical level. Although I predict you will be daunted by the magnitude of the change... :-) > So let's hear it, I'm interested to know if you're right. (-: Well, basically, I think we need to move the "path selection" function out of the "network" (i.e. the routers), and let the hosts (or, if they are lazy/stupid, an agent acting on their behalf) do it. To do this, they obviously need more information, which I claim should be maps of network topology. I have two standards points to make to people who roll their eyes at this hopeless technological naivete, and say that it's "obviously" way too complex a job to give to the hosts: - Back in the 1970's, the "network" took care of flow/congestion control and also reliability, and now hosts do all this - using some fairly complex algorithms that took us decades to get working well. And having made that fundamental architectural reorganization, it's now "obvious" to everyone that that's the way it ought to be. - This is the way we do cars and highways, and it seems to work just fine. Anyway, making this (admittedly major) architectural change kills about 17 dozen birds, of which the "how do I pick the best address for the destination" is one. And yes, I know this is a really, really, *really*, ***REALLY*** big change. But, surprisingly, when you start working through the details, there are ways to incrementally deploy it, ways which don't mandate changes to all hosts before it can begin to be useful. Noel From owner-multi6@ops.ietf.org Fri Oct 22 10:29:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08737 for ; Fri, 22 Oct 2004 10:29:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL0Q6-000EG3-U1 for multi6-data@psg.com; Fri, 22 Oct 2004 14:29:30 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL0Q5-000EFn-OF for multi6@ops.ietf.org; Fri, 22 Oct 2004 14:29:30 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.230.67]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id i9METNox019260; Fri, 22 Oct 2004 16:29:23 +0200 (MET DST) Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming From: Cedric de Launois To: Iljitsch van Beijnum Cc: Multi6 In-Reply-To: References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1098455472.23282.150.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 22 Oct 2004 16:31:12 +0200 Content-Transfer-Encoding: 8bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Le ven 22/10/2004 à 14:28, Iljitsch van Beijnum a écrit : > "When considering dual-homed IPv6stubs, we see in fig. 13 or in fig. 14 > that the path diversity observed is already as good as the path > diversity of a 25-homed IPv4 stub." > > :-) > > But the question is: will this help us or hurt us? Basically, BGP > doesn't really know what the best path is, but it can usually detect > and avoid the bad ones. So you pretty much always get something > reasonable. With multi-address multihoming you get many more paths, > some of which are better than what BGP would have given you, but a lot > are worse. So the trick is to select the best one, or at least avoid > the bad ones. How do we do this? Good question ! I'm currently working exactly at this point. And I have a pretty fair solution (I believe)... I can't say more just now, but expect some news from me about that in two or three weeks ;) Cedric From owner-multi6@ops.ietf.org Fri Oct 22 11:02:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11831 for ; Fri, 22 Oct 2004 11:02:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL0v6-000KJw-8R for multi6-data@psg.com; Fri, 22 Oct 2004 15:01:32 +0000 Received: from [128.182.58.100] (helo=mailer1.psc.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL0v5-000KJW-62 for multi6@ops.ietf.org; Fri, 22 Oct 2004 15:01:31 +0000 Received: from [192.168.1.104] (69-164-184-136.pittpa.adelphia.net [69.164.184.136]) (authenticated bits=56) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i9MF1LKq013430; Fri, 22 Oct 2004 11:01:23 -0400 (EDT) In-Reply-To: References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37EA750A-243B-11D9-BDEB-000D93289530@psc.edu> Content-Transfer-Encoding: 7bit From: "Michael H. Lambert" Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Fri, 22 Oct 2004 11:01:14 -0400 To: Multi6 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22 Oct 2004, at 08:28, Iljitsch van Beijnum wrote: > But the question is: will this help us or hurt us? Basically, BGP > doesn't really know what the best path is, but it can usually detect > and avoid the bad ones. So you pretty much always get something > reasonable. With multi-address multihoming you get many more paths, > some of which are better than what BGP would have given you, but a lot > are worse. So the trick is to select the best one, or at least avoid > the bad ones. How do we do this? [Not directed at Iljitsch; just quoting his text] Given that the "best path" probably just has meaning for a given application between given hosts at a given point in time, how often do we *really* need the *best* path? Best effort usually works well enough for forwarding--why shouldn't it do the same for path selection? (I think Noel implied this in his response--to use his highway analogy: in driving from Boston to San Francisco saving six hours is good, saving ten minutes is (usually) irrelevant?) Since the One True Best Path is likely unknowable anyway, why complicate path selection by building SVCs (or MPLS tunnels) into it? Michael From owner-multi6@ops.ietf.org Fri Oct 22 11:14:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12636 for ; Fri, 22 Oct 2004 11:14:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL16X-000Mo3-VT for multi6-data@psg.com; Fri, 22 Oct 2004 15:13:21 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL16W-000Mnk-QK for multi6@ops.ietf.org; Fri, 22 Oct 2004 15:13:21 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5057F2F6ED; Fri, 22 Oct 2004 17:13:20 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 36A5E2F6DE; Fri, 22 Oct 2004 17:13:20 +0200 (CEST) In-Reply-To: References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Cedric de Launois From: marcelo bagnulo braun Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Fri, 22 Oct 2004 17:13:30 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 22/10/2004, a las 14:28, Iljitsch van Beijnum escribi=F3: > On 22-sep-04, at 15:23, Cedric de Launois wrote: > >> CONCLUSIONS: > >> These observations show that, from a performance point of view, IPv6 >> multihomed stubs get benefits from the use of multiple PA prefixes = and >> should use them instead of a single PI prefix as in IPv4 today. >> This study thus strongly encourages the IETF to pursue the = development >> of IPv6 multihoming solutions relying on the use of multiple PA >> prefixes. >> The use of such prefixes reduces the size of the BGP routing tables,=20= >> but >> also provides lower delays, more diverse Internet paths, which in = turn >> yields to better possiblities to balance the traffic load and to=20 >> support >> quality of service. > > "When considering dual-homed IPv6stubs, we see in fig. 13 or in fig.=20= > 14 that the path diversity observed is already as good as the path=20 > diversity of a 25-homed IPv4 stub." > > :-) > > But the question is: will this help us or hurt us? Basically, BGP=20 > doesn't really know what the best path is, but it can usually detect=20= > and avoid the bad ones. So you pretty much always get something=20 > reasonable. With multi-address multihoming you get many more paths,=20 > some of which are better than what BGP would have given you, but a lot=20= > are worse. So the trick is to select the best one, or at least avoid=20= > the bad ones. How do we do this? > Just a nit, note that in multihoming we are only selection addresses,=20 not full paths. This means that we are selecting the ingress and egress ISP of the=20 source and destination sites, but that the interdomain path will be=20 selected with other means i.e. BGP. So we don't really need to know information about all the possible=20 complete paths, just the ingress and egress parts of the path. I guess=20= that this problem is more reduced and less ambitious than the general=20 one. Regards, marcelo > Iljitsch > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Fri Oct 22 11:15:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12720 for ; Fri, 22 Oct 2004 11:15:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL18T-000ND4-JY for multi6-data@psg.com; Fri, 22 Oct 2004 15:15:21 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL18S-000NCZ-Lm for multi6@ops.ietf.org; Fri, 22 Oct 2004 15:15:20 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 24CA1872D5; Fri, 22 Oct 2004 11:15:20 -0400 (EDT) To: multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Cc: jnc@mercury.lcs.mit.edu Message-Id: <20041022151520.24CA1872D5@mercury.lcs.mit.edu> Date: Fri, 22 Oct 2004 11:15:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Michael H. Lambert" > Best effort usually works well enough for forwarding--why shouldn't > it do the same for path selection? (I think Noel implied this in > his response--to use his highway analogy: in driving from Boston to > San Francisco saving six hours is good, saving ten minutes is > (usually) irrelevant?) Well, it was actually more explicit in my reference to "lazy" hosts letting other entities (a best-effort route server?) make the decision for them. Most of the time, "good enough" is good enough. Noel PS: Unrelated to this specific point, I was thinking that tahere's an interesting parallel between the cost-benefit analysis of my "crazy" routing ideas, and that for the identity-location split (a change which has been heavily examined here recently). As those with long memories will recall, I pushed the I/L split for many years without succeeding. I reckon that was in large because the benefits in any one use, of the many I cited, didn't seem worth the effort, and people had a hard time evaluating the whole basket. In fact, one could even make the case that it was only when multi-homing came up that people really saw a single application that made it worthwhile. I referred to "killing 17 birds" for the routing thing, but I predict that we'll see a similar pattern again - no one benefit will sell it, and people will have a hard time evaluating the whole basket. That's OK, I'm patient - another decade or two, and the killer need will arrive, I'm sure. From owner-multi6@ops.ietf.org Fri Oct 22 11:15:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12738 for ; Fri, 22 Oct 2004 11:15:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL18S-000NCd-MT for multi6-data@psg.com; Fri, 22 Oct 2004 15:15:20 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL18R-000NCJ-Cy for multi6@ops.ietf.org; Fri, 22 Oct 2004 15:15:19 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 21F602F6E6; Fri, 22 Oct 2004 17:15:19 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 09DAA2F6DE; Fri, 22 Oct 2004 17:15:19 +0200 (CEST) In-Reply-To: <4175AC71.7040504@sun.com> References: <4175AC71.7040504@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <355BD00C-243D-11D9-AF09-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: [Fwd: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt] Date: Fri, 22 Oct 2004 17:15:29 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Erik, Some additional issues that i may comment: When discussing fragmentation in section 5, i guess that the question=20 that Margaret raised a while ago is still there i.e. if we place multi6=20= below fragmentation, what happens when we have a full MTU packet and we=20= need to add an extension header? In section 8.4 it is stated that: This might be the case when the two hosts have already communicated, and it might be possible to have = the DNS resolver library provide alternate locators to the shim in the speculation that they might be useful. I have two issues with this: - first: wouldn't this impose a new RR or something similar? i mean how=20= does the DNS knows that all the locators belong to the same endpoint? i=20= guess this is not really compatible with section 7... - second: this would introduce a new way to learn additional locators=20 (the noid like mechanism) This mechanism may have different trust=20 levels than the one available for learning locators during the=20 communication lifetime. Wouldn't this introduce some trust problems? Regards, marcelo El 20/10/2004, a las 2:08, Erik Nordmark escribi=F3: > > > -------- Original Message -------- > Subject: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt > Date: Tue, 19 Oct 2004 07:48:23 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : Multihoming L3 Shim Approach > Author(s) : E. Nordmark > Filename : draft-nordmark-multi6dt-shim-00.txt > Pages : 20 > Date : 2004-10-18 > =09 > This document outlines an approach to solving IPv6 multihoming in > order to stimulate discussion. > > The approach is based on using a multi6 shim placed between the IP > endpoint sublayer and the IP routing sublayer, and, at least > initially, using routable IP locators as the identifiers visible > above the shim layer. The approach does not introduce a "stack=20 > name" > type of identifier, instead it ensures that all upper layer=20 > protocols > can operate unmodified in a multihomed setting while still seeing a > stable IPv6 address. > > This document does not specify the mechanism for authenticating and > authorizing the "rehoming" - this is specified in the HBA document. > Nor does it specify the messages used to establish multihoming=20 > state. > > The document does not even specify the packet format used for the > data packets. Instead it discusses the issue of receive side > demultiplexing and the different tradeoffs. The resolution of this > issue will effect the packet format for the data packets. > > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-shim-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of=20= > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-nordmark-multi6dt-shim-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-nordmark-multi6dt-shim-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > Content-Type: text/plain > Content-ID: <2004-10-18173037.I-D@ietf.org> > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Fri Oct 22 11:35:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14440 for ; Fri, 22 Oct 2004 11:35:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL1RP-0000s2-P0 for multi6-data@psg.com; Fri, 22 Oct 2004 15:34:55 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL1RO-0000ro-Mp for multi6@ops.ietf.org; Fri, 22 Oct 2004 15:34:55 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.230.67]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id i9MFYnoU025588; Fri, 22 Oct 2004 17:34:49 +0200 (MET DST) Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming From: Cedric de Launois To: "Michael H. Lambert" Cc: Multi6 In-Reply-To: <37EA750A-243B-11D9-BDEB-000D93289530@psc.edu> References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> <37EA750A-243B-11D9-BDEB-000D93289530@psc.edu> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1098459398.23282.157.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 22 Oct 2004 17:36:39 +0200 Content-Transfer-Encoding: 8bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Le ven 22/10/2004 à 17:01, Michael H. Lambert a écrit : > Given that the "best path" probably just has meaning for a given > application between given hosts at a given point in time, how often do > we *really* need the *best* path? The goal is not much to have the *best* path, but to avoid really bad paths. > Best effort usually works well enough for forwarding--why shouldn't it > do the same for path selection? (I think Noel implied this in his > response--to use his highway analogy: in driving from Boston to San > Francisco saving six hours is good, saving ten minutes is (usually) > irrelevant?) > > Since the One True Best Path is likely unknowable anyway, why > complicate path selection by building SVCs (or MPLS tunnels) into it? In the multi-address multi6 case, path selection is simply done by selecting the right source and destination prefixes. If a host can figure out which are the couples (src,dst) prefixes to avoid, then the benefit can be huge. This doesn't require tunnels in any ways. Cedric From owner-multi6@ops.ietf.org Fri Oct 22 12:09:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17121 for ; Fri, 22 Oct 2004 12:09:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL1yE-0007AN-KP for multi6-data@psg.com; Fri, 22 Oct 2004 16:08:50 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL1yD-00079r-Jk for multi6@ops.ietf.org; Fri, 22 Oct 2004 16:08:49 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E169789830; Fri, 22 Oct 2004 19:08:47 +0300 (EEST) Message-ID: <4179302D.3070209@piuha.net> Date: Fri, 22 Oct 2004 19:07:09 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: Iljitsch van Beijnum , Multi6 , Cedric de Launois Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: > So we don't really need to know information about all the possible > complete paths, just the ingress and egress parts of the path. I guess > that this problem is more reduced and less ambitious than the general one. Right. The other reduction is that I'm not sure we need to solve the "best path" problem but solving even the "a working path" problem might be sufficient. That's at least my preference. --Jari From owner-multi6@ops.ietf.org Fri Oct 22 16:09:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06031 for ; Fri, 22 Oct 2004 16:09:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL5hk-00042x-R3 for multi6-data@psg.com; Fri, 22 Oct 2004 20:08:04 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL5hj-00042V-J7 for multi6@ops.ietf.org; Fri, 22 Oct 2004 20:08:03 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9MK8VQx027537; Fri, 22 Oct 2004 22:08:32 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20041022140941.894C4872D5@mercury.lcs.mit.edu> References: <20041022140941.894C4872D5@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11203096-2466-11D9-89C3-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Fri, 22 Oct 2004 22:07:57 +0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-okt-04, at 16:09, Noel Chiappa wrote: >> I wasn't aware that I'm so set in my ways that people can predict >> whether I'll like something in advance... > It's not just you, almost *nobody* likes it! So I'm merely going with > the > odds! :-) Although I admit you seem to not be afraid of offbeat ideas, > so you > may well like it at a purely technical level. Although I predict you > will be > daunted by the magnitude of the change... :-) Hm... > Well, basically, I think we need to move the "path selection" function > out of the "network" (i.e. the routers), and let the hosts (or, if they > are lazy/stupid, an agent acting on their behalf) do it. To do this, > they > obviously need more information, which I claim should be maps of > network > topology. Source routing, you mean? As Marcelo explained, we are already on the path towards some very loose source routing (only the exit ISP) if we let hosts select source/destination address combinations and in the internal network there is source address based routing. > I have two standards points to make to people who roll their eyes at > this > hopeless technological naivete, and say that it's "obviously" way too > complex a job to give to the hosts: > - Back in the 1970's, the "network" took care of flow/congestion > control and > also reliability, and now hosts do all this - using some fairly complex > algorithms that took us decades to get working well. And having made > that > fundamental architectural reorganization, it's now "obvious" to > everyone that > that's the way it ought to be. > - This is the way we do cars and highways, and it seems to work just > fine. Well, based on these two arguments (especially the second) the natural progression here would be "source routering" where every packet contains the code to forward itself and routers are just big fat java virtual machines. :-) I'm not really sold on the car analogy, but I agree that fear of complexity in hosts in unfounded. Typical hosts have tons more complex algorithms on board than typical routers. However, we do want hosts to be simple with regard to the amount of configuration information they must receive before they can go about their business: it's not a good idea to have to load a full BGP table or similar topology map before a host can communicate, or to have to upgrade all hosts in order to fix interdomain routing problems (of which we have plenty). > Anyway, making this (admittedly major) architectural change kills about > 17 dozen birds, of which the "how do I pick the best address for the > destination" is one. I doubt it. There is just too much information to be able to make optimal internet-wide routing decisions before the first packet is exchanged. But that's not a big deal. If you have multiple paths, you can just add some multipath logic with per-path windows to TCP and the like and suddenly you're using all paths to capacity. (I was involved with implementing something where real-time traffic was "anycast" over several TCP streams towards different destinations. (Don't ask why we used TCP.) We were supposed to spread traffic randomly over the different TCP sessions. This was a disaster as we were now limited by the slowest. But simply skipping the sessions that were blocked because of a full window allowed us to use the combined bandwidth of all sessions.) > And yes, I know this is a really, really, *really*, ***REALLY*** big > change. But, surprisingly, when you start working through the details, > there are ways to incrementally deploy it, ways which don't mandate > changes to all hosts before it can begin to be useful. Well, we're incrementing things now for multihoming support so this might be a good time to get some of this stuff in... From owner-multi6@ops.ietf.org Fri Oct 22 17:32:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21616 for ; Fri, 22 Oct 2004 17:32:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL70m-000IxN-Se for multi6-data@psg.com; Fri, 22 Oct 2004 21:31:48 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL70l-000IxA-QF for multi6@ops.ietf.org; Fri, 22 Oct 2004 21:31:48 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9MLViNH027688; Fri, 22 Oct 2004 15:31:44 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9MLVgJQ007406; Fri, 22 Oct 2004 23:31:43 +0200 (MEST) Message-ID: <41797C6A.4020404@sun.com> Date: Fri, 22 Oct 2004 14:32:26 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: multi6@ops.ietf.org Subject: Re: draft-nordmark-multi6dt-shim-00.txt References: <4175AC71.7040504@sun.com> <355BD00C-243D-11D9-AF09-000D93ACD0FE@it> In-Reply-To: <355BD00C-243D-11D9-AF09-000D93ACD0FE@it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: > When discussing fragmentation in section 5, i guess that the question > that Margaret raised a while ago is still there i.e. if we place multi6 > below fragmentation, what happens when we have a full MTU packet and we > need to add an extension header? The packetization layer (such as TCP) needs to be aware of this, which isn't any different than how an implementation makes TCP aware that ESP or AH will be added to a packet, or that it will be subject to IP-in-IP tunneling overhead. > In section 8.4 it is stated that: > > This might be the case when the two > hosts have already communicated, and it might be possible to have the > DNS resolver library provide alternate locators to the shim in the > speculation that they might be useful. > > I have two issues with this: > - first: wouldn't this impose a new RR or something similar? i mean how > does the DNS knows that all the locators belong to the same endpoint? i > guess this is not really compatible with section 7... I believe you are right, but it might be possible to solve this. If the attempts to talk to the peer using another AAAA record (which may or may not point to the same host) include the ULID then the peer can respond with "not me", which would allow the multi6 layer to try all the AAAA records which do point at the same host. Of course, if there is only one AAAA record per host (but multiple AAAA records pointing at different hosts) this is just a waste of time. Even if say, the multi6 layer tries 2 records out of 10 which happen to point to the same host, but are unreachable (e.g. because the host is down), then the application layer needs to try the other 8. But the application layer wouldn't know that multiple AAAAs have been tried by the multi6 shim below; it just has a list of 10 ULIDs to try. So it would end up trying all 10. > - second: this would introduce a new way to learn additional locators > (the noid like mechanism) This mechanism may have different trust levels > than the one available for learning locators during the communication > lifetime. Wouldn't this introduce some trust problems? It does have different properties, but I don't think it matters in practice because it is the mechanism the host uses to learn different ULIDs. Erik From owner-multi6@ops.ietf.org Sat Oct 23 02:02:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18716 for ; Sat, 23 Oct 2004 02:02:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLExh-000OIe-44 for multi6-data@psg.com; Sat, 23 Oct 2004 06:01:09 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLExg-000OII-34 for multi6@ops.ietf.org; Sat, 23 Oct 2004 06:01:08 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9N614e21342; Sat, 23 Oct 2004 09:01:05 +0300 (EET DST) X-Scanned: Sat, 23 Oct 2004 09:01:01 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9N611GS003691; Sat, 23 Oct 2004 09:01:01 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00yzjT4D; Sat, 23 Oct 2004 09:01:01 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9N610S02799; Sat, 23 Oct 2004 09:01:00 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 23 Oct 2004 09:01:00 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 23 Oct 2004 09:00:59 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 23 Oct 2004 09:00:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Sat, 23 Oct 2004 09:00:58 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDED@esebe056.ntc.nokia.com> Thread-Topic: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Thread-Index: AcS4UivAi9SmI4WRR1Wkt9VpmciPUgAc1X8Q From: To: Cc: X-OriginalArrivalTime: 23 Oct 2004 06:00:57.0879 (UTC) FILETIME=[AA521270:01C4B8C5] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari, Marcelo, > > So we don't really need to know information about all the possible=20 > > complete paths, just the ingress and egress parts of the path. I = guess=20 > > that this problem is more reduced and less ambitious than the = general one. >=20 > Right. >=20 > The other reduction is that I'm not sure we need to solve > the "best path" problem but solving even the "a working > path" problem might be sufficient. That's at least my > preference. Exactly; my thought has always been that we need to avoid the non-working path(s) & that would be sufficient. John From owner-multi6@ops.ietf.org Sat Oct 23 09:08:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24747 for ; Sat, 23 Oct 2004 09:08:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLLbV-000KwT-R8 for multi6-data@psg.com; Sat, 23 Oct 2004 13:06:41 +0000 Received: from [32.97.110.129] (helo=e31.co.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLLbU-000Kv6-MA for multi6@ops.ietf.org; Sat, 23 Oct 2004 13:06:40 +0000 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9ND6dLv485754 for ; Sat, 23 Oct 2004 09:06:40 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9ND6dB9109356 for ; Sat, 23 Oct 2004 07:06:39 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9ND6cYe009086 for ; Sat, 23 Oct 2004 07:06:38 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9ND6bgE009073; Sat, 23 Oct 2004 07:06:37 -0600 Received: from zurich.ibm.com (sig-9-146-222-30.de.ibm.com [9.146.222.30]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA79540; Sat, 23 Oct 2004 15:06:35 +0200 Message-ID: <417A575F.4000702@zurich.ibm.com> Date: Sat, 23 Oct 2004 15:06:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Cedric de Launois CC: "Michael H. Lambert" , Multi6 Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> <37EA750A-243B-11D9-BDEB-000D93289530@psc.edu> <1098459398.23282.157.camel@descartes.info.ucl.ac.be> In-Reply-To: <1098459398.23282.157.camel@descartes.info.ucl.ac.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Cedric de Launois wrote: > Le ven 22/10/2004 à 17:01, Michael H. Lambert a écrit : > >>Given that the "best path" probably just has meaning for a given >>application between given hosts at a given point in time, how often do >>we *really* need the *best* path? > > > The goal is not much to have the *best* path, but to avoid really bad > paths. > > >>Best effort usually works well enough for forwarding--why shouldn't it >>do the same for path selection? (I think Noel implied this in his >>response--to use his highway analogy: in driving from Boston to San >>Francisco saving six hours is good, saving ten minutes is (usually) >>irrelevant?) >> >>Since the One True Best Path is likely unknowable anyway, why >>complicate path selection by building SVCs (or MPLS tunnels) into it? > > > In the multi-address multi6 case, path selection is simply done by > selecting the right source and destination prefixes. If a host can > figure out which are the couples (src,dst) prefixes to avoid, then the > benefit can be huge. This doesn't require tunnels in any ways. Well, there remains the exit router selection issue - I think one of the proposed solutions to that did in fact require a (short) tunnel. Brian From owner-multi6@ops.ietf.org Sat Oct 23 09:11:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24997 for ; Sat, 23 Oct 2004 09:11:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLLgJ-000Lp6-SO for multi6-data@psg.com; Sat, 23 Oct 2004 13:11:39 +0000 Received: from [32.97.182.101] (helo=e1.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLLgI-000Lor-OM for multi6@ops.ietf.org; Sat, 23 Oct 2004 13:11:39 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i9NDBbUl373348 for ; Sat, 23 Oct 2004 09:11:37 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NDBa0v140730 for ; Sat, 23 Oct 2004 09:11:37 -0400 Received: from zurich.ibm.com (sig-9-146-222-30.de.ibm.com [9.146.222.30]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA79390 for ; Sat, 23 Oct 2004 15:11:35 +0200 Message-ID: <417A588B.9090508@zurich.ibm.com> Date: Sat, 23 Oct 2004 15:11:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: [Fwd: I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt] References: <1098217103.2150.145.camel@127750> <6C6E7BEA-2429-11D9-89C3-000A95CD987A@muada.com> In-Reply-To: <6C6E7BEA-2429-11D9-89C3-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's clear that our goal in multi6 is to not create any *new* privacy issues compared to monohoming. I've haven't had a chance to read the draft yet, but all we need to do here is check that question for whatever solution proposal emerges. Brian Iljitsch van Beijnum wrote: > On 19-okt-04, at 22:18, Wassim Michel Haddad wrote: > >>> This memo describes the privacy in mobility and multi-homing problem >>> statement. > > >>> http://www.ietf.org/internet-drafts/draft-haddad-momipriv-problem- >>> statement-00.txt > > > I'm not happy about this singling out privacy issues like this, because > it implicitly says "more privacy is better". That's certainly not the > case: there needs to be a balance between privacy and accountability. > Today, the internet operator community has huge problems with all kinds > of abuse conducted by people who manage to hide behind other's systems > they managed to corrupt. We can't have privacy extensions make these > problems worse. > > "Note that while using only a different IPv6 address for each > new session may prevent/mitigate the ability to trace a MN on > the IP layer level, it remains always possible to trace it > through its device identifier(s) on the MAC layer level and > consequently, to learn all IPv6 addresses used by the MN by > correlating different sessions, thus breaking any unlinkability > protection provided at the IP layer." > > Huh??? This is certainly not universally true. > > Another issue is that the references are all towards drafts and not > RFCs. This is very bad because 1. people tend to know the RFCs and not > necessarily the drafts and 2. drafts disappear after a while. > > From owner-multi6@ops.ietf.org Sat Oct 23 09:36:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25991 for ; Sat, 23 Oct 2004 09:36:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLM3U-00002m-Mf for multi6-data@psg.com; Sat, 23 Oct 2004 13:35:36 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLM3T-000021-CA for multi6@ops.ietf.org; Sat, 23 Oct 2004 13:35:35 +0000 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id i9NDZTFk014801; Sat, 23 Oct 2004 15:35:29 +0200 (MET DST) Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming From: Olivier Bonaventure To: marcelo bagnulo braun Cc: multi6@ops.ietf.org In-Reply-To: References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> Content-Type: text/plain Message-Id: <1098538529.5847.9.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 23 Oct 2004 15:35:30 +0200 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Just a nit, note that in multihoming we are only selection addresses, > not full paths. > This means that we are selecting the ingress and egress ISP of the > source and destination sites, but that the interdomain path will be > selected with other means i.e. BGP. Agreed, but given that most AS-level paths on the Internet today are between 3 to 5 AS hops, selecting the ingress ISP and the egress ISP means that in practice you select most of the end-to-end path at the AS level. This will remain true unless the diameter of the Internet increases due to IPv6 multihoming... Olivier From owner-multi6@ops.ietf.org Sat Oct 23 15:07:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15794 for ; Sat, 23 Oct 2004 15:07:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLRC3-0007cU-Fi for multi6-data@psg.com; Sat, 23 Oct 2004 19:04:47 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLRC2-0007cB-C0 for multi6@ops.ietf.org; Sat, 23 Oct 2004 19:04:46 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9NJ5GQx042370; Sat, 23 Oct 2004 21:05:17 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <417A588B.9090508@zurich.ibm.com> References: <1098217103.2150.145.camel@127750> <6C6E7BEA-2429-11D9-89C3-000A95CD987A@muada.com> <417A588B.9090508@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <664DAA6E-2526-11D9-89C3-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: [Fwd: I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt] Date: Sat, 23 Oct 2004 21:04:43 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-okt-04, at 15:11, Brian E Carpenter wrote: > It's clear that our goal in multi6 is to not create any *new* > privacy issues compared to monohoming. IPv4-style multihomed sites must register their details in one or more whois databases. That would be just as good a baseline as single homing in IPv6. From owner-multi6@ops.ietf.org Sat Oct 23 22:02:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07898 for ; Sat, 23 Oct 2004 22:02:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLXg3-0005C1-L3 for multi6-data@psg.com; Sun, 24 Oct 2004 02:00:11 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLXg2-0005Bh-Ls for multi6@ops.ietf.org; Sun, 24 Oct 2004 02:00:10 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D97DD2F844; Sun, 24 Oct 2004 04:00:10 +0200 (CEST) Received: from [163.117.252.226] (vpn-252-226.uc3m.es [163.117.252.226]) by smtp03.uc3m.es (Postfix) with ESMTP id E1CF52F82B; Sun, 24 Oct 2004 04:00:09 +0200 (CEST) In-Reply-To: <1098538529.5847.9.camel@pcobo> References: <1095859404.23282.39.camel@descartes.info.ucl.ac.be> <1098538529.5847.9.camel@pcobo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <745F9A70-2560-11D9-8D26-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Sun, 24 Oct 2004 04:00:18 +0200 To: Olivier Bonaventure X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 23/10/2004, a las 15:35, Olivier Bonaventure escribi=F3: > >> Just a nit, note that in multihoming we are only selection addresses, >> not full paths. >> This means that we are selecting the ingress and egress ISP of the >> source and destination sites, but that the interdomain path will be >> selected with other means i.e. BGP. > > Agreed, but given that most AS-level paths on the Internet today are > between 3 to 5 AS hops, even if this is true.... > selecting the ingress ISP and the egress ISP > means that in practice you select most of the end-to-end path at the = AS > level. this is not trivially true, since the e2e path is determined by all the=20= routers in the path, not only the ASes I mean, there is still a long way between selecting the ingress and=20 egress IPS (through the address selection) and selecting the complete=20 path at the source i.e. the source node specifying all the routers but anyway, i think we are diverging... regards, marcelo > This will remain true unless the diameter of the Internet > increases due to IPv6 multihoming... > > > Olivier > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------=20= From owner-multi6@ops.ietf.org Sun Oct 24 00:02:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13888 for ; Sun, 24 Oct 2004 00:02:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLZYT-0004qd-Gk for multi6-data@psg.com; Sun, 24 Oct 2004 04:00:29 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLZYS-0004qA-Gw for multi6@ops.ietf.org; Sun, 24 Oct 2004 04:00:28 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 8894C653 for ; Sun, 24 Oct 2004 00:00:27 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 24 Oct 2004 00:00:27 -0400 Message-Id: <20041024040027.8894C653@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 24.44% | 11 | 30.61% | 49279 | marcelo@it.uc3m.es 13.33% | 6 | 12.28% | 19766 | brc@zurich.ibm.com 13.33% | 6 | 11.85% | 19070 | iljitsch@muada.com 8.89% | 4 | 11.53% | 18568 | erik.nordmark@sun.com 6.67% | 3 | 5.12% | 8236 | jnc@mercury.lcs.mit.edu 4.44% | 2 | 6.40% | 10296 | internet-drafts@ietf.org 4.44% | 2 | 3.76% | 6047 | delaunois@info.ucl.ac.be 4.44% | 2 | 3.15% | 5078 | jari.arkko@piuha.net 4.44% | 2 | 2.96% | 4758 | davidg@pipex.net 2.22% | 1 | 2.18% | 3516 | john.loughney@nokia.com 2.22% | 1 | 1.98% | 3194 | tjc@ecs.soton.ac.uk 2.22% | 1 | 1.91% | 3076 | torus@tori.cc 2.22% | 1 | 1.88% | 3031 | lambert@psc.edu 2.22% | 1 | 1.58% | 2545 | wassim.haddad@ericsson.ca 2.22% | 1 | 1.53% | 2461 | bonaventure@info.ucl.ac.be 2.22% | 1 | 1.28% | 2063 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 160984 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Oct 24 04:28:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10013 for ; Sun, 24 Oct 2004 04:28:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLdi6-0001H0-32 for multi6-data@psg.com; Sun, 24 Oct 2004 08:26:42 +0000 Received: from [212.68.1.186] (helo=pegasus.hiit.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLdi4-0001Gd-Qc for multi6@ops.ietf.org; Sun, 24 Oct 2004 08:26:41 +0000 Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 66CF522000B; Sun, 24 Oct 2004 11:26:37 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 534DC8; Sun, 24 Oct 2004 11:26:38 +0300 (EEST) In-Reply-To: <20041022140941.894C4872D5@mercury.lcs.mit.edu> References: <20041022140941.894C4872D5@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6E4BDBA2-2596-11D9-919C-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Pekka Nikander Subject: [OT] Moving "path selection" to the end hosts (was Re: On the use of multiple PA prefixes ...) Date: Sun, 24 Oct 2004 11:26:40 +0300 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel, This starts to be off-topic for the multi6 list, but... > Well, basically, I think we need to move the "path selection" function > out of the "network" (i.e. the routers), and let the hosts (or, if they > are lazy/stupid, an agent acting on their behalf) do it. To do this, > they > obviously need more information, which I claim should be maps of > network > topology. > > ... > > Anyway, making this (admittedly major) architectural change kills about > 17 dozen birds, of which the "how do I pick the best address for the > destination" is one. ... I'd like to hear what are some of these 17 dozen birds. I'm admittedly a layman in routing, but thinking about the amount of routing information and its stability, it appears to me that it will anyway be necessary to provide aggregated versions of this information at various levels. Hence, it sounds reasonable to assume that a host could have some better knowledge about the network topology (and perhaps congestion state) "close" to it, but less information, or more aggregated information, about what happens further away. Hence, any path selection performed by the end hosts will be, at best, an approximation. I could imagine that two (or a group of) communicating hosts could jointly be able to make a fairly good approximation of the routing state close to them, and thereby make a good selection about which local paths to use among the available ones. Combining this information with upper layer RTT and bandwidth estimates, the hosts might be able to create some kind of a local model about the traffic characteristics of the paths, but only over time. In the case of site multi-homing, sharing this information with other hosts on the site may make sense, just as a number of people have pointed out. Based on this straw man analysis, I get the feeling that moving path selection to the end hosts might be good because - the end hosts may use information from their peers to make better selections, and - the end hosts may more easily use dynamic upper layer congestion information to revise their choices on need On the other hand, either network assistance or letting the network to do the selection looks good because - the network may learn more from a number of end-hosts, thereby being able to create a more accurate model of the network condition - the network needs to have this topology information anyway, as we cannot expect the hosts to learn the topology without some help from the routers The situation seems to be become more interesting if we assume that there is a full blown id/loc split in place. That would allow the network to have more dynamic IP addresses, slowly changing the addresses to better match the actual network topology. Under such conditions, it becomes an interesting exercise to figure out how to represent the actual topology, as IP addresses cannot be directly used to represent nodes, and identifiers are unlikely to be directly aggregatable. Anyway, I fail to clearly see the consequences of such a change, i.e. moving "path selection" to end hosts, and would like to hear more about your insights. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Oct 24 16:51:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29561 for ; Sun, 24 Oct 2004 16:51:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLpIY-000LnY-Rj for multi6-data@psg.com; Sun, 24 Oct 2004 20:49:06 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLpIX-000LnI-Mv for multi6@ops.ietf.org; Sun, 24 Oct 2004 20:49:06 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9OKnTQx057182; Sun, 24 Oct 2004 22:49:30 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D1FFDED@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D1FFDED@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F556562-25FE-11D9-89C3-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Sun, 24 Oct 2004 22:48:56 +0200 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-okt-04, at 8:00, wrote: >> The other reduction is that I'm not sure we need to solve >> the "best path" problem but solving even the "a working >> path" problem might be sufficient. That's at least my >> preference. > Exactly; my thought has always been that we need to avoid > the non-working path(s) & that would be sufficient. Avoiding non-working paths goes to the core of what's multihoming all about, so this is something we absolutely need. But I'm not sure it's all we need. What I'm worried about is the situation where there are multiple working paths, but there is a large difference in quality between them. For instance, one path has a capacity of 100 Mbps and another a capacity of 1 Mbps. In this case, selecting the latter path as part of regular operation would hardly be acceptable. We _may_ be able to bring this problem back to manageable proportions by taking advantage of the information both ends have. So if either end knows that the second path is much slower, they'll avoid it as long as the first path is operational. This leaves only the cases where there is congestion in the core, which is pretty rare these days. (But this hasn't always been the case...) Note that the whole reachability detection problem isn't as simple as it may seem at first, especially when we want to make use of unidirectional paths. Until not very long ago, I was favoring a "cartesian ping bomb" approach where there are reachability probes for all { src, dst } combinations. However, this can cause massive congestion when a link fails for a busy site, and it's also complex and most likely slow. My current homework for the design team is to look how protocols such as OSPF and especially STUN implement similar features and see what we can borrow there. Unless this provides significant new insights I want so see if we can make a "be optimistic but check first" approach work. This means that when the reachability heuristics determine that there may be a path failure, we check the current path. If there is a failure, we check the next best path (for whatever "best" means locally) and so on, until we find one that works. In order to detect unidirectional reachability without excessive numbers of packets, each probe contains information about the last few multihoming signaling packets received from the other side. So unidirectional reachability won't be detected as fast as bidirectional reachability, but eventually it will. I think we can probably tune this process such that significantly better (= lower RTT) paths are often discovered without any additional effort. This would be accomplished by having an artificially low timeout for the initial reachability test. (Successive ones should probably use an (exponential?) backoff.) So we send probe A->X and then 25 ms later B->Y. If the difference between RTT is bigger than 25 ms, the second probe will be answered first and we're in business. But if the RTT difference is smaller than 25 ms we'll still get a reply for the second probe after the reply for the first probe was received, as long as this one took longer than 25 ms. This works pretty well for a certain range of RTTs, only with very short ones we don't see better paths and with very long ones we send too many packets. If we can make the initial timeout a function of a previously established RTT we can probably get around this. Another way to get around selecting a working, but non-optimal path is allowing applications to set an "impatient" flag which then triggers more extensive path evaluation. :-) From owner-multi6@ops.ietf.org Sun Oct 24 23:35:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25853 for ; Sun, 24 Oct 2004 23:35:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLvcM-0000jY-Nv for multi6-data@psg.com; Mon, 25 Oct 2004 03:33:58 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLvcL-0000jE-OP for multi6@ops.ietf.org; Mon, 25 Oct 2004 03:33:58 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P3Xpe20359; Mon, 25 Oct 2004 06:33:52 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 06:32:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9P3WIkQ018245; Mon, 25 Oct 2004 06:32:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00JIIPXn; Mon, 25 Oct 2004 06:32:16 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P3WEa11890; Mon, 25 Oct 2004 06:32:14 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 06:32:14 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 06:32:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OT] Moving "path selection" to the end hosts (was Re: On the use of multiple PA prefixes ...) Date: Mon, 25 Oct 2004 06:32:10 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDF6@esebe056.ntc.nokia.com> Thread-Topic: [OT] Moving "path selection" to the end hosts (was Re: On the use of multiple PA prefixes ...) Thread-Index: AcS5o9v2BC6+DQc6TiKt+jQD+YlyrwAnsTKw From: To: , Cc: X-OriginalArrivalTime: 25 Oct 2004 03:32:14.0491 (UTC) FILETIME=[38649EB0:01C4BA43] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Noel, > Based on this straw man analysis, I get the feeling that moving > path selection to the end hosts might be good because >=20 > - the end hosts may use information from their peers to make > better selections, and >=20 > - the end hosts may more easily use dynamic upper layer > congestion information to revise their choices on need We are moving towards this anyway. Wireless networks usually require a fair amount of information on which network to log into, with which credentials; and which network - private operator network, public Internet, corporate intranet, etc. VPN software usually requires one to know where to log into,=20 which gateway to connect to and so on. =20 I would note that a lot of this is more related to host multihoming than site multihoming, however any solution for site multihoming will probably require more intelligence in the end-host anyway. John From owner-multi6@ops.ietf.org Mon Oct 25 00:17:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28597 for ; Mon, 25 Oct 2004 00:17:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLwHj-0008NA-49 for multi6-data@psg.com; Mon, 25 Oct 2004 04:16:43 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLwHh-0008Mc-Ut for multi6@ops.ietf.org; Mon, 25 Oct 2004 04:16:42 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P4Gc325016; Mon, 25 Oct 2004 07:16:39 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 07:15:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9P4Fq1K010444; Mon, 25 Oct 2004 07:15:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00tAgtgg; Mon, 25 Oct 2004 07:15:51 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P4Fma19438; Mon, 25 Oct 2004 07:15:48 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 07:15:49 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 07:15:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Mon, 25 Oct 2004 07:15:48 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D09582A@esebe056.ntc.nokia.com> Thread-Topic: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Thread-Index: AcS6Cwdkyyerc/baQDKGjQXI+ZL7ggAPQuNA From: To: Cc: X-OriginalArrivalTime: 25 Oct 2004 04:15:48.0641 (UTC) FILETIME=[4E8C4110:01C4BA49] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Iljitsh, > Avoiding non-working paths goes to the core of what's multihoming all=20 > about, so this is something we absolutely need. But I'm not sure it's=20 > all we need. What I'm worried about is the situation where there are=20 > multiple working paths, but there is a large difference in quality=20 > between them. For instance, one path has a capacity of 100 Mbps and=20 > another a capacity of 1 Mbps. In this case, selecting the latter path=20 > as part of regular operation would hardly be acceptable. >=20 > We _may_ be able to bring this problem back to manageable proportions=20 > by taking advantage of the information both ends have. So if either = end=20 > knows that the second path is much slower, they'll avoid it as long as = > the first path is operational. This leaves only the cases where there=20 > is congestion in the core, which is pretty rare these days. (But this=20 > hasn't always been the case...) >=20 So, it seems like the problem might be moving into a general path = selection problem, which can be used for many things than just multihoming. I'm not completely opposed to this, but want to warn that there are a lot of details that will not be so simple. Perhaps we need to scope this = problem pretty well before going down this path. In terms of 'best' path, I can think of lots of factors - latency, = bandwidth, most active, least active, lowest cost and so on. Possibly selecting a path based on the various combinations of the above for 2 endpoints seems fairly challenging, so I'm not so optimistic that this is a = solvable problem in the short term. > Note that the whole reachability detection problem isn't as simple as=20 > it may seem at first, especially when we want to make use of=20 > unidirectional paths. Until not very long ago, I was favoring a=20 > "cartesian ping bomb" approach where there are reachability probes for = > all { src, dst } combinations. However, this can cause massive=20 > congestion when a link fails for a busy site, and it's also complex = and=20 > most likely slow. Agreed. Even if you did this, then you would need some sort of = mechanism to evaluate the paths after determining reachability. I know some people have discussed a next generation trace route that would collect = statistics about the hops along a particular path. Put that onto your "cartesian = ping bomb" and you might have a solution, but at what cost? John From owner-multi6@ops.ietf.org Mon Oct 25 00:19:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28708 for ; Mon, 25 Oct 2004 00:19:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLwKp-0008xv-Mw for multi6-data@psg.com; Mon, 25 Oct 2004 04:19:55 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLwKo-0008xd-LP for multi6@ops.ietf.org; Mon, 25 Oct 2004 04:19:54 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P4Jql18830; Mon, 25 Oct 2004 07:19:53 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 07:18:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9P4ILYj032683; Mon, 25 Oct 2004 07:18:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00UnjQVp; Mon, 25 Oct 2004 07:18:19 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P4IJS14655; Mon, 25 Oct 2004 07:18:19 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 07:18:20 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 07:18:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Date: Mon, 25 Oct 2004 07:18:18 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDFB@esebe056.ntc.nokia.com> Thread-Topic: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Thread-Index: AcS3TP46ooKgjueVRzurZhJplgc/bAC/GQxQ From: To: , Cc: X-OriginalArrivalTime: 25 Oct 2004 04:18:19.0724 (UTC) FILETIME=[A899B0C0:01C4BA49] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Marcelo, > > My minor substantive comments are below. > > Some editorial comments were sent direct to the author. > > > > > 4.2 Multi-Homing: Mobility > > ... > > > The aspect of MIPv6 which appears to present issues in the = context of > > > multi-homing is the return routeability mechanism. In MIPv6 = identity > > > validity is periodically tested by return routeability of the > > > identity address. This regular use of a distinguished locator = as the > > > identity token cannot support return reachability in the = multi-homing > > > context in the event of extended path failure of the path that = is > > > associated with the identity locator. > > > > This question isn't really relevant to multi6, >=20 > Well, lots of people claim that there is a close relation between=20 > multihoming and mobility, since both problmes require changing the=20 > locators and keep the identifier. > Since there is an available solution for mobility, it seems quite=20 > natural to explore if such solution is suitable for multihoming. > The problem with the available solution for mobility is that the=20 > security mechanism used in mip is inherently incompatible with the=20 > multihoming requirements, since it is based on reaching the=20 > identifier. >=20 > so imho it is relevant to multihoming the explanation why the approach = > used for mobility is not suitable for multihoming. I agree with Marcelo, but with the caveat that solving mobility problems is not a goal of Multi6. Learning from mobility solutions is a good = thing, though. John From owner-multi6@ops.ietf.org Mon Oct 25 01:30:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04627 for ; Mon, 25 Oct 2004 01:30:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLxPc-000JX9-4G for multi6-data@psg.com; Mon, 25 Oct 2004 05:28:56 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLxPa-000JWj-Pl for multi6@ops.ietf.org; Mon, 25 Oct 2004 05:28:55 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9CA7C89887; Mon, 25 Oct 2004 08:28:53 +0300 (EEST) Message-ID: <417C8EB3.4030500@piuha.net> Date: Mon, 25 Oct 2004 08:27:15 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Multi6 List Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <3CF661B1787ABF41A869BE20108F8D6D1FFDED@esebe056.ntc.nokia.com> <1F556562-25FE-11D9-89C3-000A95CD987A@muada.com> In-Reply-To: <1F556562-25FE-11D9-89C3-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Avoiding non-working paths goes to the core of what's multihoming all > about, so this is something we absolutely need. But I'm not sure it's > all we need. What I'm worried about is the situation where there are > multiple working paths, but there is a large difference in quality > between them. For instance, one path has a capacity of 100 Mbps and > another a capacity of 1 Mbps. In this case, selecting the latter path as > part of regular operation would hardly be acceptable. I agree that we have some remaining issues. To give you another example, switching from a 50 Mbps LAN to a 20 Kbps GRPS might be needed when the LAN goes down at some point. However, what do we do when the LAN comes back up again later? The slower interface still works, so there's no need to do failover. But you'd really want to switch... > We _may_ be able to bring this problem back to manageable proportions by > taking advantage of the information both ends have. So if either end > knows that the second path is much slower, they'll avoid it as long as > the first path is operational. This leaves only the cases where there is > congestion in the core, which is pretty rare these days. (But this > hasn't always been the case...) Hmm... I guess the issue is whether either end knows. I'm not sure the assumption that you know/test what the L2 does is any better than the assumption that you know/test what the core does. I'm not really afraid of testing the speed of a path, but what I am afraid is the interaction with ULPs. We really don't want Multi6 and TCP and whatnot testing all the same thing and second guessing each other. > Note that the whole reachability detection problem isn't as simple as it > may seem at first, especially when we want to make use of unidirectional > paths. Until not very long ago, I was favoring a "cartesian ping bomb" > approach where there are reachability probes for all { src, dst } > combinations. However, this can cause massive congestion when a link > fails for a busy site, and it's also complex and most likely slow. Yes. In http://www.arkko.com/publications/multi6/faildet.html#anchor9 we did the math, and with the quite reasonable assumption of exponential back-off, testing all combinations of addresses with just four addresses on each side would last 3200 seconds. > My current homework for the design team is to look how protocols such as > OSPF and especially STUN implement similar features and see what we can > borrow there. Unless this provides significant new insights I want so > see if we can make a "be optimistic but check first" approach work. This > means that when the reachability heuristics determine that there may be > a path failure, we check the current path. If there is a failure, we > check the next best path (for whatever "best" means locally) and so on, > until we find one that works. In order to detect unidirectional > reachability without excessive numbers of packets, each probe contains > information about the last few multihoming signaling packets received > from the other side. So unidirectional reachability won't be detected as > fast as bidirectional reachability, but eventually it will. This is the algorithm in http://www.arkko.com/publications/multi6/faildet.html#sketch The part about using heuristics to try the address (pairs) is good. But I think the worst case behaviour is still bad. Remember that even getting a packet from A to B means that you both have to have the source set so that its currently routable, the destination so that its currently routable, and that its routable from this source. > Another way to get around selecting a working, but non-optimal path is > allowing applications to set an "impatient" flag which then triggers > more extensive path evaluation. :-) Do you mean the "I am in a hurry, screw the others if this causes congestion" -flag? ;-) I fear that the things that we want to do would really require better good knowledge of the current RTTs of the paths. This can be measured, but there's a tradeoff in how far we want to venture in the territory of TCP vs. how good our information is. --Jari From owner-multi6@ops.ietf.org Mon Oct 25 01:55:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06414 for ; Mon, 25 Oct 2004 01:55:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLxp6-000OFg-UU for multi6-data@psg.com; Mon, 25 Oct 2004 05:55:16 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLxp5-000OFK-Ou for multi6@ops.ietf.org; Mon, 25 Oct 2004 05:55:16 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P5tAt12237; Mon, 25 Oct 2004 08:55:11 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 08:54:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9P5sppl007324; Mon, 25 Oct 2004 08:54:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00yWcjRV; Mon, 25 Oct 2004 08:54:49 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9P5sba08523; Mon, 25 Oct 2004 08:54:37 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 08:54:33 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 08:54:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Mon, 25 Oct 2004 08:54:33 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D09582C@esebe056.ntc.nokia.com> Thread-Topic: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Thread-Index: AcS6VArWj+9HXorDTA+VbqnV+hB5bgAAa7iQ From: To: , Cc: X-OriginalArrivalTime: 25 Oct 2004 05:54:33.0325 (UTC) FILETIME=[19EF49D0:01C4BA57] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari, > > Avoiding non-working paths goes to the core of what's multihoming = all=20 > > about, so this is something we absolutely need. But I'm not sure = it's=20 > > all we need. What I'm worried about is the situation where there are = > > multiple working paths, but there is a large difference in quality=20 > > between them. For instance, one path has a capacity of 100 Mbps and=20 > > another a capacity of 1 Mbps. In this case, selecting the latter = path as=20 > > part of regular operation would hardly be acceptable. >=20 > I agree that we have some remaining issues. To give you > another example, switching from a 50 Mbps LAN to a 20 Kbps > GRPS might be needed when the LAN goes down at some point. > However, what do we do when the LAN comes back up again later? > The slower interface still works, so there's no need to do > failover. But you'd really want to switch... Let's take the corner case of 50 Kbps GRPS vs 200 Kbps WLAN behind DSL. You might prefer the WLAN connection, but the GPRS might be more stable. I think you also want to avoid ping-ponging between the interfaces as well, so being prudent here is an important issue. > > We _may_ be able to bring this problem back to manageable = proportions by=20 > > taking advantage of the information both ends have. So if either end = > > knows that the second path is much slower, they'll avoid it as long = as=20 > > the first path is operational. This leaves only the cases where = there is=20 > > congestion in the core, which is pretty rare these days. (But this=20 > > hasn't always been the case...) >=20 > Hmm... I guess the issue is whether either end knows. I'm not > sure the assumption that you know/test what the L2 does is any better > than the assumption that you know/test what the core does. >=20 > I'm not really afraid of testing the speed of a path, but what > I am afraid is the interaction with ULPs. We really don't want > Multi6 and TCP and whatnot testing all the same thing and second > guessing each other. Exactly. =20 > > Note that the whole reachability detection problem isn't as simple = as it=20 > > may seem at first, especially when we want to make use of = unidirectional=20 > > paths. Until not very long ago, I was favoring a "cartesian ping = bomb"=20 > > approach where there are reachability probes for all { src, dst }=20 > > combinations. However, this can cause massive congestion when a link = > > fails for a busy site, and it's also complex and most likely slow. >=20 > Yes. In http://www.arkko.com/publications/multi6/faildet.html#anchor9 > we did the math, and with the quite reasonable assumption of = exponential > back-off, testing all combinations of addresses with just four = addresses > on each side would last 3200 seconds. So, I should read your draft (on my reading pile) but are there = simplifying assumptions? If we look at site multihoming, we might not need to test all addresses. For example, in a VPN case, there might only be a = handful of VPN gateways. Instead of testing all of the destination addresses, we might need just to test the different VPN gateways. Additional constraints are probably possible based upon site configuration. > > My current homework for the design team is to look how protocols = such as=20 > > OSPF and especially STUN implement similar features and see what we = can=20 > > borrow there. Unless this provides significant new insights I want = so=20 > > see if we can make a "be optimistic but check first" approach work. = This=20 > > means that when the reachability heuristics determine that there may = be=20 > > a path failure, we check the current path. If there is a failure, we = > > check the next best path (for whatever "best" means locally) and so = on,=20 > > until we find one that works. In order to detect unidirectional=20 > > reachability without excessive numbers of packets, each probe = contains=20 > > information about the last few multihoming signaling packets = received=20 > > from the other side. So unidirectional reachability won't be = detected as=20 > > fast as bidirectional reachability, but eventually it will. You might want to consult ICE: Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-02.txt > > Another way to get around selecting a working, but non-optimal path = is=20 > > allowing applications to set an "impatient" flag which then triggers = > > more extensive path evaluation. :-) >=20 > Do you mean the "I am in a hurry, screw the others if this > causes congestion" -flag? ;-) >=20 > I fear that the things that we want to do would really require > better good knowledge of the current RTTs of the paths. This > can be measured, but there's a tradeoff in how far we want > to venture in the territory of TCP vs. how good our information > is. Agreed. I think if we go down this route, it would be very important to engage TSVWG types into the discussion. TCP has a very conservative approach to this. TCP Quick Start is an interesting algorithm that might be applicable here: http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt Finally, a big issue is also L2 Indications. I think that we might be able to assist any multihoming if we consider L2 indicators. Lots of work has been done in the transport area about l2 indicators. A good summary can be found here: http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt John From owner-multi6@ops.ietf.org Mon Oct 25 02:48:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24274 for ; Mon, 25 Oct 2004 02:48:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLyd7-0005fi-2Q for multi6-data@psg.com; Mon, 25 Oct 2004 06:46:57 +0000 Received: from [192.68.245.115] (helo=mail.nttv6.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLyd5-0005fU-RW for multi6@ops.ietf.org; Mon, 25 Oct 2004 06:46:56 +0000 Received: from [10.0.22.187] ([192.16.178.225]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id i9P6ibJi003423; Mon, 25 Oct 2004 15:44:37 +0900 (JST) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Arifumi Matsumoto Subject: Re: New I-D Submitted (Re: Newbie Question about addressing impacts) Date: Mon, 25 Oct 2004 15:47:34 +0900 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, thank you for your comments. On 2004/10/22, at 21:41, Iljitsch van Beijnum wrote: > On 15-okt-04, at 11:01, Arifumi Matsumoto wrote: > >> In short, in our model, ISPs provide Source Address Selection >> Policies as well as Prefix Delegation Info by DHCP. >> The consumer edge router receives those policies (from >> multiple ISPs) and re-distribute them to end nodes. >> End nodes put them into policy table, which leads to >> appropriate source address selection. > >> http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist >> -00.txt > > Hm, I'm worried about the policy information becoming too extensive to > fit comfortably in DHCP or RA packets. I guess it would be possible to > broadcast basic policy information this way and then create a cache of > more specific information on-demand, e.g. when ICMP messages come in. > > (The advantage of using RA here is that when connectivity changes, a > lot of hosts can be informed quickly about a new policy.) As you mention it, each method seems to have both merits and demerits. IMHO, one of the demerits of ICMP error method is: When an error occurs, packets have to be re-sent by the end host and the host has to change the src-ip of the packets. This can cause unignorable impacts on upper layers(L4 and above). We might have to modify upper layers more than a bit. Our proposal just makes use of the existing RFC 3484 mechanism and doesn't demand such modifications. As for the packet size issue, we are thinking of some devices. - We've adopted prefix space compression in RA. Almost all the prefixes in SAS Policy are expected to be less than 64-bit length, so it is wasteful to allocate 128-bit space for each prefix field. - We are also thinking of cutting down SAS Policy option, for example, once a minute, once every two packets or only for router solicitation. - In cooperation with DHCP, RA only specifies O flag and SAS Policy information is delivered by DHCP. >> http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- >> selection-opt-00.txt >> http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- >> selection-opt-00.txt > > Why must the padding be ones? On many systems, newly allocated memory > is filled with zeros, so this would be easier. And then there's > tradition. :-) This may look a bit tricky. This is because 8-bit zero field means "::/0" in our specification. But this is not essential, and can be changed by introducing "number of prefix" field or something like that. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From owner-multi6@ops.ietf.org Mon Oct 25 05:02:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02513 for ; Mon, 25 Oct 2004 05:02:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM0io-000PTQ-G0 for multi6-data@psg.com; Mon, 25 Oct 2004 09:00:58 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM0in-000PT5-E6 for multi6@ops.ietf.org; Mon, 25 Oct 2004 09:00:57 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9P91HQx064743; Mon, 25 Oct 2004 11:01:18 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ADD566C-2664-11D9-81FA-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: New I-D Submitted (Re: Newbie Question about addressing impacts) Date: Mon, 25 Oct 2004 11:00:44 +0200 To: Arifumi Matsumoto X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-okt-04, at 8:47, Arifumi Matsumoto wrote: > As for the packet size issue, we are thinking of some devices. > - We've adopted prefix space compression in RA. Almost all the > prefixes in SAS Policy are expected to be less than 64-bit length, so > it is wasteful to allocate 128-bit space for each prefix field. > - We are also thinking of cutting down SAS Policy option, for example, > once a minute, once every two packets or only for router solicitation. > - In cooperation with DHCP, RA only specifies O flag and SAS Policy > information is delivered by DHCP. That's good, but what troubles me is that when you can have N policy expressions in a packet, what happens when there is a need for N+1 policy expressions? >> Why must the padding be ones? On many systems, newly allocated memory >> is filled with zeros, so this would be easier. And then there's >> tradition. :-) > This may look a bit tricky. > This is because 8-bit zero field means "::/0" in our specification. > But this is not essential, and can be changed by introducing "number of > prefix" field or something like that. If you just say in the draft "padding and end marker" this should clear everything up nicely in the draft. From owner-multi6@ops.ietf.org Mon Oct 25 05:02:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02542 for ; Mon, 25 Oct 2004 05:02:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM0iy-000PV7-Vz for multi6-data@psg.com; Mon, 25 Oct 2004 09:01:08 +0000 Received: from [32.97.182.106] (helo=e6.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM0ix-000PUk-Oh for multi6@ops.ietf.org; Mon, 25 Oct 2004 09:01:08 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9P90msZ286506; Mon, 25 Oct 2004 05:00:48 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9P90kgR130014; Mon, 25 Oct 2004 05:00:47 -0400 Received: from zurich.ibm.com (sig-9-146-221-79.de.ibm.com [9.146.221.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA37016; Mon, 25 Oct 2004 11:00:45 +0200 Message-ID: <417CC0C3.5080600@zurich.ibm.com> Date: Mon, 25 Oct 2004 11:00:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com CC: iljitsch@muada.com, multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <3CF661B1787ABF41A869BE20108F8D6D09582A@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D09582A@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Iljitsh, > > > >>Avoiding non-working paths goes to the core of what's multihoming all >>about, so this is something we absolutely need. But I'm not sure it's >>all we need. What I'm worried about is the situation where there are >>multiple working paths, but there is a large difference in quality >>between them. For instance, one path has a capacity of 100 Mbps and >>another a capacity of 1 Mbps. In this case, selecting the latter path >>as part of regular operation would hardly be acceptable. >> >>We _may_ be able to bring this problem back to manageable proportions >>by taking advantage of the information both ends have. So if either end >>knows that the second path is much slower, they'll avoid it as long as >>the first path is operational. This leaves only the cases where there >>is congestion in the core, which is pretty rare these days. (But this >>hasn't always been the case...) >> > > So, it seems like the problem might be moving into a general path selection > problem, which can be used for many things than just multihoming. I'm > not completely opposed to this, but want to warn that there are a lot of > details that will not be so simple. Perhaps we need to scope this problem > pretty well before going down this path. > > In terms of 'best' path, I can think of lots of factors - latency, bandwidth, > most active, least active, lowest cost and so on. Possibly selecting > a path based on the various combinations of the above for 2 endpoints > seems fairly challenging, so I'm not so optimistic that this is a solvable > problem in the short term. > > >>Note that the whole reachability detection problem isn't as simple as >>it may seem at first, especially when we want to make use of >>unidirectional paths. Until not very long ago, I was favoring a >>"cartesian ping bomb" approach where there are reachability probes for >>all { src, dst } combinations. However, this can cause massive >>congestion when a link fails for a busy site, and it's also complex and >>most likely slow. > > > Agreed. Even if you did this, then you would need some sort of mechanism > to evaluate the paths after determining reachability. I know some people > have discussed a next generation trace route that would collect statistics > about the hops along a particular path. Put that onto your "cartesian ping bomb" > and you might have a solution, but at what cost? It seems to me that this is one of those separable functional components we've been talking about, i.e. the one that triggers a multihoming event. In Version 1 that component would issue a trigger when connectivity vanishes for more than N seconds; in version 2 it might do so when QOS drops below some threshold for more than N seconds; in version 3 it might do so when observed QOS drops below presumed QOS for an alternative path for more than N seconds. The critical interface to be standardized isn't any of that; it's the "trigger multihoming now" protocol or API, IMHO. Brian From owner-multi6@ops.ietf.org Mon Oct 25 05:05:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02682 for ; Mon, 25 Oct 2004 05:05:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM0mo-0000E5-5e for multi6-data@psg.com; Mon, 25 Oct 2004 09:05:06 +0000 Received: from [32.97.182.104] (helo=e4.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM0mn-0000Do-4Q for multi6@ops.ietf.org; Mon, 25 Oct 2004 09:05:05 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9P94oCE240840; Mon, 25 Oct 2004 05:04:50 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9P94nZc143680; Mon, 25 Oct 2004 05:04:49 -0400 Received: from zurich.ibm.com (sig-9-146-221-79.de.ibm.com [9.146.221.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA42586; Mon, 25 Oct 2004 11:04:48 +0200 Message-ID: <417CC1B5.5060203@zurich.ibm.com> Date: Mon, 25 Oct 2004 11:04:53 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Nikander CC: Noel Chiappa , multi6@ops.ietf.org Subject: Re: [OT] Moving "path selection" to the end hosts (was Re: On the use of multiple PA prefixes ...) References: <20041022140941.894C4872D5@mercury.lcs.mit.edu> <6E4BDBA2-2596-11D9-919C-000D9331AFB0@nomadiclab.com> In-Reply-To: <6E4BDBA2-2596-11D9-919C-000D9331AFB0@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Noel, > > This starts to be off-topic for the multi6 list, but... It is a bit, but "choose the new source/dest address pair" is one of those separable components in any multi6 solution. As in my previous message, I think we should concentrate on the interfaces between those components, since one size probably doesn't fit all, and topology maps won't appear overnight. Brian > >> Well, basically, I think we need to move the "path selection" function >> out of the "network" (i.e. the routers), and let the hosts (or, if they >> are lazy/stupid, an agent acting on their behalf) do it. To do this, they >> obviously need more information, which I claim should be maps of network >> topology. >> >> ... >> >> Anyway, making this (admittedly major) architectural change kills about >> 17 dozen birds, of which the "how do I pick the best address for the >> destination" is one. > > > ... I'd like to hear what are some of these 17 dozen birds. > > I'm admittedly a layman in routing, but thinking about the amount > of routing information and its stability, it appears to me that it > will anyway be necessary to provide aggregated versions of this > information at various levels. Hence, it sounds reasonable to > assume that a host could have some better knowledge about the network > topology (and perhaps congestion state) "close" to it, but less > information, or more aggregated information, about what happens > further away. Hence, any path selection performed by the end hosts > will be, at best, an approximation. > > I could imagine that two (or a group of) communicating hosts could > jointly be able to make a fairly good approximation of the routing > state close to them, and thereby make a good selection about which > local paths to use among the available ones. Combining this information > with upper layer RTT and bandwidth estimates, the hosts might be > able to create some kind of a local model about the traffic > characteristics of the paths, but only over time. In the case of > site multi-homing, sharing this information with other hosts on the > site may make sense, just as a number of people have pointed out. > > Based on this straw man analysis, I get the feeling that moving > path selection to the end hosts might be good because > > - the end hosts may use information from their peers to make > better selections, and > > - the end hosts may more easily use dynamic upper layer > congestion information to revise their choices on need > > On the other hand, either network assistance or letting the network > to do the selection looks good because > > - the network may learn more from a number of end-hosts, > thereby being able to create a more accurate model of > the network condition > > - the network needs to have this topology information anyway, > as we cannot expect the hosts to learn the topology without > some help from the routers > > The situation seems to be become more interesting if we assume that > there is a full blown id/loc split in place. That would allow > the network to have more dynamic IP addresses, slowly changing the > addresses to better match the actual network topology. Under such > conditions, it becomes an interesting exercise to figure out how > to represent the actual topology, as IP addresses cannot be directly > used to represent nodes, and identifiers are unlikely to be > directly aggregatable. > > Anyway, I fail to clearly see the consequences of such a change, > i.e. moving "path selection" to end hosts, and would like to hear > more about your insights. > > --Pekka Nikander > > From owner-multi6@ops.ietf.org Mon Oct 25 07:16:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14490 for ; Mon, 25 Oct 2004 07:16:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM2oN-000JQ9-5N for multi6-data@psg.com; Mon, 25 Oct 2004 11:14:51 +0000 Received: from [192.68.245.115] (helo=mail.nttv6.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM2oL-000JPu-Ry for multi6@ops.ietf.org; Mon, 25 Oct 2004 11:14:50 +0000 Received: from [10.0.22.187] ([192.16.178.225]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id i9PBCUia004588; Mon, 25 Oct 2004 20:12:30 +0900 (JST) In-Reply-To: <5ADD566C-2664-11D9-81FA-000A95CD987A@muada.com> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> <5ADD566C-2664-11D9-81FA-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C0AE399-2677-11D9-834A-000A95D3E0E2@arifumi.net> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Arifumi Matsumoto Subject: Re: New I-D Submitted (Re: Newbie Question about addressing impacts) Date: Mon, 25 Oct 2004 20:15:26 +0900 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, On 2004/10/25, at 18:00, Iljitsch van Beijnum wrote: > On 25-okt-04, at 8:47, Arifumi Matsumoto wrote: > >> As for the packet size issue, we are thinking of some devices. >> - We've adopted prefix space compression in RA. Almost all the >> prefixes in SAS Policy are expected to be less than 64-bit length, so >> it is wasteful to allocate 128-bit space for each prefix field. >> - We are also thinking of cutting down SAS Policy option, for >> example, once a minute, once every two packets or only for router >> solicitation. >> - In cooperation with DHCP, RA only specifies O flag and SAS Policy >> information is delivered by DHCP. > > That's good, but what troubles me is that when you can have N policy > expressions in a packet, what happens when there is a need for N+1 > policy expressions? First of all, please note that one RA packet can contain as much as 132 prefixes when all the SAS Policies are /64, or 184 prefixes for /48. In general use, it seems to be almost improbable to fill this space with valid source address selection policies. In such a case, IMHO, these measures can be taken: - As I mentioned in the previous e-mail, it is an alternative to fall back to DHCP by using O flag in RA message. DHCP is a UDP protocol, so it can be fragmented as specified in RFC 3315. - The other alternative is to prune some of SAS Policies to fit in one RA packet. There can exist end nodes with no DHCP capability. For those nodes, it is often better to have part of SAS Policy Info. than to have nothing. So, it might be a reasonable approach to make both O flag and pruned SAS Policy info. included in one RA packet. At least, this should be configurable by router administrators. As for pruning, some algorithms can be possible. Based on my intuition, it seems to be better to prune policies with shorter prefix length, as shorter prefix length policies has less priority and can be overridden by longer ones in RFC 3484 Policy Table >> This may look a bit tricky. >> This is because 8-bit zero field means "::/0" in our specification. >> But this is not essential, and can be changed by introducing "number >> of >> prefix" field or something like that. > > If you just say in the draft "padding and end marker" this should > clear everything up nicely in the draft. Thank you for your advice. I'll use that wording in my update draft. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From owner-multi6@ops.ietf.org Mon Oct 25 08:37:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21199 for ; Mon, 25 Oct 2004 08:37:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM448-0005i2-4l for multi6-data@psg.com; Mon, 25 Oct 2004 12:35:12 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM447-0005hf-1s for multi6@ops.ietf.org; Mon, 25 Oct 2004 12:35:11 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PCZ6l15385; Mon, 25 Oct 2004 15:35:07 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 15:31:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9PCV6L4006529; Mon, 25 Oct 2004 15:31:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004ZnZXo; Mon, 25 Oct 2004 15:31:04 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PCV3a04551; Mon, 25 Oct 2004 15:31:03 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 15:30:22 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 15:30:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Mon, 25 Oct 2004 15:30:21 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> Thread-Topic: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Thread-Index: AcS6cfH4xzWphkurSYGX54jab644LQAHDd9A From: To: Cc: , X-OriginalArrivalTime: 25 Oct 2004 12:30:22.0049 (UTC) FILETIME=[6546FD10:01C4BA8E] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, > > Agreed. Even if you did this, then you would need some sort of = mechanism > > to evaluate the paths after determining reachability. I know some = people > > have discussed a next generation trace route that would collect = statistics > > about the hops along a particular path. Put that onto your = "cartesian ping bomb" > > and you might have a solution, but at what cost? >=20 > It seems to me that this is one of those separable functional > components we've been talking about, i.e. the one that triggers > a multihoming event. In Version 1 that component would issue a > trigger when connectivity vanishes for more than N seconds; in > version 2 it might do so when QOS drops below some threshold for > more than N seconds; in version 3 it might do so when observed > QOS drops below presumed QOS for an alternative path for more > than N seconds. The critical interface to be standardized isn't > any of that; it's the "trigger multihoming now" protocol or API, > IMHO. So, multihoming triggering mechanisms are out of scope for Multi6, except for link failure ... I would agree that the API should be out of scope. thanks, John From owner-multi6@ops.ietf.org Mon Oct 25 09:19:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24395 for ; Mon, 25 Oct 2004 09:19:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM4kg-000Cow-Pt for multi6-data@psg.com; Mon, 25 Oct 2004 13:19:10 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM4kf-000CoZ-II for multi6@ops.ietf.org; Mon, 25 Oct 2004 13:19:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9PDJXQx067636; Mon, 25 Oct 2004 15:19:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7018B73E-2688-11D9-81FA-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Mon, 25 Oct 2004 15:19:02 +0200 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-okt-04, at 14:30, wrote: > So, multihoming triggering mechanisms are out of scope for Multi6, > except for link failure ... I would agree that the API should be > out of scope. I agree that an API for this is something for a later day. However, we do need to create a reachability measuring mechanism that is flexible enough that it can be made smarter at some time in the future while maintaining backward compatibility, as having several of these mechanisms is a huge waste and deploying new ones will be hard because both ends must support it before it can do anything useful. From owner-multi6@ops.ietf.org Mon Oct 25 09:47:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26231 for ; Mon, 25 Oct 2004 09:47:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM5Av-000G6J-Qi for multi6-data@psg.com; Mon, 25 Oct 2004 13:46:17 +0000 Received: from [32.97.110.132] (helo=e34.co.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM5Ar-000G5j-Of for multi6@ops.ietf.org; Mon, 25 Oct 2004 13:46:14 +0000 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PDkCJ8529382 for ; Mon, 25 Oct 2004 09:46:12 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PDkAjU114846 for ; Mon, 25 Oct 2004 07:46:11 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PDkABZ007198 for ; Mon, 25 Oct 2004 07:46:10 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PDk8rt006755; Mon, 25 Oct 2004 07:46:09 -0600 Received: from zurich.ibm.com (sig-9-146-221-79.de.ibm.com [9.146.221.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA41762; Mon, 25 Oct 2004 15:46:02 +0200 Message-ID: <417D039E.8050408@zurich.ibm.com> Date: Mon, 25 Oct 2004 15:46:06 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com CC: iljitsch@muada.com, multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Brian, > > >>>Agreed. Even if you did this, then you would need some sort of mechanism >>>to evaluate the paths after determining reachability. I know some people >>>have discussed a next generation trace route that would collect statistics >>>about the hops along a particular path. Put that onto your "cartesian ping bomb" >>>and you might have a solution, but at what cost? >> >>It seems to me that this is one of those separable functional >>components we've been talking about, i.e. the one that triggers >>a multihoming event. In Version 1 that component would issue a >>trigger when connectivity vanishes for more than N seconds; in >>version 2 it might do so when QOS drops below some threshold for >>more than N seconds; in version 3 it might do so when observed >>QOS drops below presumed QOS for an alternative path for more >>than N seconds. The critical interface to be standardized isn't >>any of that; it's the "trigger multihoming now" protocol or API, >>IMHO. > > > So, multihoming triggering mechanisms are out of scope for Multi6, > except for link failure ... I would agree that the API should be > out of scope. I didn't say it's out of scope, I said it's separable. Actually, after we review the design team's output in the upcoming meeting, there will need to be a charter discussion to find out what is in scope for which WGs*. I'm trying to keep my mind unbiased on that question for the moment. *Our charter ends with these words: Development of specific solutions will require chartering of work in the appropriate Area or Areas. Brian From owner-multi6@ops.ietf.org Mon Oct 25 16:09:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00773 for ; Mon, 25 Oct 2004 16:09:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMB8n-000MTT-Lq for multi6-data@psg.com; Mon, 25 Oct 2004 20:08:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMB8m-000MSc-H8 for multi6@ops.ietf.org; Mon, 25 Oct 2004 20:08:28 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00467; Mon, 25 Oct 2004 16:08:21 -0400 (EDT) Message-Id: <200410252008.QAA00467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-architecture-02.txt Date: Mon, 25 Oct 2004 16:08:21 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Architectural Approaches to Multi-Homing for IPv6 Author(s) : G. Huston Filename : draft-ietf-multi6-architecture-02.txt Pages : 36 Date : 2004-10-25 This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-architecture-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-architecture-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-architecture-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-architecture-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Oct 25 17:37:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16356 for ; Mon, 25 Oct 2004 17:37:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMCUu-0008GX-HL for multi6-data@psg.com; Mon, 25 Oct 2004 21:35:24 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMCUt-0008GB-Au for multi6@ops.ietf.org; Mon, 25 Oct 2004 21:35:23 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2E2C82F787; Mon, 25 Oct 2004 23:35:24 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id 2D8872F791; Mon, 25 Oct 2004 23:35:23 +0200 (CEST) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D1FFDFB@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D1FFDFB@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <72E29F08-26CC-11D9-AB06-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: , From: marcelo bagnulo braun Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Date: Mon, 25 Oct 2004 23:25:52 +0200 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 25/10/2004, a las 6:18, escribi=F3: > Marcelo, > >>> My minor substantive comments are below. >>> Some editorial comments were sent direct to the author. >>> >>>> 4.2 Multi-Homing: Mobility >>> ... >>>> The aspect of MIPv6 which appears to present issues in the=20 >>>> context of >>>> multi-homing is the return routeability mechanism. In MIPv6=20 >>>> identity >>>> validity is periodically tested by return routeability of the >>>> identity address. This regular use of a distinguished locator=20= >>>> as the >>>> identity token cannot support return reachability in the=20 >>>> multi-homing >>>> context in the event of extended path failure of the path that = is >>>> associated with the identity locator. >>> >>> This question isn't really relevant to multi6, >> >> Well, lots of people claim that there is a close relation between >> multihoming and mobility, since both problmes require changing the >> locators and keep the identifier. >> Since there is an available solution for mobility, it seems quite >> natural to explore if such solution is suitable for multihoming. >> The problem with the available solution for mobility is that the >> security mechanism used in mip is inherently incompatible with the >> multihoming requirements, since it is based on reaching the >> identifier. >> >> so imho it is relevant to multihoming the explanation why the = approach >> used for mobility is not suitable for multihoming. > > I agree with Marcelo, but with the caveat that solving mobility=20 > problems > is not a goal of Multi6. Learning from mobility solutions is a good=20 > thing, > though. > agree regards, marcelo > John > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Mon Oct 25 18:25:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00635 for ; Mon, 25 Oct 2004 18:25:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMDHA-000FIA-Kw for multi6-data@psg.com; Mon, 25 Oct 2004 22:25:16 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMDH9-000FHu-Dk for multi6@ops.ietf.org; Mon, 25 Oct 2004 22:25:15 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9C22D2F6F2; Tue, 26 Oct 2004 00:25:16 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id 709962F852; Tue, 26 Oct 2004 00:25:15 +0200 (CEST) In-Reply-To: <417D039E.8050408@zurich.ibm.com> References: <3CF661B1787ABF41A869BE20108F8D6D431E03@esebe056.ntc.nokia.com> <417D039E.8050408@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, iljitsch@muada.com, john.loughney@nokia.com From: marcelo bagnulo braun Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming Date: Tue, 26 Oct 2004 00:25:26 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 25/10/2004, a las 15:46, Brian E Carpenter escribi=F3: > john.loughney@nokia.com wrote: >> Brian, >>>> Agreed. Even if you did this, then you would need some sort of=20 >>>> mechanism >>>> to evaluate the paths after determining reachability. I know some=20= >>>> people >>>> have discussed a next generation trace route that would collect=20 >>>> statistics >>>> about the hops along a particular path. Put that onto your=20 >>>> "cartesian ping bomb" >>>> and you might have a solution, but at what cost? >>> >>> It seems to me that this is one of those separable functional >>> components we've been talking about, i.e. the one that triggers >>> a multihoming event. In Version 1 that component would issue a >>> trigger when connectivity vanishes for more than N seconds; in >>> version 2 it might do so when QOS drops below some threshold for >>> more than N seconds; in version 3 it might do so when observed >>> QOS drops below presumed QOS for an alternative path for more >>> than N seconds. The critical interface to be standardized isn't >>> any of that; it's the "trigger multihoming now" protocol or API, >>> IMHO. >> So, multihoming triggering mechanisms are out of scope for Multi6, >> except for link failure ... I would agree that the API should be >> out of scope. > > I didn't say it's out of scope, I said it's separable. Yes, this is very important in the desing of the solution. I guess that we should really try to design the solution in such a way=20= that the different components/mechanisms that build the solution can=20 evolve as independently as possible. A good excersive would be to identify which are those components that=20 we will design to be able to independetly evolve. It seems that the mechanisms used to trigger a re-homing is one of them. Security mechanisms could be other one mechanisms to deal with ingress filtering perhaps another one. But we should try to make a full list since if we don't do this=20 separation from scratch, it is very unlikely that we will be able to=20 achieve this modular evolution later. Regards, marcelo > Actually, > after we review the design team's output in the upcoming meeting, > there will need to be a charter discussion to find out what is > in scope for which WGs*. I'm trying to keep my mind unbiased on > that question for the moment. > > *Our charter ends with these words: > > Development of specific solutions will require chartering of work > in the appropriate Area or Areas. > > Brian > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Tue Oct 26 03:48:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07336 for ; Tue, 26 Oct 2004 03:48:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMM2c-0003R3-4z for multi6-data@psg.com; Tue, 26 Oct 2004 07:46:50 +0000 Received: from [32.97.182.102] (helo=e2.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMM2b-0003Qp-8D for multi6@ops.ietf.org; Tue, 26 Oct 2004 07:46:49 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9Q7kmBF062490 for ; Tue, 26 Oct 2004 03:46:48 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9Q7kkUp274796 for ; Tue, 26 Oct 2004 03:46:47 -0400 Received: from zurich.ibm.com (sig-9-145-248-112.de.ibm.com [9.145.248.112]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA64000 for ; Tue, 26 Oct 2004 09:46:43 +0200 Message-ID: <417E00E9.7050207@zurich.ibm.com> Date: Tue, 26 Oct 2004 09:46:49 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Updated Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-02.txt References: <4176E2F5.10008@zurich.ibm.com> In-Reply-To: <4176E2F5.10008@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since draft-ietf-multi6-architecture-02.txt has just been published, the WG Last Call now applies to this draft. Since the differences are small (see the second page of the draft), the comment deadline is still November 3. Brian multi6 WG co-chair Brian E Carpenter wrote: > It is proposed to forward > draft-ietf-multi6-architecture-01.txt > to the IESG for approval as an Informational RFC > > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. > > Thanks > > Brian Carpenter > multi6 WG co-chair > > > > > From owner-multi6@ops.ietf.org Tue Oct 26 04:44:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11567 for ; Tue, 26 Oct 2004 04:44:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMMvW-000ECm-3l for multi6-data@psg.com; Tue, 26 Oct 2004 08:43:34 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMMvU-000ECX-OM for multi6@ops.ietf.org; Tue, 26 Oct 2004 08:43:33 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D6F618987C; Tue, 26 Oct 2004 11:43:31 +0300 (EEST) Message-ID: <417E0DCF.7040807@piuha.net> Date: Tue, 26 Oct 2004 11:41:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: multi6@ops.ietf.org Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming References: <3CF661B1787ABF41A869BE20108F8D6D09582C@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D09582C@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > might be more stable. I think you also want to avoid ping-ponging > between the interfaces as well, so being prudent here is an > important issue. Right. So that's why the approach taken in my draft is "failover only". I'm just pointing out its limitations in terms of user observable behavior. But just because I point out a limitation doesn't necessarily mean that I'm suggesting we go and fix it, because the solution might not be available or would be complex. >>Yes. In http://www.arkko.com/publications/multi6/faildet.html#anchor9 >>we did the math, and with the quite reasonable assumption of exponential >>back-off, testing all combinations of addresses with just four addresses >>on each side would last 3200 seconds. > > So, I should read your draft (on my reading pile) but are there simplifying > assumptions? If we look at site multihoming, we might not need to test > all addresses. For example, in a VPN case, there might only be a handful > of VPN gateways. Instead of testing all of the destination addresses, > we might need just to test the different VPN gateways. Additional > constraints are probably possible based upon site configuration. I agree, but I was thinking about this one layer lower down. If you have VPN gateways or something else, you still have a set of addresses at both ends. I guess what I'm saying is that there are some fundamental-looking limits to what we can achieve. Basically, 2-3 addresses at both ends seems to be the practical limit; anything beyond that isn't easily explorable. (And then an advertisement from your MOBIKE co-chair: I suspect the VPN example is not very good one for MULTi6 because MOBIKE protocols will do that pretty well -- including support for NATs in between and mixed IPv4/IPv6.) > You might want to consult ICE: > > Interactive Connectivity Establishment (ICE): A Methodology for > Network Address Translator (NAT) Traversal for Multimedia Session > Establishment Protocols Thanks for the pointer. I'm aware of STUN and ICE but need to study them in more detail... >>Do you mean the "I am in a hurry, screw the others if this >>causes congestion" -flag? ;-) >> >>I fear that the things that we want to do would really require >>better good knowledge of the current RTTs of the paths. This >>can be measured, but there's a tradeoff in how far we want >>to venture in the territory of TCP vs. how good our information >>is. > > > Agreed. I think if we go down this route, it would be very important > to engage TSVWG types into the discussion. TCP has a very conservative > approach to this. TCP Quick Start is an interesting algorithm that > might be applicable here: > > http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt Thanks for this pointer too! > Finally, a big issue is also L2 Indications. I think that we might > be able to assist any multihoming if we consider L2 indicators. Lots > of work has been done in the transport area about l2 indicators. A > good summary can be found here: > > http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt Yes. My failure detection draft has a couple of abstractions that deal with "lower layer" (under MULTI6) issues, such as - availability of an address (RA/DAD/DHCP all done) - operational status of an address (router NUD, L2 info etc) But there isn't a lot of details about link layer indications beyond this. I guess one of the decisions that affects this is whether we deal with on/off type of information or we want to take bandwidth and issues into account too. --Jari From owner-multi6@ops.ietf.org Wed Oct 27 13:51:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26965 for ; Wed, 27 Oct 2004 13:51:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMrw0-000Osx-GG for multi6-data@psg.com; Wed, 27 Oct 2004 17:50:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMrvz-000Os9-8s for multi6@ops.ietf.org; Wed, 27 Oct 2004 17:50:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RHnxG22084; Wed, 27 Oct 2004 20:50:04 +0300 Date: Wed, 27 Oct 2004 20:49:59 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Multi6 Subject: Re: Multi6 WG Last Call (3 of 3) draft-ietf-multi6-v4-multihoming-02.txt In-Reply-To: <4176E3F6.9090503@zurich.ibm.com> Message-ID: References: <4176E3F6.9090503@zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 21 Oct 2004, Brian E Carpenter wrote: > It is proposed to forward > draft-ietf-multi6-v4-multihoming-02.txt > to the IESG for approval as an Informational RFC > > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. While I think the document could still be further improved, it seems that the document should be good enough right now, and is ready for publication. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Oct 28 02:26:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09463 for ; Thu, 28 Oct 2004 02:26:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN3hW-0004rK-NJ for multi6-data@psg.com; Thu, 28 Oct 2004 06:23:58 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN3hV-0004r4-Lp for multi6@ops.ietf.org; Thu, 28 Oct 2004 06:23:57 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9S6NuGH060642 for ; Thu, 28 Oct 2004 06:23:56 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9S6NtXc150812 for ; Thu, 28 Oct 2004 07:23:56 +0100 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA63856 for ; Thu, 28 Oct 2004 08:23:55 +0200 Message-ID: <4180907A.9070800@zurich.ibm.com> Date: Thu, 28 Oct 2004 08:23:54 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: For your travel planning References: <415C2465.8050408@zurich.ibm.com> In-Reply-To: <415C2465.8050408@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please note that the latest draft IETF agenda shows multi6 meeting on MONDAY morning (instead of Tuesday) and on Wednesday afternoon. Also note that most of the agenda of the two sessions will be devoted to the design team documents: Multihoming L3 Shim Approach draft-nordmark-multi6dt-shim-00.txt Hash Based Addresses (HBA) draft-bagnulo-multi6dt-hba-00 Functional decomposition of the M6 protocol draft-bagnulo-multi6dt-functional-dec-00 Failure Detection and Locator Selection in Multi6 draft-arkko-multi6dt-failure-detection-00 Multi6 Application Referral Issues draft-nordmark-multi6dt-refer-00.txt The draft agenda will be coming soon... Brian co-chair Brian E Carpenter wrote: > Multi6 people, > > FYI we are expecting some drafts from the multi6 design team > in the coming weeks. As a result we have scheduled two > sessions at the November IETF, provisionally on Tuesday > November 9 and Wednesday November 10. > > The IETF agenda is not final, so these may change. The latest > version is always at: > > http://www.ietf.org/meetings/agenda_61.html > > Brian > From owner-multi6@ops.ietf.org Thu Oct 28 05:28:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23175 for ; Thu, 28 Oct 2004 05:28:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN6Yg-000PCu-ER for multi6-data@psg.com; Thu, 28 Oct 2004 09:27:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN6Ye-000PCd-Oy for multi6@ops.ietf.org; Thu, 28 Oct 2004 09:27:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9S9Qwj08148; Thu, 28 Oct 2004 12:26:58 +0300 Date: Thu, 28 Oct 2004 12:26:58 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt In-Reply-To: <4176E3B7.4090806@zurich.ibm.com> Message-ID: References: <4176E3B7.4090806@zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 21 Oct 2004, Brian E Carpenter wrote: > It is proposed to forward > draft-ietf-multi6-things-to-think-about-00.txt > to the IESG for approval as an Informational RFC > > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. I don't think this is quite ready yet. Comments below. ==> a couple of 'things to think about' have been lost in the revision. Has this been intentional? At least: 2.3.3 Can your solution be aggregated and implemented site-wide? 2.3.4 Does your solution impact existing traffic engineering methods I think these are rather important, even thought the latter is focused on MPLS, when it should be focusing on BGP traffic engineering practices instead. 2. On the wire behavior 2.1 How will your solution solve the multihoming problem? That's why we're here. Remember, a reference is fine. ==> this seems almost like asking, in an email context, 'how does your proposal solve the spam problem?'. This question is not good, because I don't think we have sufficiently clearly defined what "the multihoming problem" really is (and some might even argue it's multiple different problems), and its unlikely that the solutions can even solve the whole problem. This will cause folks to answer, "the solution provides connection survivability, solving the multihoming problem" .. BUT THAT'S NOT THE (WHOLE OF) MULTIHOMING PROBLEM! It's difficult to say how this should be fixed. One way might be trying to precisely define what 'the multihoming problem' refers to. One way would be rewording the question so that the responder should try to describe which multihoming problem(s) the responder thinks what the solution is solving, and which not. Reference to a list of multihoming problems would also be OK, but I don't think there is a good document laying these out. 2.7 Can multihoming capabilities be negotiated end to end during a connection? If the proposal introduces additional overhead, can the information be somehow piggybacked on messages that are already used? This would be useful in order to keep connection setup constant. Please also indicate any drawbacks that might apply due to this piggybacking. ==> I already proposed the following new section in March: === 2.X Can multihoming setup be delayed from session setup? If the proposal induces overhead (added bytes in packets, or additional packets), is it possible to delay that overhead (or "multihoming set-up") to happen after the session has been established? That is, is it possible to specify that multihoming benefits would only be achieved for sessions which last over XX seconds, to optimize away the cost of set-up for short-lived sessions? === Whether that should be a section of its own, or a couple of questions merged e.g., in 2.7 is your call. 3.4 How is the binding updated? Will transport connections remain up when new paths become available or when old ones become unavailable? How does the end node discover these events? ==> You should probably also ask: How long does it take to notice new paths? How long does it take to notice paths which are already used which have become unavailable? ... 3.12 Are there any implications for scoped addressing? Please see RFC 3513 [1]. How does your mechanism interact with multicast? ==> what does 'multicast' have to do under 'scoped addressing'. Granted, multicast addresses have a concept of scope, but maybe this calls for an additional question, 'Are there any implications for multicast', where multicast would include both global and non-globally scoped mcast. 4.3 Are there any changes to ICMP error semantics? Do you create new codes? If so, why and what do they mean? Will a host that is not aware of your scheme see them? ==> add 'What would happen if such ICMP messages would end up being filtered e.g. in a firewall?'.. 5. Name service interactions ==> you discuss DNS in this section, but AFAICS, these issues could be generic if some other mapping function than DNS would be used. Maybe this issue could be handled by adding something like: This section assumes that DNS might be used for a mapping function. If you are using some other method (see Section 3.8), please consider separately both the impact on DNS, and the impact on your mapping function as appropriate. editorial --------- This document contains several set of questions that attempt to focus ==> plural/singular It is the hope of the author perhaps others that the authors of the proposed solutions will use this document to identify gaps in their solutions, and cooperate to close those gaps. ==> something missing here If so, how are rendezvous handled? Can your solution handle both ==> plural/singular it? If not, how will your solution interact with MOBILEIP-V6 [3] ==> that's an interesting way to write it:) try 'Mobile IPv6' While Ipv6 has a simplified approach to layer 2, perhaps you unsimplified it. If so, please provide details. ==> s/layer 2/the link layer/ How does your solution interact with link-local addressing ==> add '?' at the end? How does your solution interact with Son-Of-Sitelocal (whatever that will be)? ==> just reference ULAs ? If a link fails or a service is dropped, how will it impact DNS? Again are there any dependency loops? Perhaps diagram out your dependencies to make sure. ==> is 'diagram out' a verb? Referrals exist within various other protocols, such as so-called "peer to peer" applications. Note that referrals might suffer three types of failure: firewall and NAT - just as FTP active mode experiences today with relatively simple firewalls? time-based - is there something ephemeral about the nature of the solution that might cause a referral (such as a URL) to fail over time, more so than what we have today? location-based - if the binding varies based on where the parties are in the network, if one moves will they no longer be able to find one another? ==> some numbers, bullets, etc. for these 3 would be nice [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. ==> rfc 3775 now [4] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming solutions", draft-nordmark-multi6-threats-00 (work in progress), October 2003. ==> draft-ietf-multi6-multihoming-threats now -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Oct 28 05:50:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24786 for ; Thu, 28 Oct 2004 05:50:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN6uw-0001L4-DU for multi6-data@psg.com; Thu, 28 Oct 2004 09:50:02 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN6uu-0001Jo-Tk for multi6@ops.ietf.org; Thu, 28 Oct 2004 09:50:01 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i9S9oSQx015351; Thu, 28 Oct 2004 11:50:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4180907A.9070800@zurich.ibm.com> References: <415C2465.8050408@zurich.ibm.com> <4180907A.9070800@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: For your travel planning Date: Thu, 28 Oct 2004 11:49:58 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-okt-04, at 8:23, Brian E Carpenter wrote: > Please note that the latest draft IETF agenda shows multi6 meeting > on MONDAY morning (instead of Tuesday) This is not good, as it overlaps with the open apps area session. > Multi6 Application Referral Issues > draft-nordmark-multi6dt-refer-00.txt From owner-multi6@ops.ietf.org Thu Oct 28 07:42:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03493 for ; Thu, 28 Oct 2004 07:42:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN8eY-000DFb-SS for multi6-data@psg.com; Thu, 28 Oct 2004 11:41:14 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN8eX-000DEM-LY for multi6@ops.ietf.org; Thu, 28 Oct 2004 11:41:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 149EF62482C; Thu, 28 Oct 2004 13:41:19 +0200 (CEST) In-Reply-To: References: <4176E3B7.4090806@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <40B42849-28D6-11D9-BEFF-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Date: Thu, 28 Oct 2004 13:41:05 +0200 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka, On 2004-10-28, at 11.26, Pekka Savola wrote: > 2.1 How will your solution solve the multihoming problem? > > That's why we're here. Remember, a reference is fine. > > ==> this seems almost like asking, in an email context, 'how does your > proposal solve the spam problem?'. This question is not good, because > I don't think we have sufficiently clearly defined what "the > multihoming problem" really is (and some might even argue it's > multiple different problems), and its unlikely that the solutions can > even solve the whole problem. > > This will cause folks to answer, "the solution provides connection > survivability, solving the multihoming problem" .. BUT THAT'S NOT > THE (WHOLE OF) MULTIHOMING PROBLEM! > > It's difficult to say how this should be fixed. One way might be > trying to > precisely define what 'the multihoming problem' refers to. One way > would be > rewording the question so that the responder should try to describe > which > multihoming problem(s) the responder thinks what the solution is > solving, > and which not. Reference to a list of multihoming problems would also > be > OK, but I don't think there is a good document laying these out. I agree with you to some extent, but I read the question being "describe the problems you are trying to solve". Which I think is closer to your point. > ==> I already proposed the following new section in March: > > === > 2.X Can multihoming setup be delayed from session setup? > > If the proposal induces overhead (added bytes in packets, or > additional packets), is it possible to delay that overhead (or > "multihoming set-up") to happen after the session has been > established? > > That is, is it possible to specify that multihoming benefits would > only be achieved for sessions which last over XX seconds, to optimize > away the cost of set-up for short-lived sessions? > === > > Whether that should be a section of its own, or a couple of questions > merged > e.g., in 2.7 is your call. I think that might actually be worth a question on it's own. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYDa2KarNKXTPFCVEQJCNQCggi4P+XV7Ju/uuCVNRTdQxmy3EE8AnAnr PvCmX+oHDRg2XrR0URFwVhhV =DAzg -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Oct 28 07:53:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04483 for ; Thu, 28 Oct 2004 07:53:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN8qD-000Ehi-SI for multi6-data@psg.com; Thu, 28 Oct 2004 11:53:17 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN8qC-000EhJ-QC for multi6@ops.ietf.org; Thu, 28 Oct 2004 11:53:17 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9SBr8Dq092926; Thu, 28 Oct 2004 11:53:08 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9SBr7LQ146358; Thu, 28 Oct 2004 12:53:08 +0100 Received: from zurich.ibm.com (sig-9-146-220-104.de.ibm.com [9.146.220.104]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA73018; Thu, 28 Oct 2004 13:53:06 +0200 Message-ID: <4180DDA7.6080201@zurich.ibm.com> Date: Thu, 28 Oct 2004 13:53:11 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: For your travel planning References: <415C2465.8050408@zurich.ibm.com> <4180907A.9070800@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 28-okt-04, at 8:23, Brian E Carpenter wrote: > >> Please note that the latest draft IETF agenda shows multi6 meeting >> on MONDAY morning (instead of Tuesday) > > > This is not good, as it overlaps with the open apps area session. > >> Multi6 Application Referral Issues >> draft-nordmark-multi6dt-refer-00.txt Correct. We have asked to be moved back to Tuesday morning, and we will see what they answer... Brian From owner-multi6@ops.ietf.org Thu Oct 28 08:09:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05821 for ; Thu, 28 Oct 2004 08:09:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN95g-000HJq-I0 for multi6-data@psg.com; Thu, 28 Oct 2004 12:09:16 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN95f-000HJQ-EK for multi6@ops.ietf.org; Thu, 28 Oct 2004 12:09:15 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 05:20:49 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9SC9C6s009630; Thu, 28 Oct 2004 05:09:12 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4186.cisco.com [10.61.80.89]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9SCAgRx005747; Thu, 28 Oct 2004 05:10:43 -0700 Message-ID: <4180E165.4020706@cisco.com> Date: Thu, 28 Oct 2004 14:09:09 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041027) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Brian E Carpenter , Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt References: <4176E3B7.4090806@zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098965444.940596"; x:"432200"; a:"rsa-sha1"; b:"nofws:5543"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"rx/uAFxsTRy2pZhLtD8z5QiHZ+32GxXbcLkrWpnemeB6ijeppxSA8cmfKyHsE" "XNgSIj4m0qkcFV4ztJWjHZfOkK7qUpzvz941MDNqoq6l70hEQm2i0jWigAKb5" "4BNb62tTGx0DQjqNViqLcVWTmG59Qhg9ViDK30mrjO2UUGmcs="; c:"Date: Thu, 28 Oct 2004 14:09:09 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to" "-think-about-00.txt" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, > 2.3.3 Can your solution be aggregated and implemented site-wide? This is now in Section 4.1: does your solution change existing aggregation methods? > 2.3.4 Does your solution impact existing traffic engineering methods > > I think these are rather important, even thought the latter is focused on > MPLS, when it should be focusing on BGP traffic engineering practices > instead. We had this in there and nobody could understand how a solution could impact traffic engineering methods, other than by changing the aggregation methods. Thus Section 4.1. > > 2. On the wire behavior > > 2.1 How will your solution solve the multihoming problem? > > That's why we're here. Remember, a reference is fine. > > ==> this seems almost like asking, in an email context, 'how does your > proposal solve the spam problem?'. This question is not good, because I > don't think we have sufficiently clearly defined what "the multihoming > problem" really is (and some might even argue it's multiple different > problems), and its unlikely that the solutions can even solve the whole > problem. > > This will cause folks to answer, "the solution provides connection > survivability, solving the multihoming problem" .. BUT THAT'S NOT > THE (WHOLE OF) MULTIHOMING PROBLEM! > > It's difficult to say how this should be fixed. One way might be trying to > precisely define what 'the multihoming problem' refers to. One way > would be > rewording the question so that the responder should try to describe which > multihoming problem(s) the responder thinks what the solution is solving, > and which not. Reference to a list of multihoming problems would also be > OK, but I don't think there is a good document laying these out. What I am looking for, and perhaps a clarification *is* in order, is a scoping of what problem they think they're trying to solve. This document doesn't require you to solve every problem, but simply to explain how your solution to the problem you think you're solving will impact the world we live in now. > > > 2.7 Can multihoming capabilities be negotiated end to end during a > connection? > > If the proposal introduces additional overhead, can the information > be somehow piggybacked on messages that are already used? This would > be useful in order to keep connection setup constant. Please also > indicate any drawbacks that might apply due to this piggybacking. > > ==> I already proposed the following new section in March: > > === > 2.X Can multihoming setup be delayed from session setup? > > If the proposal induces overhead (added bytes in packets, or > additional packets), is it possible to delay that overhead (or > "multihoming set-up") to happen after the session has been > established? This is included above based on your earlier feedback. > > That is, is it possible to specify that multihoming benefits would > only be achieved for sessions which last over XX seconds, to optimize > away the cost of set-up for short-lived sessions? And this may be too specific to a mechanism you have in mind. For instance, perhaps this would be handled by an IP end host option. > === > > Whether that should be a section of its own, or a couple of questions > merged > e.g., in 2.7 is your call. > > 3.4 How is the binding updated? > > Will transport connections remain up when new paths become available > or when old ones become unavailable? How does the end node discover > these events? > > ==> You should probably also ask: > > How long does it take to notice new paths? How long does it take to > notice paths which are already used which have become unavailable? That's a good question. > > ... > > 3.12 Are there any implications for scoped addressing? > > Please see RFC 3513 [1]. How does your mechanism interact with > multicast? > > ==> what does 'multicast' have to do under 'scoped addressing'. Granted, > multicast addresses have a concept of scope, but maybe this calls for an > additional question, 'Are there any implications for multicast', where > multicast would include both global and non-globally scoped mcast. The question is right there. I attempted to borrow from IPv6 nomenclature. If you believe that nomenclature is failing us here, then we should change it, but we should do so elsewhere as well. > > 4.3 Are there any changes to ICMP error semantics? > > Do you create new codes? If so, why and what do they mean? Will a > host that is not aware of your scheme see them? > > ==> add 'What would happen if such ICMP messages would end up being > filtered > e.g. in a firewall?'.. Ok. > > 5. Name service interactions > > ==> you discuss DNS in this section, but AFAICS, these issues could be > generic if some other mapping function than DNS would be used. Maybe this > issue could be handled by adding something like: > > This section assumes that DNS might be used for a mapping function. If > you are using some other method (see Section 3.8), please consider > separately both the impact on DNS, and the impact on your mapping > function > as appropriate. I don't want to make quite so broad an assumption about the solution space, since we don't quite know which problem people are working on. > > > editorial > --------- Will modify as appropriate. Eliot From owner-multi6@ops.ietf.org Thu Oct 28 08:38:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07779 for ; Thu, 28 Oct 2004 08:38:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN9Xb-000KZE-IC for multi6-data@psg.com; Thu, 28 Oct 2004 12:38:07 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN9XX-000KYs-2A for multi6@ops.ietf.org; Thu, 28 Oct 2004 12:38:03 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9SCc1Dq311492 for ; Thu, 28 Oct 2004 12:38:01 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9SCc0LQ147248 for ; Thu, 28 Oct 2004 13:38:00 +0100 Received: from zurich.ibm.com (sig-9-146-220-104.de.ibm.com [9.146.220.104]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA82356 for ; Thu, 28 Oct 2004 14:37:59 +0200 Message-ID: <4180E82C.302@zurich.ibm.com> Date: Thu, 28 Oct 2004 14:38:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> In-Reply-To: <200410191148.HAA14355@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-shim-00.txt [Co-chair hat off] I personally like this approach (I was always a fan of NOID). Substantive remarks: -------------------- > 5. Placement of the multi6 shim ... > ...Layering the > fragmentation header above the multi6 shim makes reassembly robust in > the case that there is broken multi-path routing which results in > using different paths, hence potentially different source locators, > for different fragments. Thus, effectively the multi6 shim layer is > placed between the IP endpoint sublayer, which handles fragmentation, > reassembly, and IPsec, and the IP routing sublayer, which on a host > selects which default router to use etc. This raises an interesting point about the flow label. According to RFC 3697, a flow is identified by the 3tuple {Flow Label, Source Address, Destination Address} and flow labels are only required to be unique when considered as part of this 3tuple. In other words it is quite legal (even if silly) for a host to use Flow Label = 1 for simultaneous flows to Address A and to Address B. Now, what should we say in the context of the multi6dt shim? Is a flow identified by the complex tuple {Flow Label, {Source Locators}, {Dest Locators}} or by {Flow Label, Source ULID, Dest ULID} or do we simply consider it as a set of flows that all happen to have the same Flow Label but various different locator pairs? I think it depends where you sit. Above the shim, a flow has to be identified using its ULID pair. Below the shim, but in the hosts, we have the necessary state to use the complex tuple. In routers along the way, we can only identify flows in the traditional way. This does need to be discussed in the draft, even before we get to section 9.2.1. > 8.1. Initial Context Establishment ... > At this point in time it is possible for the hosts to change to > a different locator in the set. But until they have exhanged > the locator sets, and probably until they rehome the context to > use different locators, they continue sending and receiving IPv6 > packets as before. I think you need to make it clear whether the two hosts have to *agree* to change locators, or whether it is a single-ended decision. > 8.2. Locator Change ... > Given that each host knows the locator set for its peer, the host can > just switch to using a different locator pair. Don't the exit router selection and ingress filtering issues need to be handled here? > 8.3. Concurrent Context Establishment > > Should both A and B attempt to contact each other at about the same > time using the same ULIDs for each other, the context establishment > should create a single host-pair context. > > However, if different ULIDs are used this would result in two > completely independent contexts between the two hosts following the > basic content establishment above. Is there really no race condition where this would fail? > 9.2.1. Flow-label > > > A possible approach is to carry the context tag in the Flow Label > field of the IPv6 header. This means that when a multi6 context is > established, a Flow Label value is associated with this context. > When a packet is received, the Flow Label value is used as a key to > determine the context to be used for the demultiplexing operation, That isn't enough. As noted above, a flow label is only unique within a {Flow Label, Source Address, Destination Address} 3tuple. And in multi6, that surely has to be extended to any 3tuple in the complex tuple {Flow Label, {Source Locators}, {Dest Locators}}. A slightly tricky per-packet lookup, that won't be good for performance. But there is good news just below... > determine the context to be used for the demultiplexing operation, > hence determining the identifiers that have to be presented to the > upper layers. Because this approach overloads the Flow Label field, > it is necessary to have an additional information to determine > whether the Flow Label field is actually being used as a context tag > or not. In other words, additional information is needed to identify > multi6 packets from regular IPv6 packets. This is because, the same > Flow Label value that is being used as context tag in multi6 enabled > communication can be used for other purposes by a non-multi6 enabled > host, Good news. This is wrong (and I didn't realise it when analyzing NOID). Flow Labels are not unique on their own and cannot be used for anything on their own. You must always lookup a 3tuple.But if the received {Flow Label, Source Locator, Dest Locator} is in the set {Flow Label, {Source Locators}, {Dest Locators}} corresponding to a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim *knows* that it is a multi6 packet. (The only extra rule at the source to make this true is: never use the same flow label for a multi6 flow and a non-multi6 flow to the same destination.) (One catch: the source must not send shimmed packets until it has positive acknowledgement that the destination has built the multi6 state, but I think that catch will apply to all solutions.) Now, I see that you list exactly this below as "Another approach." But I think it is in fact the *only* approach that is fully consistent with flow label semantics, since the flow label is *only* unique per source/destination pair. Editorial: ---------- > 4. Locators as Upper-layer Identifiers ... > This implies that the ULID section is performed as today's default s/section/selection/ > 8.4. Handling Initial Locator Failures > > > Should not all locators be working when the communication is > initiated some extra complexity arises, because the ULP has already > been told which ULIDs to use. If the locators that where selected to > be ULIDs are not working and the multi6 shim does not know of > alternate locators, it has to choice than to have the application try > a different ULID. s/has to choice/has no other choice/ Brian From owner-multi6@ops.ietf.org Thu Oct 28 11:20:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25294 for ; Thu, 28 Oct 2004 11:20:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNC3m-000DH4-FA for multi6-data@psg.com; Thu, 28 Oct 2004 15:19:30 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNC3l-000DGb-2k for multi6@ops.ietf.org; Thu, 28 Oct 2004 15:19:29 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9SFJPru079050 for ; Thu, 28 Oct 2004 15:19:25 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9SFJOdO224168 for ; Thu, 28 Oct 2004 17:19:25 +0200 Received: from zurich.ibm.com (sig-9-146-220-104.de.ibm.com [9.146.220.104]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA56826 for ; Thu, 28 Oct 2004 17:19:24 +0200 Message-ID: <41810E00.8020705@zurich.ibm.com> Date: Thu, 28 Oct 2004 17:19:28 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: For your travel planning References: <415C2465.8050408@zurich.ibm.com> <4180907A.9070800@zurich.ibm.com> In-Reply-To: <4180907A.9070800@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks to the Secretariat's flexibility, we are back on Tuesday again to avoid two unwelcome clashes: > MULTI6 has been moved to Tuesday, November 9 at 0900-1130. > Other groups scheduled at that time are: dhc, mpls, btns, > ltans, ippm, sipping. Brian Brian E Carpenter wrote: > Please note that the latest draft IETF agenda shows multi6 meeting > on MONDAY morning (instead of Tuesday) and on Wednesday afternoon. > > Also note that most of the agenda of the two sessions will be > devoted to the design team documents: > > Multihoming L3 Shim Approach > draft-nordmark-multi6dt-shim-00.txt > > Hash Based Addresses (HBA) > draft-bagnulo-multi6dt-hba-00 > > Functional decomposition of the M6 protocol > draft-bagnulo-multi6dt-functional-dec-00 > > Failure Detection and Locator Selection in Multi6 > draft-arkko-multi6dt-failure-detection-00 > > Multi6 Application Referral Issues > draft-nordmark-multi6dt-refer-00.txt > > The draft agenda will be coming soon... > > Brian > co-chair > > Brian E Carpenter wrote: > >> Multi6 people, >> >> FYI we are expecting some drafts from the multi6 design team >> in the coming weeks. As a result we have scheduled two >> sessions at the November IETF, provisionally on Tuesday >> November 9 and Wednesday November 10. >> >> The IETF agenda is not final, so these may change. The latest >> version is always at: >> >> http://www.ietf.org/meetings/agenda_61.html >> >> Brian >> > From owner-multi6@ops.ietf.org Thu Oct 28 12:02:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06682 for ; Thu, 28 Oct 2004 12:02:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNCjD-000IFi-0J for multi6-data@psg.com; Thu, 28 Oct 2004 16:02:19 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNCjB-000IF2-RX for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:02:18 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i9SG2HGn020123 for ; Thu, 28 Oct 2004 17:02:17 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA29648 for ; Thu, 28 Oct 2004 17:02:13 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9SG2DJ15835 for multi6@ops.ietf.org; Thu, 28 Oct 2004 17:02:13 +0100 Date: Thu, 28 Oct 2004 17:02:13 +0100 From: Tim Chown To: Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Message-ID: <20041028160213.GG15055@login.ecs.soton.ac.uk> Mail-Followup-To: Multi6 References: <4176E3B7.4090806@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Could/should we add a note that IPv6 renumbering (without a flag day) will generally involve a site being multihomed in a transient phase between using one prefix and adopting a new prefix? [I recall for Fred's "IPv6 renumbering procedure" draft we discussed the relevance of multihoming to renumbering, and I think the reverse applies.] A difference is the (probably) each node will be configured to prefer one uplink over the other as an existing prefix is deprecated and a new prefix introduced, as described in Fred's document (in contrast to being able to use both links, with neither being deprecated). We added some notes on the linkage to section 5.9 of http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-00.txt which can probably be improved. A site could also change provider for one of its two uplinks if dual-homed, in which case a site may be triple homed while it's primary or secondary existing uplink provider changes and is renumbered. Tim From owner-multi6@ops.ietf.org Thu Oct 28 12:10:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07950 for ; Thu, 28 Oct 2004 12:10:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNCr2-000JT4-Ab for multi6-data@psg.com; Thu, 28 Oct 2004 16:10:24 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNCr1-000JSj-BP for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:10:23 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E75282F83E; Thu, 28 Oct 2004 18:10:21 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id 11F6D2F83D; Thu, 28 Oct 2004 18:10:21 +0200 (CEST) In-Reply-To: <20041028160213.GG15055@login.ecs.soton.ac.uk> References: <4176E3B7.4090806@zurich.ibm.com> <20041028160213.GG15055@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Date: Thu, 28 Oct 2004 18:10:38 +0200 To: Tim Chown X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Tim, El 28/10/2004, a las 18:02, Tim Chown escribi=F3: > Hi, > > Could/should we add a note that IPv6 renumbering (without a flag day) =20= > will > generally involve a site being multihomed in a transient phase between > using one prefix and adopting a new prefix? > I think i am missing your point... why does a multi6 solution designer consider this when designing a =20 solution? I mean, as some folks have mentioned earlier, it is good to keep this =20= doc short, Regards, marcelo > [I recall for Fred's "IPv6 renumbering procedure" draft we discussed =20= > the > relevance of multihoming to renumbering, and I think the reverse =20 > applies.] > > A difference is the (probably) each node will be configured to prefer =20= > one > uplink over the other as an existing prefix is deprecated and a new =20= > prefix > introduced, as described in Fred's document (in contrast to being able = =20 > to > use both links, with neither being deprecated). > > We added some notes on the linkage to section 5.9 of > http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-=20 > thinkabout-00.txt > which can probably be improved. > > A site could also change provider for one of its two uplinks if =20 > dual-homed, > in which case a site may be triple homed while it's primary or =20 > secondary > existing uplink provider changes and is renumbered. > > Tim > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Oct 28 12:11:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08010 for ; Thu, 28 Oct 2004 12:11:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNCre-000JWb-Mb for multi6-data@psg.com; Thu, 28 Oct 2004 16:11:02 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNCrd-000JWM-Jk for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:11:01 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9SGAZU24358 for ; Thu, 28 Oct 2004 18:10:35 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SGAZSj031828 for ; Thu, 28 Oct 2004 18:10:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281610.i9SGAZSj031828@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: multi6@ops.ietf.org Subject: about draft-arkko-multi6dt-failure-detection-00.txt Date: Thu, 28 Oct 2004 18:10:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Some comments about draft-arkko-multi6dt-failure-detection-00.txt: - in the intro a missing < before xref target='transport'/> - in 3.1 link-local IPv6 addresses, private (RFC 1918) IPv4 addresses, etc, are excluded. IMHO this is a too strong constraint: only ambiguous zone limited addresses should be excluded (note that one (only) address cannot be ambiguous). - in 3.2 s/the relevant default router/a relevant default router/ (links in a resilient multi-homed environment should be served by more than one default router :-) - in 3.2 "Theoretically, it is also possible for hosts to learn about routing failures for a particular selected source prefix, even if no protocol exists today to distribute this information in a convenient manner." I disagree about the last part: there is a well known and simple protocol to announce routing failures for a source prefix: deprecate it, i.e., send RAs with zero preferred lifetime in the prefix info. Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Oct 28 12:46:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16075 for ; Thu, 28 Oct 2004 12:46:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDPX-000NoG-EQ for multi6-data@psg.com; Thu, 28 Oct 2004 16:46:03 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDPW-000No1-8f for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:46:02 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9SGjs004328 for ; Thu, 28 Oct 2004 18:45:54 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SGjtSj031983 for ; Thu, 28 Oct 2004 18:45:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281645.i9SGjtSj031983@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: multi6@ops.ietf.org Subject: about draft-bagnulo-multi6dt-hba-00.txt Date: Thu, 28 Oct 2004 18:45:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk I like the idea but the I-D is hard to read by itself, i.e., the send-cga I-D is needed to understand things... But this is more a problem about the organization of the document. But section 4 is incomplete: "2. Modifier generation. Generate a Modifier as a random or pseudorandom 128-bit value. If a public key has not been provided as an input, generate the Extended Modifier as a 384-bit random or pseudorandom value. Format the Extended Modifier as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [3]." this is underspecified (RSA must be specified) and not clear enough: IMHO the idea is to get a 384 bit random value and to encode it as a RSA key in a SubjectPublicKeyInfo DER value. But there is at least another interpretation... BTW the encoding gives only a static (i.e., easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 31 00 <48 octets> but please check :-) prefix. Finally I am not convinced a type tag is not required for HBA CGAs, i.e., today HBA CGAs are not more usable than CGAs... Thanks Francis.Dupont@enst-bretagne.fr PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and check/sign/verify). I can send it to who'd like to extend it to HBA (I'm using the standard BSD licence). It should be easy because if I've understood the design the multi-prefix extension is an extension field? From owner-multi6@ops.ietf.org Thu Oct 28 12:47:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16126 for ; Thu, 28 Oct 2004 12:47:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDQS-000NvW-H2 for multi6-data@psg.com; Thu, 28 Oct 2004 16:47:00 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDQR-000NvE-7Z for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:46:59 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9SGkm004408 for ; Thu, 28 Oct 2004 18:46:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SGkmSj032006 for ; Thu, 28 Oct 2004 18:46:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281646.i9SGkmSj032006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: multi6@ops.ietf.org Subject: about draft-bagnulo-multi6dt-hba-00.txt Date: Thu, 28 Oct 2004 18:46:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk I like the idea but the I-D is hard to read by itself, i.e., the send-cga I-D is needed to understand things... But this is more a problem about the organization of the document. But section 4 is incomplete: "2. Modifier generation. Generate a Modifier as a random or pseudorandom 128-bit value. If a public key has not been provided as an input, generate the Extended Modifier as a 384-bit random or pseudorandom value. Format the Extended Modifier as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [3]." this is underspecified (RSA must be specified) and not clear enough: IMHO the idea is to get a 384 bit random value and to encode it as a RSA key in a SubjectPublicKeyInfo DER value. But there is at least another interpretation... BTW the encoding gives only a static (i.e., easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 31 00 <48 octets> but please check :-) prefix. Finally I am not convinced a type tag is not required for HBA CGAs, i.e., today HBA CGAs are not more usable than CGAs... Thanks Francis.Dupont@enst-bretagne.fr PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and check/sign/verify). I can send it to who'd like to extend it to HBA (I'm using the standard BSD licence). It should be easy because if I've understood the design the multi-prefix extension is an extension field? From owner-multi6@ops.ietf.org Thu Oct 28 12:53:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17624 for ; Thu, 28 Oct 2004 12:53:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDWC-000Oqi-KO for multi6-data@psg.com; Thu, 28 Oct 2004 16:52:56 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDWB-000OqP-BV for multi6@ops.ietf.org; Thu, 28 Oct 2004 16:52:55 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7601689830; Thu, 28 Oct 2004 19:52:54 +0300 (EEST) Message-ID: <41812380.3020406@piuha.net> Date: Thu, 28 Oct 2004 19:51:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: multi6@ops.ietf.org Subject: Re: about draft-arkko-multi6dt-failure-detection-00.txt References: <200410281610.i9SGAZSj031828@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281610.i9SGAZSj031828@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Francis and thanks for your input! A few responses below: > - in 3.1 link-local IPv6 addresses, private (RFC 1918) IPv4 addresses, > etc, are excluded. IMHO this is a too strong constraint: only > ambiguous zone limited addresses should be excluded (note that > one (only) address cannot be ambiguous). I'm open to doing this either way. I guess the issue is accidentally attempting to connect to someone else's 10.0.0.1 address. I've heard that protocols in the multimedia space already can run into this, however, so this may not be a new problem. How do others feel? > - in 3.2 s/the relevant default router/a relevant default router/ > (links in a resilient multi-homed environment should be served > by more than one default router :-) Ok. > - in 3.2 "Theoretically, it is also > possible for hosts to learn about routing failures for a particular > selected source prefix, even if no protocol exists today to > distribute this information in a convenient manner." > I disagree about the last part: there is a well known and simple > protocol to announce routing failures for a source prefix: deprecate > it, i.e., send RAs with zero preferred lifetime in the prefix info. Ah, yes. Thanks. --Jari From owner-multi6@ops.ietf.org Thu Oct 28 13:02:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20162 for ; Thu, 28 Oct 2004 13:02:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDfM-0000Zg-U2 for multi6-data@psg.com; Thu, 28 Oct 2004 17:02:24 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDfJ-0000Yu-1h for multi6@ops.ietf.org; Thu, 28 Oct 2004 17:02:21 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 10:13:54 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9SH2F6s012080; Thu, 28 Oct 2004 10:02:16 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4186.cisco.com [10.61.80.89]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9SH3kjn007914; Thu, 28 Oct 2004 10:03:47 -0700 Message-ID: <41812616.9090506@cisco.com> Date: Thu, 28 Oct 2004 19:02:14 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041027) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt References: <4176E3B7.4090806@zurich.ibm.com> <20041028160213.GG15055@login.ecs.soton.ac.uk> In-Reply-To: <20041028160213.GG15055@login.ecs.soton.ac.uk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098983027.707835"; x:"432200"; a:"rsa-sha1"; b:"nofws:305"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"odSTfNwP1w2DqvGn9aFy7g0ZX4Fc2WKhYXt4nbbxNTTzPX4EFJxHg4h6VZ/8J" "jF3/wmstM9NZ7ojq7JglRrJYMT1/9OYSC38YnyxmHqy+MSgZJzmz1dqqNZmCp" "ghApAvYyT0u7W3EiT33/iLMLUaFCIBcaLeiqukmvPq/ToyefQ="; c:"Date: Thu, 28 Oct 2004 19:02:14 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to" "-think-about-00.txt" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > Hi, > > Could/should we add a note that IPv6 renumbering (without a flag day) will > generally involve a site being multihomed in a transient phase between > using one prefix and adopting a new prefix? Yes, this makes sense. Could you suggest text? Thanks, Eliot From owner-multi6@ops.ietf.org Thu Oct 28 13:09:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21747 for ; Thu, 28 Oct 2004 13:09:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDm3-0001bj-Rc for multi6-data@psg.com; Thu, 28 Oct 2004 17:09:19 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDm2-0001bP-OD for multi6@ops.ietf.org; Thu, 28 Oct 2004 17:09:19 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9SH94q09167; Thu, 28 Oct 2004 19:09:04 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SH94Sj032204; Thu, 28 Oct 2004 19:09:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281709.i9SH94Sj032204@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: multi6@ops.ietf.org Subject: Re: about draft-arkko-multi6dt-failure-detection-00.txt In-reply-to: Your message of Thu, 28 Oct 2004 19:51:12 +0300. <41812380.3020406@piuha.net> Date: Thu, 28 Oct 2004 19:09:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Hi Francis and thanks for your input! A few responses below: > - in 3.1 link-local IPv6 addresses, private (RFC 1918) IPv4 addresses, > etc, are excluded. IMHO this is a too strong constraint: only > ambiguous zone limited addresses should be excluded (note that > one (only) address cannot be ambiguous). I'm open to doing this either way. I guess the issue is accidentally attempting to connect to someone else's 10.0.0.1 address. I've heard that protocols in the multimedia space already can run into this, however, so this may not be a new problem. => IMHO there are three issues with zoned addresses: - zone IDs are local (so I can't designate a zone to a peer) - an unclothed zoned address is likely ambiguous (API issue) - is the peer zoned address in the same zone? (perhaps your concern). I tried to solve these issues in my address management for IKEv2, and in fact IMHO the only reasonnable scenario is to use only at most one zoned address and from the beginning. This is not an unlikely scenario and don't forget than the RFC 3484 rule 8 on destination addresses is "Prefer smaller scope"... Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Oct 28 13:22:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24738 for ; Thu, 28 Oct 2004 13:22:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDyK-0003Xb-Hf for multi6-data@psg.com; Thu, 28 Oct 2004 17:22:00 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDyJ-0003XD-78 for multi6@ops.ietf.org; Thu, 28 Oct 2004 17:21:59 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DF6FB2F8F3; Thu, 28 Oct 2004 19:21:57 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id 1804C2F8EC; Thu, 28 Oct 2004 19:21:57 +0200 (CEST) In-Reply-To: <200410281645.i9SGjtSj031983@givry.rennes.enst-bretagne.fr> References: <200410281645.i9SGjtSj031983@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: about draft-bagnulo-multi6dt-hba-00.txt Date: Thu, 28 Oct 2004 19:22:13 +0200 To: Francis Dupont X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Francis, El 28/10/2004, a las 18:45, Francis Dupont escribi=F3: > I like the idea thanks, > but the I-D is hard to read by itself, i.e., the send-cga > I-D is needed to understand things... But this is more a problem about > the organization of the document. > agree, and i apologize for this. I think that the outcome is more focused in the specification of the=20 mechanisms rather than in the rationale, which is what it should be=20 presented at this stage. I think that an appendix with an example would help to clearify. I will=20= try to add this. > But section 4 is incomplete: > "2. Modifier generation. Generate a Modifier as a random or > pseudorandom 128-bit value. If a public key has not been=20 > provided > as an input, generate the Extended Modifier as a 384-bit random=20= > or > pseudorandom value. Format the Extended Modifier as a=20 > DER-encoded > ASN.1 structure of the type SubjectPublicKeyInfo defined in the > Internet X.509 certificate profile [3]." > this is underspecified (RSA must be specified) and not clear enough: > IMHO the idea is to get a 384 bit random value and to encode it as > a RSA key in a SubjectPublicKeyInfo DER value. yes > But there is at least > another interpretation... BTW the encoding gives only a static (i.e., > easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01=20= > 05 00 > 03 31 00 <48 octets> but please check :-) prefix. > ok, i will try to clearify this > Finally I am not convinced a type tag is not required for HBA CGAs,=20 > i.e., > today HBA CGAs are not more usable than CGAs... > i am not following this, could you expand a bit? > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and > check/sign/verify). I can send it to who'd like to extend it to HBA > (I'm using the standard BSD licence). It should be easy because if = I've > understood the design the multi-prefix extension is an extension = field? > Great! we are planning to implement HBA, so this would be really helpful. I will contact you later. Thanks, marcelo > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Oct 28 13:39:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28680 for ; Thu, 28 Oct 2004 13:39:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNEEx-00064C-Sk for multi6-data@psg.com; Thu, 28 Oct 2004 17:39:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNEEw-00063k-4o for multi6@ops.ietf.org; Thu, 28 Oct 2004 17:39:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9SHd0j20877; Thu, 28 Oct 2004 20:39:00 +0300 Date: Thu, 28 Oct 2004 20:39:00 +0300 (EEST) From: Pekka Savola To: Eliot Lear cc: Brian E Carpenter , Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt In-Reply-To: <4180E165.4020706@cisco.com> Message-ID: References: <4176E3B7.4090806@zurich.ibm.com> <4180E165.4020706@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 28 Oct 2004, Eliot Lear wrote: >> 2.3.3 Can your solution be aggregated and implemented site-wide? > > This is now in Section 4.1: does your solution change existing aggregation > methods? Oh yes, sorry -- I missed that. >> 2.3.4 Does your solution impact existing traffic engineering methods >> >> I think these are rather important, even thought the latter is focused on >> MPLS, when it should be focusing on BGP traffic engineering practices >> instead. > > We had this in there and nobody could understand how a solution could impact > traffic engineering methods, other than by changing the aggregation methods. > Thus Section 4.1. Yes, the text was probably focused wrong. Maybe it should have been something like: X.Y Does the solution solve traffic engineering requirements? One of the significant goals of IPv4 multihoming solutions has been to be able to perform traffic engineering based on appropriately adjusting the BGP advertisements. If the prefixes used by the sites would be aggregatable, the sites' ability to perform traffic engineering would be diminished. Does the solution offer ways for site the to manage its traffic flows? If so, how? Is this controllable on a per-host basis, or on a per-site basis? .... i.e., there should be some section which forces the solution developer to think, "gee, if the site would no longer be allowed to advertise more specific prefixes, or any prefixes that would get into the global routing table, how would it fill its traffic engineering needs? Or is this left unsolved? [which seems to be the case now]" >> 2. On the wire behavior >> >> 2.1 How will your solution solve the multihoming problem? >> >> That's why we're here. Remember, a reference is fine. >> >> ==> this seems almost like asking, in an email context, 'how does your >> proposal solve the spam problem?'. This question is not good, because I >> don't think we have sufficiently clearly defined what "the multihoming >> problem" really is (and some might even argue it's multiple different >> problems), and its unlikely that the solutions can even solve the whole >> problem. >> >> This will cause folks to answer, "the solution provides connection >> survivability, solving the multihoming problem" .. BUT THAT'S NOT >> THE (WHOLE OF) MULTIHOMING PROBLEM! >> >> It's difficult to say how this should be fixed. One way might be trying to >> precisely define what 'the multihoming problem' refers to. One way would >> be >> rewording the question so that the responder should try to describe which >> multihoming problem(s) the responder thinks what the solution is solving, >> and which not. Reference to a list of multihoming problems would also be >> OK, but I don't think there is a good document laying these out. > > What I am looking for, and perhaps a clarification *is* in order, is a > scoping of what problem they think they're trying to solve. This document > doesn't require you to solve every problem, but simply to explain how your > solution to the problem you think you're solving will impact the world we > live in now. I agree with that. The text needs some tuning to make it loud and clear that there is not a single big problem to be solved, and the responder should articulate which problems he's trying to solve. >> 2.7 Can multihoming capabilities be negotiated end to end during a >> connection? >> >> If the proposal introduces additional overhead, can the information >> be somehow piggybacked on messages that are already used? This would >> be useful in order to keep connection setup constant. Please also >> indicate any drawbacks that might apply due to this piggybacking. >> >> ==> I already proposed the following new section in March: >> >> === >> 2.X Can multihoming setup be delayed from session setup? >> >> If the proposal induces overhead (added bytes in packets, or >> additional packets), is it possible to delay that overhead (or >> "multihoming set-up") to happen after the session has been >> established? > > This is included above based on your earlier feedback. Piggybacking can mean multiple things. This is not sufficient, see below. >> That is, is it possible to specify that multihoming benefits would >> only be achieved for sessions which last over XX seconds, to optimize >> away the cost of set-up for short-lived sessions? > > And this may be too specific to a mechanism you have in mind. For instance, > perhaps this would be handled by an IP end host option. You seem to make the assumption that as long as no additional messages would be sent, it would be OK. That's not the case: my proposed text was also addressing the situation where you wanted to avoid the extra *overhead* and processing at the start of the sessions. The piggybacking text could be read to just refer to being able to bundle the messaging right from the start, right? Trying to say it differently, so that it'll be clear for certain: - piggybacking has protocol overhead, which can be undesirable for many reasons (and it might not even be possible to completely piggyback the packets), requiring e.g., new options, and such packets might be dropped in the firewalls - if you do piggybacking from the start, you'll waste bytes and processing even for short, 1-2 second flows. That seems like something that one might want to do away with. Delaying the multihoming set-up from the initial signalling would do just that, whether it would be piggybacked ont he data packets, or sent separately. Again, it's not clear whether this is a tradeoff to pick, but it should be on the list of things to think about :-) >> 3.12 Are there any implications for scoped addressing? >> >> Please see RFC 3513 [1]. How does your mechanism interact with >> multicast? >> >> ==> what does 'multicast' have to do under 'scoped addressing'. Granted, >> multicast addresses have a concept of scope, but maybe this calls for an >> additional question, 'Are there any implications for multicast', where >> multicast would include both global and non-globally scoped mcast. > > The question is right there. I attempted to borrow from IPv6 nomenclature. > If you believe that nomenclature is failing us here, then we should change > it, but we should do so elsewhere as well. I'm not sure if I understand your comment. The grouping of the questions seems to be odd, because handling (global) multicast has probably different things to think about, than handling link-local or ULA unicast. The latter has to do with scoping, the former.. well, there are always some problems with multicast which one might not have thought of :-) >> 5. Name service interactions >> >> ==> you discuss DNS in this section, but AFAICS, these issues could be >> generic if some other mapping function than DNS would be used. Maybe this >> issue could be handled by adding something like: >> >> This section assumes that DNS might be used for a mapping function. If >> you are using some other method (see Section 3.8), please consider >> separately both the impact on DNS, and the impact on your mapping >> function >> as appropriate. > > I don't want to make quite so broad an assumption about the solution space, > since we don't quite know which problem people are working on. That's cool. But there are a lot of questions about DNS which should be asked in closely identical fashion if someone invents his or her own discovery service. What would the best place to require them to discuss those issues? Seems to have significant overlap here.. A possible approach might be generalizing some of the generic DNS questions, and keeping some of them which are related to the continued well-being of DNS (which might not be a problem if the solution invents its own for its own stuff). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Oct 28 15:02:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17378 for ; Thu, 28 Oct 2004 15:02:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNFWM-000HGr-Bt for multi6-data@psg.com; Thu, 28 Oct 2004 19:01:14 +0000 Received: from [200.180.242.22] (helo=PENTIUM4.org) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CNFWF-000HFK-Uq for multi6@ops.ietf.org; Thu, 28 Oct 2004 19:01:13 +0000 Date: Thu, 28 Oct 2004 16:01:00 -0300 To: "Multi" From: "Smd" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yoeyfaeovhyrazrdsyvl" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: **** X-Spam-Status: No, hits=4.8 required=5.0 tests=AWL,BAYES_70, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY,RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------yoeyfaeovhyrazrdsyvl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Screen and Music


:)

----------yoeyfaeovhyrazrdsyvl Content-Type: image/gif; name="cvjdprssjb.gif" Content-Disposition: attachment; filename="cvjdprssjb.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhPwAQAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA/ABAAAAj2AP8JHEiwoMGD CBMqXMiwocOHECNKnAgx0IyCq6IMzGcx0DaCFgVuOxRlxjOKDKu10Chy1YyL//LNqPYvyqqB 1WawLDXjY4tYKBVabDEwCkmi/1YhLRgoytKiT4MSrPZM58BD/1rADBT1X7WcUWV2kXrw0Dat BVcKbBHI5U2Bpao5LVgqCk2yBLfdnEuw5Nqe+VrcrHZzxhWCbvFipOmX4AykfA3/M5t1qdxA igs6vaKV5V+4kIk61Yk2a5d8mQ+q7csyZ7VtM94KfCxw1ZW7qQtyTgvz37MWgjUj7bJ5de7j yEmX1Pp45WOdz4s3Hy0dOPLrDgMCADt//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f985n3NfCF8I/3//f/9//3//f18IXwj/f/9/ XwjfOV9KXwhfSv9//3//f985n3NfCF8I/3//f/9//3//f985Xwg/Z/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/X2u/Vl8I Xwj/f/9//39fSv9/XwhfCP9//39/LV8I/3//f/9//3//f/9/X2u/Vl8IXwj/f/9//3//f/9/ n3NfCH8t/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f985XwhfCP9//3//f18IH0JfCF8I/3//f59SXwj/f/9//3//f/9/ /3//f985XwhfCP9//3//f/9//3//f18IXwj/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/P2dfCF8I/3//f/9/v3dfSl8I Xwj/f/9/n3NfCD9nv3dfCJ9S/3//f/9/P2dfCF8I/3//f985Xwi/d793Xwi/Vv9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f38tXwj/f/9//3//f/9/n1JfCP9//3//f19r3zlfCN85v3f/f/9//3//f38tXwj/f/9/ v3cfQl8IXwi/Vv9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------yoeyfaeovhyrazrdsyvl Content-Type: application/octet-stream; name="Cat.zip" Content-Disposition: attachment; filename="Cat.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAIB8XDHNwAN4AmAAAB1cAAAJAAAAb3Z0d3MuZXhlP3o4AXcrUCPFZ/y2sbUx 2SJ2evbcZ+YJrIl22ny3xPNVaHKmwVddysQju8K6GFJUlSWz40WlH1yQQmKpniBt6QW5PrKH T1W7GO3aRTQ2nBSXUHwcwEluTU0TARPPjbRVCGuuNETFFIfmdjHHtrx0gb4zCCcC82LHZkzV EXm3VJnY+XUuIOMgGc6nv4b8SB+Aps9Q7k4Pt8SMxLfjvUfCqahxLuPgW/mS34gBJNFSRGoC 9ce4crMP3Fdb7cO5UHZ1p7DNZiWTA0fZtNaMOn/8NdrKoG68CbgaY9JNbqig6B6z4/YYpr0F UIsIwHo6dPkTR9CzJ9k6+vYb6zJnyOQJ9su/ZL+fN7+XPHJjc73S9HfGaZ6pbrh0I/nCT2yt PzBqrD3D31YMZUjeDNj3NhNQOODPm1bIV3izkDn3HN7nYRFXPIV2Cr9dL7JG3d6oe1EL/WGb tiuASxX4vxEqp14dX32l7mKh9fy8pDPKdXnT4qIsYjWsfEjqCcEJeAlBLV4MJceYvq0gbAMm 3zNBEDEQbOOavoAjCqEWI+U+WfT0e6SCZjL8QJnFQfD5zdZjpKK9xXuBbFWSxe4Bs56EI13m uXWFFe5S7drt0WSOosLjxGcq9h0PrO26IRuIsMFoJkto1xL/n0TnwBP66s3JUN78yEh+Gh5z pcwAx7YNA0LlwWhbQrgPF/FW4T1hifYuzJ+Zx4xglsVLazpyEotnSMEE3flNrzUqMMxL9xBL Jg30kVy2ZWe7GVJGL1cVUZMVnf2WFfeoLm/YfUE7lmjRClb+tpC6R5BEYTsomzZ32vrEL5bi LFl/70L9NUdr2BZmT/TzfNsb1BanwxDlsqhTB5IqDyNArrmoja5UEE02Jyx4+AJd/c+rtiOK 77lTS8rW0OQkNzo5Qll9rQj9NkHh30YEEvP1wMWJpk2bohTEKavzz9FJCrsoRHAp9bUqi6gy fnNjnEfsLF2fnbxs3DIX8tWom9c81XYdL7C4AWiUrsWH3zXvhiW420DR7mFeRWOOgOqPS24K fdzYs8FBwK8TBnQ426gtx0NZbsFbLr040ZoxkzRRqgeiAetdw+7kQFfVVi5v5ao3zQBPc9m8 Ec9vvLTGrIGPEGiDLYRvZe15wa92ImolxpCdpXgLKrf/YQQBtZkrxQTkbCBNIeGbVzpX55xN gWworVZQrbtPxy6tfOhqmNgg8qskTsFGr5Xf321+lU3gsQs4r7WNMg081SaETxBKGsE1NoxW TOQoP2wUkiZ8cRN0x7X5HGVGjeqG8BKOmWojMWlocJkqXGvMovDxqLlXM/sknLJTaCP4AJxb GGLAWs+yHsgKvqIyqYAdN+p41dxC7zh/DwN++Ac2+N/HaCSqIcPRsvstAI119VubbAtJjX7H UZoVcHXOEH8F+AYlzJRkhlD9+fawggWXEzOmJ5jRtg9WbvHmpcqwtVNWDv+7geZC9s7G5Pkh pfnc8SazpQ4vVP7z2XjqhJBs+6VLy9yz0wiW3lopiyQGkbrH+0HFGomtdrpvCiV4ZP/Rv28i E/QMbd4FH5mvNevNwvRaO80jZ3qousNYXP09XoWcOzOgpGJ98m1k5kMfKvKMlRk1i113ywNJ c98ndEzsu93Gg/Kdna3yE4JR7uoohnt8OTBKjwGlelodngIee8jY+eitVKQ+wL7gsQ/CInMh IjYsiNHDE8LpZm+xFkBweWq2LIDKTYBm+t6CkIo6ib8caYi8faoZKqhcws5qkF83UsAQFIax zQxfAMik0+xFNreeKrR2aOYu+HeJHdh33629AlwUQnJezhJA52310U/pzWg1lkbRQOZW66K5 oDFxiP7oZMANsJPFMO/UF15KM7v+GeJvM7h6mWmh0lpiqWmLJKHJ/IGISsXjf4bfcCcwfUqt r2BQwpxJxyOAyPy8l5v6YA4VpQwt2pmZ7J+4Edwi/rQAsj2BLJ8jVa925tO+p72B0m1YO6Yy F8VbwYn80i/hTYthr8FkNHKq6Ens4fsKY/CPLvLyF+ojIacipc6P+4cECRpHby+rP4bddTyG nb27TrYk5cI0A+xX2ZxGIcdZxqm9fB4rRRSqMr7qzpGf/5X0sXRbI0yYRTqQvoMDPwP7c+Gt eiZEk6FRahlEpXQ1qI495aOqvarAhfrntH9krkUWYiVC3nkGP9Gs1NmLsawUWYpth9RPBRp+ uIXg4WtRg8thgNoLnMtUgHaQrom9vXH4voVT0sotxYF/Qbn7rR81BwBHCTFfrqurn4upJtEd OWvLwYccfC9UJco6OKsRW8uMo1pA3mMjj7KvKAGPWnF0aLyxlq/ApjdHZNnUUzfTRQoPxuFS O73dNd+2EU0+9aHw1hShRNfJWXK13Ntpx3ussBCC3uIGz1552d+T3LKm2oCWB7LJSAzxMaV1 +P/76JWQZEYy1icgHJpd3DeixG/C6uFGZZHMxXS2QuRM9QXDZSSqxyNvDjIaFRq+In6oY5IV GL4T6saz2XDRc0U6qMZCRAW84qJI7+PLtcLjRTvAi3BNkJuD7geW/pApdxTRDtje9+gfhL/M SYfJOsmOJuDa5/UcCTLtd7wasbnMYmVpbpKHzWV6UX3GWr24wWPu3jp2vNkMIiXchoV+sr+A ilHZaGpPHowY4CEamORCyCi8ccgEFFuGYO7RCD55tH4JsFQ3MvlRnmUg7Sc/eTH0WKcDyhly Gyw3+4cVB+vppDBRu3Im5TxwzfM0EpMG5MO8xdeQQW/V6XT/Xln1jpG3nEnEC0gSSxnnbTaH dGr/qYbocBTaRZSvFxVSL204a0odyNx/J60UQQ0NwSFiVf81MeqVqbrqRLA92LRO035+8FYe QPFsN/JKDRn1rDaoZk2MnUuIFoE2sc1z4umM2Ln7zEXnRQ6F02tFW33rsQJyJmCFwn58EU/S D852Wm8QBjbMJ7mcpxo9SFcScMBz4j8oCacigQ0MIF1Nah/LFKS2NLObecjQUgqh/z6xgOeX a0Dl6tFQfXl9fZeEkpUljXczsW0ggPWu/J3Qn8Q68FrWfKhka700LsItelmeybERZHhEHCnm 2Jxa9TWZ+6kdIu7hWlQtt2y8Q6w0457wlt2ruadasKgkk0S1cAHYaMUKnenLr7DtoCe22adf NJIsMgN0scHE5n6QxoyiIaJzvzY9FFTmDU4V6roskyNqqM8YRD7VquJfHVfJWj+lXf0VTfXq r9DiP+Q84WWwcbwaiYq7qWJlvkMBR6+ovT9mAyJfzJeqMaX18Hxx+x4k6V7ajygkfz2mh/hC B2tdAWWIQ0oioHxQq4a2WhI1bWg7+xY+i55NRCATug33sVPIB3hgzuLhvGKi7deXNqVh9h3S Rc1imHzS/cQ0ik8oVrLCbuUp1hUrWk9OCQMYjD0SZoSa7vlyD2Rr4SE4gJ7F8hIuXLReUNXf SYDf+MtTj5T+FS9S15B3UAyttdZ+uJmzQI+oKWIeaMyX+aUgni6qYfoOxmTorB/txKwMMYS8 HtF+Y2bCpMAA+AGZUM1reDar81nUz5bl+682PCDU1Yvb3h91P4U01I2HrqYGsQ5vN6x6XZii 6Nl645I9VOfp6fIHZ7/rpSLw3etvACnQL3bKJQaEUTFmR+nkXOPkb2pFvVXVNBTZyjZzwv2W ygrmgVS45Za1+mt/wfC5udUOSRXdrCVtw28sbNF/vlGoLOA/qaA2v5PzymM5GsK0Xzp/jthN bh5d6tmUGeHNEw5U2+54j2H5GUbxRcfqMtrnyBsZSx41roe0bCJ0CUJD7KsoLW9qrVd6+TRk 2Czp2baG5xcmjiRy9Zz89nSrRTy//G1EWHOHdNe4TfKqJVFTIjHjWpaLCFF3WuLHYVlw46YY /F28JJk3+7Ldsj6RHwTBLjxWQ+0xJL6jUL2590Vh0wZv8biigQMZ6I5jXe88c0NBpF+FbuAl 1yEQJOSfxR2qdxlrviFfCISftWyjrjuPSabKOc3mQmWalft8P+lwRvDiSG7RRqR/zElB2Z+/ 1shXeQcRazicNKMiFn9bkptznVrCybcWFLJYYLkw9/F5kNh/pSfPgMdU4/zgfdRL1q7KT1zk K8ueKuRZkBKaracgb3KdOhIgnmhLlE3D0pyZ/FkVE8XpR/kPIGDAl/mWgly0l/8M6Tk3uxIj lhKsNHALphtVAoMvdKpYWO9t531lt8wkSlzrhhfYN4TSvlzCn8xOiCHSVqmgGd8blX0ld786 vJwulhme5D70uYmMNia/RIoQIaia1ulmhJnbATPD7bo34TqYCU5AM2uKflXD1CfK0NyPvm0E POaaJq6sUcebQrIgGpvGm0MPGheee+dRNGKJD1CUFta1admuN/SXFbF5REV2QNXQj9pKVd5Z NltH5l2BmS8+LojPBhOPFh+VJy2VzweGFMU8I88n+Adazn2o6evEMQ2p1tyjmsqzgdQMiaVV G9Rw1ruMTvhnzadhenKIP/X1EFIVWRUU5cCH1ReIiZFp2sQgENNX7Kk3uc96Qc3W51rBUcRS zrixCiMC8Cd96yPqq2CTZtK0kcznUC8Qfv9cLiTBgd4M9uGNxoK/dIJs2aZSG0SXdNYh04WL d+rimVP3+eCK2ZE4SNvAecp1cka+hebIrkEDdGcwvOXdJNCnasiKXmeovRs2GLB4iyMXM+xc +S6VbYxAo8Hmc1/NfFNv1HlObGPSMvZbyorQtZii7eN5GE841apLrcHsm4f5YGAaGm2joSOS dzLlfThZ3YChkpD/vaB3tWYnXeaZmjndSRm6egfkaUHLY9AzAdTQoPS1zR9xn1emu6n9RVHX piCr8gFXshf+FZ762sey0oLf/oP74FUt2rpEVTxU4r84nS8HDqO64cNnqoqBXhPUXNsaqWlG Kv+rW3m/y0Kj4L2K+QEB/UTph6cPiYjIAPAU2N98BMVt6Z5OZ+PnrqJuFvWVle8zrF6ERk85 gMXjdp4TJzpHWqy3JfP4GwjVfRrYNp+8i4HEOMmR0bVq3j8TWbl8kl50lNg4a6icvGY7y8T+ gRXtwI6HvA4EX/yzpjVdGhfy+UAaa93wyhP6dsW8QueqPnmTMe6lVnDCA20OOoRh92nQd/Wc LcjakxYgTcaX00tAuyZRGnEv9uESNJ6Fj7mXRDLmxOlnQwJMp9EwnNPOvk0cGfYyAoEit4Vp An/KmKiyTrNFM7ccINex4xOL7y1IvwjZItTmM+hHhXbRB+t0WC5r7UlA7KicS3Xp5qCbTn6h XfP0AoFCayiy1llh1U78rVrz7+EbEjXuPE2P/ixute2wifS8DYuO2vnP5JY5c04Hm5JNh5Qa EJ5w/VDc08fiHE1fsDHSwRXIbojNhmO7EYytRp/Z2p/bxRUoBIaaxfUZKtHUKsK+V9D0HSkp e4TUFaQhj5JEo9p8xE+yx45DOF8xGsjdMDxNkR3ItDEfc27KZUe67/itWk983XUEYIIn78Un bSZ4Mp8SxCsadwtEUqQWzFxhEA0ZMycdBb3zl3cZPuBnCi3UvqUTLCAYywNp7teLHKY9utT/ qhP86faK+qRGQ5Hd5lNVwWLTVkymrg+SWKXVhuBotp/RbrjXsUxdppXBV81hkIIQnAjceAJ/ BwYfrmpUvKRzWH+6Xl0VG9iUD5Qhgk5+XF3Op1x6IeTstJuoPuPVLXz2JICp4WEAnPSrbyUa U0kZuWh6qhQz43zv+aYZlwRALg9LiSXciWTLJbWJxCMaEF8tvn4Gh7TxNbgrEYbXdf6Ziwt8 ntKlCWBAfchXTlJfybIaX/66uJ9kTfVDHtlclYvPzDYASOLCjUylfSpX6nyfnoL/pdJOAhrB RECW2agQdzS9mEZwN3z1WZQ16dGCHQ2smfgS0EilSP+ftw+sAqYm3N2bD6VAw7QMOOe6KDuR 469Zdza3dTfvPOIPjIKKa9wW1p4FxctAFn5cenp5ZA4M0p8IeV4wKDPOAwwNehdBuwP/qoIY 1FTVQ0UQospocEH+7WQ8+KFtvdFrHK3P2r0o6w/CVP2niwVJOtlCT6HU0sWwrqIxf29ciI53 IWd988M2VyR5toV8GkFUDuOfK+y4wPV3TvkHK3xJg4XOscIp4e30oh9hNjYpc0sPBkgovcGZ 2lG36poMZn8C8nKA0YIB6bFhX3bAjieZ0uPjrJ+O4QaOaVBB4NIYh2UUh8+IuRF7RMU0DUUB YavG7dccZbvxtdZegXm54LNm07cKe4LFBAdn0lmcAyAfx2JvtznMqilObJcXznSdE8Pu8pYb HXeTUvylyfygV0zyWYE/iSyCnHkURM41O2s+rQ+dTal5Ms8QYQGNZYw9YnOCJ9nCvWEMRBTM ubvuzu8oUs7Y5xTNyN66xmsNabDqNfji3hBB2bKZZWBEYn33kQeETHz+zjmcUh2Y0rSBB911 dcu/Xs3NlUjaM/Y2aarg3R/02wSK/0kZT9PM2vpcdv6O9NbbSWW6mxs6Ovd3JTx4QKy26V1Z f6Jy1HQvUEBpodteldROXYUdUVJIUNVVg39OEtU6HQa1AItuOpi/ihNmaaAts/M1/0Bz4mwn eP5DJ/6ttYRvqXAxE2fxQgTVGJqyrOYHwikvuh1n8Y2WMP1oNAspFsKr3zfLHxtuLbw1uR+Y wCgw8ilvc8VZa9fOy3wc00mZKVHwd3eMA0EBwstC2OvtZYyepxCvUlqmdrEzS0zxIQmrnN4h cNf51LjKvoC9oWJ8zTrQIcMaXFz4uBJstynFkcgxH+JpDZf4rhO49mC4NB/lFRzvePLb9LSd TUq2laVLJn2kL4Jy18Ayssr28yoA7XO7Lq4IC92cJjvMDSQxlC2Yxgojdq8q0gAzw3gKPsNN GoKkYZovxOrS9Xy/5AWLvmjYPX7KilWl8RGLYlql/NPWL4UL4O7YrgcxP24nsrlk5Nd3qcVH f1Q8hmTRDCIpLJkNZl+I8fMUrdn5aO9Ogiw3KIgrEGcB8mVh9wvfFAUv1zqvsFEU+N4fS3Bw RHs0pLj40ob0cD2tFzrzMlpDJYgvLq8YHVvp/BgSeELfFqBnS2mHGzljlK0ZpifdycBEGLQH dInhNSQnFBOVnpEA8XW6RxaKzsLrNo4roct2KwJpE1D9JKFoMCuR9IGZY+YiWm8U5Me18E2l wz9Mt878jzoLOCk9H/E806ivfhZl482AMLvOepuOpUuDSn3U/uZYyCWnMyfLw+XgXVWIdsmq wnyutIZmhVZSlBzUq+onFKdp8z8mxj9tbkGQni2vsqbjTp2slcnyiMRXmNrTQdbN4oOBc9eR w91lL9hZeIoT3cWAykmH032ObCc0mLHl6XGYuPZUOCToCutxmkDY+HJYemXwAvwB0pfa1DXC XhaalpxUYgOZ/aZGxV70DMjIE8dufbTBzxjvfL8/BzmcdGKGkYuFFF74/jenXrGEOZIZUR8n 4Uhq5CZNoVeHBECIUjkr3zxG58xSluF8sz9Y7LTZ6KvTvW+GGECIqQ11R8GIxlQMUqkvmWYZ nr8m3yvWqXzI69+TEmSEaZgAK8NyRK6IiuVCuIKXCpZuggJ1hct3m+0Jb0GmmBehR4kzHAJN 79YB015Bs0E7AtZ34RKdsb3Zaci4UZOptX00T7tjKH412+Tp1NDEJnZMawHFT2hbAT2PBVEu nDfdFgl12HCO8WSw4p1saS4uAWqIumQ+NkiIv/bPz+W542JpvmVAYWq5QBiF0K4nJ/6Gu6zh AcpaI7Z/LCHGaOhwboDmU/K0DucbZb2QU+bLl0ZdogXVZfVtSo7ZtM1jmLttxSuRB3Cu9Jcd VmiGF5Rprkfl7ifu4MnVPCQrRM87jm0NFnRghLQORO0tgI7sdV4URr0eqXcxYOhX7azMPjDU l7AtMglH802KhUyk8lT0CfgpOsC/aKqttSgdwUq8l99938hJOzFaOiBvZDfe6vD3a+OxawuH PpG1FZ4z9QXtxOPTosXUoqD606SkF/fNyMwieVOjuzZEPXzuV5tpP0DYW06ZLXx6JVF8oU1Y z9+7/Mcy1TZ5C+pzexlSrkfuzjhfG6Nx2sYD0gtrbIUkoAk7BFRbhJJPz65lk1vLAYJRioP6 +P1Mbu7ycSHlltfk/uUPagvGGU2tkuvyvfQvONRaGLcvRqggKeu7gKKEVtH4KBnac1/gA/1X nhUd3B+bBQo8Z9UDj7PbR/LoHL6QAShvSjfHctUb1L+Yz232xZUmpGhCpzrdxTXit9pNHkZD BzrUfVFER/8eqJAfu4E4c5TBmhQstYi0lj4v7h7DezwyCFZZmC3YvV2vIhIKvEZl0x9ErIye 0NzKpnXSPEJCGzT0EwGXGBZ6p+blXj1/QNAPOqjnPhslcT1y+ZqpdKS6DzPnH3VjdASxX/xi fKClqQwh054F5qn9pC99BoueJBlSrUjYkWhI3yyp4zmWVfMJF4H8qWKLlE9fakrLIpedq96y /VTpRKQOtvwGSD6+ySDZbf7GD8KgHW6oFu/LQMyk6viBXyw/pLWDhX7Jt5RyYv/2n6nP6vY5 BZCGOOUBS2UK2xaJKkMTI3SIjd6ziWjFGEQClUFb3B0XNJ/hWck3O4Z4N/hPE76JE/skkYPQ B9ZMUOYY4e8PVCnxvp+k0onNxX31TJaXy5unhThB21h3FsLrnjWQaTaltAodZiyR+duuPdk1 QHV3TLmPx7zoifjinrBFZS0QyvSbUT88gv9nPXBSRsH7ZSt8DRoBkWaTviWQr9CRbNtg9BRi GOlT2ksKSkWXMsiUYeOPeOEvy97db33j97Yr979zr4mr3U5jsSUoC8Zs2joLUtpzSnsp6x45 /eWS2XdG4HCDPjvo/RgcID7H2VLVyOZWSi6eOwfJvK+tIYGwORr19hOlSGYcGKBxOsWATyHa 6BeCwFFN4o+PZoQuonJ2jP3Fo1CpxJQkSZEBZL6esEB/mEXZrZ+WhDSHzdZgHpWLkP+0nXnL 07qqgwbuLymLS+otlwOzOH/937nVNmkN+JnH+gGcReTrpZmw7/cQCQM6lY+wCT5IPNyWRRsK 9zDPqMIoVBqiFAY3l9cbD78urb0UEeYaWQlg7GRJn6dhL5vs5U/dRK1gCRNFcYZ4prXGCqNT bQeIkAIl7o2vU/fQ4uLqv1i8db7NfPbxkWhvbzKK8A4WmfGcfGeucXi7l6bOBC0cv7elZKiy OnrDripg/BBhwr1KtQofQA1H+K/n2f6Bg+4wG00FdtsFC5+q9NvdBCTR17zlSNNW8Bjtpi/A 6k8U/Wt4mughK2GMIs+LzCj+pHeQSztN/fMXmP++ZZJeQux9uavt2wHaj/P4nlcz/8eFdsHg CqBaPikD0/N3NHwcO0b4gKyfBK9s3cwUw7zGAFv33XEBKGiX2edPGUzN8/6KK01n93f7w43K EWRX/nFeCOusVG7tmj/4Gt/VAQc1yR6ofGbQ2CE7Ixkf+1dQfW9kTgG5xUUBaTeRV2fqEtFc VTaQzlwShX3ENMkrwqw04+tVsP9WNjarnUUtp3NHvW+QcPKTQ6dQ4U5RvfBLgFfFdJnM8TBs /ph59odN4ZpwpWB5GSDsqIfO0skmyKudTKYisGf57dXuHOeSStrl7k6Fe1zIT2s00D6rIwom 1AGoVbjOoeqFDYvZ9ZzUpg3WvU2xbjlBKwDN6vLiU2qgmKgtwCkNQGAJZ1WSoEkDhHFh2amP 5DnInNvBPUInfVqZJgtPn3XA4Wk/ki1v3xbLrwZX6S7PXLOyKqn35Dt+xQwCD2NJeuJ+PAiE rzwTwKjdAMEwx+GvR8wbxhjGZcD/4meMoyxnKrtCb7bBL/HA1oMoRPctdYNuOYdYlHEf5mzF oY1M6pAaad3L95gUXS6gPayiAIikAyYkOi0RG0V1S1uTAkYPDljMWg+eZ4Ocd3n/r7BHaaRt KmE9WW7+r5OXjzEBWBF/qnviIfTx8ru/0aoU6ie3Xo2e+HIG4OisZ1JFSnCrkOZIYqZqofQm 2eAV85RbHVonTzRXVurjreE8eXGFT4Uh65PdvT9b2a+IKpTYr3JynAao/UHvYxygYC1AREnO WjA1e0QqVpRXsA2+F1nqqPrxyCD6wdhU1XMlNFnWMhI1w0N3f5tXEfKJJXNd7hbdB46JElLg TjlVUhosozHAJcaYngAfGIvWwgcc0ZOuof7Z/4YHRzq4HkGMyAVYvSJplQH/NmGzHYkKMGRn 7UXkQsMp/uGt/mwXnJFvbOMe9KS6LznbMrBK5Op9Ey2ZAMI0kbz0g0UIsr5gtEFarCTwzIGp n85TxEdEjzUOvEBXnYBo3oclZf6KVdjE9y7JrjHd1f83FH4JohB4KLPgEws4DNN745Q+q98L aq/5h7WNG613yrzVTLfrvGSpuWpdmqB1vqRkRxaBMhUiRjiVmBYZrdSWnoXWfS2UNXuWoSsi ZPyVa9l17Y4mQVYismjo+G5pkMu+9uSG5/S7FB8oYthQ851NgPmT75X87mlBIzc8GWssKxmq tRLmq8yJ7hQv6IW8yY+puKl7ENgyE8Y9m6GAA3kPvpdsiyjAXb3WqBZoh5G6/Zv1yQL/j7Yt mPxxRB7Cw5t0d3opTYTAatftXG39KWy4L2nmlK/I6mCpi6LfWQfOob7//F5C1iJiVLJbpt97 VFbIgO9oXgnNjJ+gJ3mVGkhh7Q0Vpv/Ffx5Qfg/qnDWH7szzOPpW+bBP3MNOABM6nxgmq6sv 212UWK76wtsqPGY5s6HD0FIbP3rLZ7kyRsWh9fD/7sfyFQTEpext89NXB6wThQ/dC8qK69TG cFEZhw2iI8z/4XdZ62bYb+b1lOaJlSj5SKqSfE/onpBYT0p82n2EaPTROXatpOGySjVyP4sw 3nI8KuRCLDhVwG1/djOY5M8nStjw7ot1kYcwfWrRlNFoAVGAESVYcT6NZXv6FKVcbGgwYZX4 qXv/o+Uvzmf0B8zREtzLouFih5q+R8lgOvHyIRZF8KHnk6pd6nyeUYabjegztrBVzpoDEoAP 3AjtF5F/dNDYCPLj7bwTQmw4yhIxs0p6xGW0aDF/pJfHNtoJhWrsMAA4gGWZlwM3kLC7rh1+ TTuLY2S3qWdV8Auw1u7wuE/dSrjDFT2Ew7a3omLSsd1XpRBikiqbuCfjl6Yj1iOrz/IdtZsE IvqvZrWeIn85cJWa/jX8gNZMocOROQQ28Ajzk5rbQ5UjX2yWMFVGIPQbxvgv3xp5I75p11TQ YPlzmFq8gq0gcoYbEDQBO0YXCIalBqwwNbXkl0rgj5vXJC1o4c0E/kIS1DCBq9LYn00RA1BN P/lJt/sDGLmerTXKRgnk+eSsw6lCOJTlAGGgR3ZjIXNyUV86vJ5DDr3Yn0KeyPO7RZ6m0eIq YFqGICEA/G0zcUh04BQ1Hae93MxAgXe599z12d3/pC0XVcpZn65olo59R2JGI1jldiwlKZEf Uw+pIU7WQJFKwIQ9SE6KJpvCnq8QExR34sgoyYPXY2m5y/QoBOg1vpD9ymxRTEHXVQlRoulF VSKyV0Z6bLL0uK7IMiUArlffC+79V2AooOBOwAIBtGXUpA4o3s+2R9/012wGa5EGGl5t8nTz B7dOHiC7BS4Jfs8zCYafxv/8gE1mnzKJG7abdjB+qgDT0FtEknEG3aMjBQZcaWqaPkv65FTL zQLZscu7Lj92mqL0NZUlSB2Wg8HfqwJN7EH52DKr6z1LymT6VGhZZcFkMEBMDhmH6C0kkxlM gXivLgPZDi3rSIjpGUh1ZnOjcSUSqVJnE++I9OFpJt//RL2UbxSTfTvD2VmS3ei99cad5kky 0zz+fi+97yESlpP+gDL4splvlCx/BkYLN5gTj+YttHmrt0/gEZYNBmhpmS4QNvq4iq11mNyF jTYjG6fCw4g078N4Cdt6Or3H4ELkrvn6O/iPSlKFFi4IqF+2HbLcSxKPzHhRptHb4OuvEkWc XMVKv0DLx0vt+g59pC2HWqL/rG8bKmtC+bzcf6R53HTTa6RDHDOoZyhFlD/dl215Q9BTdwjk H8rI1MtjWbNlaJuHk3YzqiIin+BSfwyU5HIBCv4GSoOqM1qMLRuu6if8CIU1OJwNx+ufPqST k24cqJaifdxpwcD1BnPdK2Y4NRu0Eylnbfq105FahTiBtqlkyJntBUTyZUypSVs1OGal4Lhw 6Njzssy0ts4v5tXJeVkNuS025lp5Gdz/ZOLFhmn2LPoxHef+1in7oMrA8tPcxRkRmHQOFXtv Q2MceATlpLHt8AFo5c/q/E48u6WKpBBJV0/qu68Y29Dm8bZeFtWvs+ugebWP04vYaq48laGS BN0MVAR1YXTIPSrMJKeuddGXi5SxDX3znLrejg26fwI8rn0NYRoYPFeR6lUgoeCRGLO4tarA Qc+DDHJqvvyD+mcQv0TY874ZByUpYjniOe0xtSeQiTFUU73jVHFH9KGEAvcKdkOL3TyIJVoU K3NAffLZf2pbbPWPSc6X7AwjuOIOyXPvxunxy2m8ameSZS3UylpQy4WrQtZxrIK3mbD7m9tv So1HcqIwNn28CZ2PbZY6hVVfZcsDsrK6ZwVanZ+dffIEPgE1EVi7TP/Pjas6iswD2r9+yhlA W7DFf8yGfbQVxzH3A/Yfz1kOwMTmE3KDeT3irQ1qDG7jqVToQfktXUJ03dHOHrO87Z8RrXyU iNZi0P1/BMQyqSf90TknfcgxAAJiQMaUHHFbGC4jRoQ641J978AH3T/1GjjjYv/JubO8RmRs sv7tA96RNiero7xyu3tg/LC0ndTE1Z68035wkH8STBGDFEh9awm6z5NyAIUXybnUOvh3HkEN 5pB3UxywiGngltLJNKaKdIUWskn3IBS6mKZPDqYf6WJLaY84HglW5qz4+jYTQjLBYb8Y1Rwc oh9rFFEcPpoC85iqYNFBVmggVftuB0kc1e0XuVrW+7H3TZ1EE58gYOCW4B0K72OMNFPteEFk aqaAMBeXYPU1UCcYZxM33gn+iWC4khYCF5eFNQpUKK8/0RRXidNGHRZ4JMxCr1YkiByNF0C2 X3WSj/sE1z4jptSD4UShGFHyzmf3nb87TNtKNUeV8wBAjl2s/ezDHT02suRJvWQJ6e6GpN0h kWZiaQIKZRA3ca23sVoFlu5p//QziqPFgEhyNvOjakvkeNaNpiVaHAWXnanHml6dCgJKsKH2 tbw8LDafEVXIUuid8q0bGTubI5HlBtU5AWqCcZPY+hORhoyYIwc3FLIE7QPiwt0AimUL8Lbp FpIdQdJ6HF1kM9dRd15JkeTd7vU9sak2ZOsUaoISgMHFK6Krn5nwvC+d9zmY5CwVVv3RD9b2 37rDfYwIWkFu5zN4iPxTlK9407pV/euXeI547Ctj5rBbga7o2nJtJh8WMK6487GLu6CQzpaV AMMQNAbAsi4JyknkJPP5mQGfUS88uWSy9NXBUUIYKSLNapDKzkHdMGKzpzWgMDsoMSxjJW4g vwwhtqT4qsh1VT0nQCfiVZvxckiVhKu3MszzR1oEGQXYohNy5aYSzxwN1s+1VArJkpC6+KQO u/dUUqEEnQ4svTC9+Mq9yWM5c9DVaJQCx8hc/6rzadFq03In7gPkZdZui6XTSbwr6zbDDzcF MyNbsVEj/IsYCITZfsj1uTcHFwQIyQ3HF/vYwQjCYg/yB1RiyXkChCdltsaTw/T3HNfY7r1N hWXGhHo3ZbMGdRe4Ua6v67q11e6axjlgBgQBAzQjuDyT93cFOVS6lBQjec9pTnPkPqELZkWf Jd+y5CplroMmtvFv6exj4HtMlGjyyE/sbrEmRWE2kcoo1wLsEYNJsndeCuMHZkshBvljJiPw OSd7V4dUKoIgy9UpOgDdYAtQnJQKb304+aKd7/T1DGQmSmU0Td0pCuu3nKJUofIajTtZGeKv TIq/RMdu53yPTfg75b2dg4fzDB/ETpM5x7mu3k85W8plsPks1REqDVLn8P7VrbQ+svTrk4Bg 5Xg8cut1wqRpemCPdbVudRYIimniTwdz2yRxe/ydXWJ/J7Dtp/7NatECttj7QSBnc/bBUS3+ WmGT0Mo4MVN+4NMr9nLeRzt1y+n8enSGnvjpRIpZgWdKM6zGN6to5sxX75X3NplXEl3gpE7u Gu+X6CfMpXbjjt5mh7vMMswv8P1XT7E5mba8ACEikSdRVxrMzz5qenM42BkyasReWKN+jeFG sWDY6Hen9oz7GcTWXsZhPEqbOlb5DmqcO8GWIzduNJswogUml3fOGF8NerWM3Eesecg1emdI +/h13j8qNdzD0pBEd0ivr6sGtcbnKXcWx4jDqV1KpBWT0U03+uXZxU6/rjnICuDY5Nd8s//W JNVQTp8X9b2lwYf+xiilLqb//ZpJwmtUQp9iZLk1BneP4C9IwQtXztY5mIFGm2ALWEa2AMzq Bw3r7F8m3cAalauthz87WaNXARX0E+4zj7cODYuBHv6VqfrTCKKNqeZzWJZAc88ittuvkrk+ vRofMRWxRHHQ3+iVCZR01kWvKn+4ADPLUV7HwpAFsKUASco0WyXJk677lIFBSyAT3Zi8zIgD KBJ3raDsdyDvyQAMXfdtb1NVkYfcJAaDew9TmHIdBTQEm2SBYHH9k08/kb/N/xdDx6q0y3OS 4q10mKmj1tzo9Xt43ryPSG/R9zx0Q5aBZZdghzh2cVMaml7/vjsDAjLKO3GaK+icZkMLP75k Hicei0pLXiXUtDJ2Olk+ilp5lCHYBx9XUr2BN/OFzCED8l0uQZHtK1A7ImIY2sL+ZWT5GgkH t7LwQaeDnSc/nDC+S8jhWqLYXy8EvREjDZL1w/vGQf2M3Adb3KVnyusqZcFN2Zt8h08yCM2y tX9P6BD7eYXBVl4zLr4B3SfzpZNPXrkz++PF5EirbV7w+TZY1cTyuFN/3cK/ViITGG3v+CJE dJyCVxLAlp4HpjrU2OACm3V/ct6/NKB8Xce3rV4uKVQreb9zHKr+PNL2a6cDHJehFY+eEfiR l5n12sm96tqmDCddNpA8eFuS3csF1bjV8rjV2xzwIifOUo50QiTnhWOUnOXaDQ9j2axMrcrs Bl5cnTzrqlO00hvix5nL8bYvH2lVce49NOGGz8HPHOwbHAbrcXRGnAutsaXYe9InR+y5I8JP YzZx0H+ni766wBk1WK1CtXNkor/2bvIOvw/RVx3FuLvysGjXpJR+CIZFvle5ywSa+b7yzyBb loVYAXG5yRkAbTNTjTu8tJi6jubJjtzrtWzpuB5nwcmKkvHYyUuulYp9zq9wSsXDM7zZZyvj kWuBFjGuKLg2uW93ms/cCDyk7AolPGUJdaL6ByVccAD/KXkvUaYIdnxd1XtzwVq/dTRi/pHY smefJx5+q83/WSSs/0EGBkF0yfGMkeF9SPbZXQ2fFZHchX8gbxVsPb/aJJnzDQeQzebxPIDt D72yXxb6h5mfAOjJ2WaYjmzV4U4Kv1zyU/JB6dPhAthGx6neHy7ih52HkDoNx3dw09aYq1vk 9oqgtGfhsTDX84SC15aou6KzXZUaqL4e96oZM7LpReQ8QOTR37VkAxOf6ViQ0AUOOUqbUPbU FfwYweEF0U9g6y3FBuJbFxaanxMaS4nnAW/pSRVaLfYNxfHDKqj0DsekarGkoiZoFsCHqR1r mgwJPMOwlgZI79qdmcPwV9RvRuaba66TjVKLMWIoqi76Gy6tVsv9jzf9sxQbOluQ70PJhPa9 fZrC9TTEj6nl/zCar3I6CICnIy9aKYNje905tQtFo6qDSHWuFSiwCFK8cREtYH0kf5A0IE1B yDORDUODMnO+HCYPfE2OoEnCsnI94PXwzK7CIQmo/bPZz2FOJNJXKIKPBzuMoT1IzXw+3kk+ SN+HATJwo+gpxgS1c7odxMDjjpPfqQidFK7evFQmGXKwCaadCja2EeaNKFNJSTgo8fh0F0RF 463h+PFNuMEvETz/YrH4Ipc/2RLMlnKbZ4leoZsUcXUs1Up1AtYZ3pbJs0DkfW1BdtAHaB7Y mIaS6ldYi8vlXpdjNq/ZZBcfKMFWd5L/XDR0gSy0Wz8Q2pnV0p+oRYQ3jwkpR+NgAu+isR6P m276vfO0f8KpaOX3D97z3eVWBPm7RDG2n8FM54iKniLgb3b++oWW6bYArTY6dvTZN9vEHlLc BDqlL1NQnkWB107jSX/01Z/Gg2Qn6MksVwQ0WQzmR3yp1W9BLtk9kaX4nW8jh3YQP5eQ4jlG VNso2F6Y/T/7eZkxM8ZHiGLmBsZBkwQ0yWPns2Y4ZXAgFQE+EzuBQBdDmNO/crmf1axNly9v OzD7k0TC9LkDjxVL0Robz6C17Ii8/SNTh70v4hLuTpvIdj8BIXvB4oYyqOyGs15lq7eoSMcE gRccyLN0hYNA77XKr/4hJfjwqin77r9JCNuF0nHTYPY6uPbRSGicbzJQ+f9V4l7Fcrws3aig h9S9KoHM3pPqjBwvc8sekT1/eJhMOmTQ4S9MN0P2s88YYIlwf+3WQ+vvaxpTZnFqtsXlsDg4 7pY6kBcmQ7GVr59n1rAxz6RPYmikChC1Ou2tmszkqFYPYRxBAqxQ7SdJwJYQhR4jDPgOYEVM YKHDp9WcrBahHg6UXY9xIU4UwfLQn5mdWMMxer93MjnYybZy35aSk1eun1i7dhqbQIPQiSla 93BJN/aCbnsPd9gQZqSxjEtd1dXqhUQsfJGU9TEj4DIpo2/DSUqcTlAE5eIfbzCL8XIjvuoP TRnnGrXoszoCuWjSmtskrch7SBp4ocm4SDtTW/51I5noJqO5ijpjnG/WabLRIblUVB195+R7 6nkH1a+I1nXha6SZjmFH1VXcyja66r6d9NzXy/pM7tuWqBU/MLhBI0Pi+ljAqvjyOnJxP/nC LVM/qIElKhdhkDMS2RJmFN6wAuvM0aY/dNyMs8woATFcoD/sx9mv/Y1iVwDtvIBVvSVpWdQI ts7duobYjIA17yfp8ZWaEkPoq7MpQZH4kJbCXYynFKQRl87KSuPnzpzTF4Iv9CzatiYThJsf 3QfwEPx4c6+Bv38iF11ya9xqJO7pG0looss0VfEvJ/noCEPO8P6gXGrS1rjLOzeQDAb4mp7d LWupdA9U5czFo3k6LmoV02zlDbCtaUAGZ92n5w6RQuLQgW1zr/DxZx6K/nrP8rS7E1AVdSyn doUTEBCu8v2I/BEMPwgnRn119OCHO4dPGejHWM8J07oMCWZPxjRCVXzcx79Xx4pcjD0+Un5o x19Mb0WuUC91LcvH+HGtgzKf2as9z64akEBm69q9M3gNsUojl6eMXA/nF/UYjvkh3Rqz3ToD EuMjSmM3nVU2Rb1Kw5kh1bz552N95A7uuMzABWSOIU3dKVKNkx8K0ItHcswfTbmGxTjRtSbs Pzbhf7yEN/S2EmlxYn7raVrf679D9SDWXIjEVDtlFE5H7n7WZRQ/ErKD4rMjKurxvjtHzq57 +SJa+H12sboukUbwvgkxUWbQH+mYBtZFDJhQKFfdM71ncIO1n5CwMJ8d3Ycdgtjlj+J07Wb+ /2QOFKcEqDvDFtquv9HTKh+GgssFzna8/YeCODATGmKtL3ky6aM4x2yQHT4BIJQH0UILAOLm l9LCasvOM5EJ+BIE/YpMdwqux+Lot1kcXLPlrldD6PdbHTSkLPHvn6ygxO0gf9L63Auu3o3l Pzhaiq8kAQZLX4voaEUB6yHru+jxbcnvEqIUxQc9ScuErnehpAjK8AnRDbp+mSlQXnJ/tQl4 sDqCCuWI1uKZ4woxxI/E7yoCRxTtMIMHmR3RGa6XOXS+Qd8V90tCJY68fErbYoWeytav9+lH 8lGkD9Dcb0dyFXQFE/+URB6KQ6B07YepqBqzdJ5j6WN4TgEYo9lB3bIy7fhetDx/axMcHoFC HEsYGDWA2pnAqD20aiV+Tm5z80+oqtztGVHdEMs36dg5GygXjq7sMHUVeXn9tMsIEGPI7Kqd LnqRiF+Bl3V0A0MJBAVT5d8PfFkWc5jZvQOia2drCuI1Ul6dWHwvCB/34DRY/P8l7/eyDh4z stLd4GUYBreTEr/jEHMSn5io+Sp3zsX8DHp200G3smMvzLFpiZ2Z8m5BanF2k1LskX/TfUbx WUUNQGh1Sh5x/do40JF6GXCzVZsZ5xi4E+sdsMIa3SiCWrssOTrGwdRFAk70Jq1w9AWZhuhP F/PaNRssm4y09LvTMrDH/YRQVz+j3dAGavcpM0eGYhaZsLJotJymAfuuhbR91HdwM6O8rZUj tFOVyRYdpU9gt0XsufauO16+vvqS8bEC+d7M2EA7kFmgIlp4DcUrxuUds9+NfVn+uR5Z0lVI UIzhB96h+WjH2JT5smH+A6u8HN9IMCHboaDd4wSdqKWndmtpm6kOFxnaJAXfy3KL9a67dO4Y a0T476q0fPUj5fnK1e/KDxBbRxUR+LaI91finDqwoXJNqrTUojluUJ/p6vnyJx0NsIdB9nuD a3/dVtP0i8HFEMKc2aIV+X1jUj4JBaDH1+wrjr0TffehhWMCDsuC7n53JmqjNAi6xEuUpyjz UqDuaVpvpjFw1jft1ZBzjG7R35Ptf2u0IjifMqvhNIH35pahVtrXVGIvBTdrjGmGzaJ9aty9 oxh1hf/9ANyHKBRF22ERuQxrqya0SD4Blzwd/ka6T7gy+3ELvYm9yHYmk8EhB4anOZMgo12f OlvbEkSd40IdHqUcRS9LyVER2D70YqN+bAECucqdC9uqQAlaU5w0c4v6HS0u9LWDXh+Y02jo qMyXH90Gm+9eO6Wnw3/dQIIfuIUlM/01DNaWyWrN/qyT5ihhDFhb/ZGPqFFbp+xnmpBfAm0N LMdC7yFl5PEh6E3LmwnI3m0rt0R49sPQ1MpEopO6f3KciQ//srmcoHr6QJxE1zF+NY7nk85s TCIMXZ62/HxIOFAQMfIUGml93V2dSz1I4qFFPQTqZnLj9Rcl5ESv3Wx+ZrkYcDSWx3jc5QNB srvtKrymx62lDIQaZ9BdR40wXjMwuQb6VYhA98dyxh+kRP6cT3UHfyjsLSIKqiUHL9csZkwl CPQ6DLW3XnZYiLcnrWY3Xq1BZ9+PRrfQsDNKSIuTv63avmfhEs2j59ZfHteircUdXAzvDtcg HG4ZxNtWsikfQTv7Rm9thSqSSJQKzs41DnJjIK70q4CNjN1VuoNVRGNurs4dM5UJC2AVKYcf IAmLIaN70FX+eyV5JFly8y+irsrJA74GlmVyVRSM+YstYaoIjvDElKCsUZqa5KdFvBOfuqj5 ZjYtrcTWi2Z9dY40j7yfXd7no47VxIJHm1b8DQR8dCzGXUIvJVmfo/nNTqirMnANjGAsmygO Hv6eFYhnKD3p1YpVGKW3y7Om+zKXf6wWxR4SnqaTz0VUBdUbJ7wKI/O89WujinTHhXEKmkn6 qT9hiP7f84vauotHXvUZYfPFJH5+XPBOUvchnL5nvnwuEjutv90glBxl8YnVdBcJ0CxRIHMT d+w6aM/lzvLBLYrU/l6hEvCqbX8V2VY06ey1IF89SHjczXKaOXL4bdhOjD2xKQU2peMEQ5tg aB3FOfbqh9dZlz1vKAwIbE8rFO9/ajIX2S+KJjKzJgsRQS3omoGpWUzQV1BseZjPET5JXnq6 jdhsswSTGQcRPkgRTVluhGQewFEq6uaEukIST9n3ic/XrkbnUj2/UlvZK1fwIZZKLZXfp3/h shuKVG+KXTj7x82DM1QooaxuFh21jYQpDTTUes6Niu9Qa5V0rQn4vo66IOQJFPvIx1xAkvT8 Bn8BkGGUAHXYTIGzzzLN1WeMxh1SX9cX0I1/h5X+baljDNHi0tWR8QZngYy5kp0eBq7Fesap kAL0EMNnZeJoP3IHa6o7QwpUys/gIrIQuiufeRpt6Dz1Ts5Y9eEythwWt5OkOhZtSQpj68zM V9/0tBOzMvoTjDNMoLJVf6p7L5GiAlqIahaVYnDv/0MZSeXYTam/L1+Rtlf8q57LlEqrDT7T ynW7ntfZTafdumzr9EYxscrgF71hTALkDmp7XbXtN6kKBdoeBqGW8LxU3jld+kP2eUz+XaRe QRL4JY+U+4Nq3wWq9DLO8SiaBDvmtveZ5H/mSYNxqZfrcvOH6GrWypAvTBiOSFobhllGobhV CnlBvsMyiATvz5sAmGhPgkVW8W21u8FhfAb/7tlJlodlfvBpoT1V8pV1nPUNWnG36sr5+nYg CcXRrPtdr3aTwySDvjLD+KeiQv6TkrF+l8D9rVyiehOXhtwBFqdBCEHmOBKLoS+kp19mBme2 i1P0yKwkY21VMtFXWULi5lpiTu4nMjB88KaMGuhdb+GGzCU0tn4XFwZ7djItccCr56+LrmDJ N+25OsGLd3zDjh6/zDyut95vFlY6lpOF5a7YkY218nAOMkEaYaoHNYYvujR695v8nItfUCNM cXp53B8Khv9sfFDCKEcomMA8gsdSDGYmPjkDyFKui03ICLMb11RDyBVc3loOB6rhOeGtIaFf TW9V/KO+uxdR7E1nVGzqZyyFYPzNFt6fzc5oIrK5Jmu/nxWCcN0SXQSOW6ALyHrjxH/3i4kd QiPg7sCvVDPN4YZek3GV5BljXIEMuxTdT8+5mEZ4VstrNv7HC27+lSAbf4yCxblJjfSYHMT/ dTbSm6hmBtlC1JDrUfLZQW+Vl+qdA9ZUQ/9rZLr30gZJ8RItobTnL55p3m6y68uRuquoejOh TVyESR4ZaWyEz4ZemZjALXWC50Vx1LpMOjCsYhnvuxBZaZ+ZIDkKCOygRoIj1qq9gFEceybS 9Aqtk3A1BDGr9MC6wSgW/NTKOdQOXSZ5Vtzhi1uFn5QJIIQ82bkXrbV1IRNYyYkMEGW1jozx TFcHBoACQLNz7nIEIg2nm1CSk/z3kRgwuzV6eLoVLaT7f3QfrdAgTnRKW63Ta9NxH2hdzL+T AaZKs9LXXiTSNaR6L+Z2Qc5XyjzAZiPhk7oTG08ygDSIT4ZBV3gDuSLG/J8BZQv/gWWCU96c 4Gy4yuR0sKCyZLJHuYZZwSzbrWJvozgRcclcX89woZ/MhLMivDziv8AHCabKuntgGMiDC9W/ ZFkthajd9DS4cH7thSi7ecGM5LbmhT8Fu9xTXn/gxzJ1RPT9t7ScJBsm5iSkSJU4J6VslduV 4cFL0ZHjKKzLuEuKsHGhzH4YhLoybbw2knv/UvXD8F565iwd8ojwM31t6EduGH9R7VWqX90f o04pmg9aIjMHaIQG9kKkzETvayOC0pxBpmmhhUn7pVwCu1hJi1yeygi6kD0BkY2Lw6FWQQYx 3YBTPu12bD+JitFG2fYcXcWL2J4g2lgWtzTFUd2rIRlgvummKQy/wA432a/G7edbMWBQx1Fg +7nB2OPozPfI5jtdeTEP5zRaIwjvIda8KeKYqb0VgV6iY5eHIfmT0Kq2lp6lhHvgrcCNs68f LEGtL8Rgs0Qfa2MLty7eKF+lu4drp8jQ07eCnt59VbL4bNdYLKpEfdbbs4ojjUUsScLpDmaE JcUKsgXNpSs5so5DoLa0vYF/4WFPn83QDr8S+p/CVAzC3TcQNyXecluhwOzNf48syM35kwqh B50AO+rvdzRWCC/BQkQMiL84AGcJBf5R0g19V1kdC4MHlp86udlXBBCpqGGAkL7QHzi3D1Q0 RMszUcY1I9tNEpFweUbJnrDEo5gYDwOT6InPdNgsXJMmEiRofqogSu4aYCWXIOUs/+rXUpZ4 2NdBSEIfaKQ++UoAfBhwe68L1r8rFENddBgWp0cfmD1ef4QerQlaOTWvP2vKn+1YP9+VPgkq +8vy+ZMKgj6sFJMINBB8GY0fI/1ufAPZ9PLWGn0QLiiMVKUeNuhsCplbRwCzpJ78XfViK66S uzENHF9gZ+hSOy9Oc+IsobSPuTKBaZhXpOEm10m3LnKzepgMM6idHo0s0Lh7ra125bawQOIW tFq8WBvcpKwdUmyjeZNG7jEG/SDAIzRYVDyRzoHktmpseZWBCUkz1ZOq7Sc86sqN+/TVbv6Y nPz/IdWR18EhxUH/Wv4lgsrKy6AZbDFEje0XhojsYXvWTrga2+xyBsBSWGhgnYopp/38Fs0x HitHWJQQrmOqQA1cDQueC/MfIZ2oxRpqrgcejy/Z1FpPWmzZQTe/Sob6vwwG3LiN/9mYLhvZ JJJ3xbkkU5N1AnfwuTczXMu56ic3RR8tNgOzXJtNC/pPHCjr+tKMxHGEDU1BLb/tcSiVTyDZ Kp1fu8XOgY4MuniORPhIs5JfHn03bjLrRzWINysllxVUxj9OERK9dZFfBDta6DW7g81oEBjO 6092F3HC8HECMVOg46ebjwNAvvRaKg+8ghmFkcKa+gKJC3wCycGKmOCZwSz7shDf65SP5BUa 8bMR40NO8JhQ4BFUvMbw2TlpnY6Bs3nb0St/kEJzhwWf2uzg4FwSpKb6IvYYz4/t/l1LqGTq WHtOZMaXykThEI+E9bK9T8iJL2/tCI7UOAk3U2fwtO5o0jSOylt4cpgwz8EJiVtVACpm27Ll weozCVIRHoTvvet+L2HVvgD3viSfhcz35cO3iiW48/rhAM+omuSHLXtDfEv9dz9MpITuprSy W+1evLQwtn8De3kjntWgs6EnzlZbwbgnv0vfYlq9QPgFlBzePMuob9QFgmhzDTyQxG6rMCfC jpFXXaiYl9r9kQ/UPGfMX9rHgK9dm/ijhCNRijNzniU7JX94T/gsB8VStk65dCEB0nRpsuf3 J+PoCSuCNRWzGhIlybq3K0kWcXVN0aYZhY8XHNWhQY2Q/rq1mGlfTeL2EfX91nqS5ek1Zinx CwghXIjutjhWvijIIxtNAvbxM0VgHHmeqzokB1YvuTmDXMGaLmTI645yusxjLpSwk/0qDP5+ 0ReVbzNhPtGQBG4BfULOkRm7Y3uGiCYj03Av/7e38iSSZfKjLlafPZlff1grmMGIIfVndS4Z V7x736sT8teWvsmfg5fKVQOvYKd7lngqJnfHdOkjhygGKikeI3XccCvqW7kz74rCAcASU+E6 lHs7V2qBJEGM2OqoRxYgJ2FGOtOhiybkBqq/OI20zHETn5RCaLI0U+oQjR5WndRXns1/jiPL jIs0wLJ+Yl4QHm5S3A47sIpc9zcbkkm6PzhjfgV9XZEoOrYS3ACjAp18QLaW5qhBmBHUYr/3 Qjub3nltvLgEXRrYtnczrTTngTFHeiL9ASHK9f7dCuez0NGfDT2FuaOZkekx7df6j7AB9PAG F/0VRrEjTF4wFuNpqSVdDJ2+Rw2u76hpXTHLQzCUyCxTsLcSixFpgPZiRXy0WzwZBFwRAMv7 fSWLTB2o8Lzq4siUNP3ILSYR1YT5ddG0x2HcJdcdCoZ2vgCy9KH4OxtlZKc9w2wgBHZa+5KC fDdUl3nzka312BzdY3hqiudh8sAJLhBc5ZMFOQi6xAgVqS0BuplGSrKdj7jmQU5B7Nk4jcsl owh/ZJsXK36NyP+C8lu0C2OeG3CD0umgxvGpSuFr2hyv+L4VRbMMEzK4sbVff30dv57dUjyx Auv/LqzQlLlA+GJ+0WR61F8ieh6NXkjQcK67B6V+VTc9VrPOY90jpwdZBFsxtifNeUNmtucy froJiZsmfpPPbWyntg/pmEvhbHZXQuEh068macTVjoQrkth8Y4VYGIumvZWHfmN7yB1WVlKO 82FCcSbnRVAQTl8DudITlQdZNj/WNprmWy2S4c9VaIJlTsEexIsu6nQE2XmUnIOdDC4pStM9 gXFoinIUNLBunqVZiAgiX17+E3sO0cQNAebot+nZIGr8Qc2DXYEe1AuMqC0zqFUbOJZVdylp /DxqcIFJJOHB6/tTNV1WX3i8TEqsEC/DkNzBlQM3T6w3oFMcB8P67fz25JJVK/LU4XodU2m1 aJX/KRQPzdP1m5DgPyffyBNCRUDRHIK2LEFPRuHVw5cnK8bAB+SXB5koGkMHEU3qfhPUdZzC ETOgHhhMuAKZgrT1GRp59fYFeABB5vipjenY3Wue6cT1hvE35lpdOf6YMu0vqTVoq/wnyJZ1 iGiHIfzS5biIzume1bsmvoOwIxJXJl2SqnnWx9dTxPK0f2caaFh1TIiXwfnUBGw6Yu1UBk9z sreqbuBUVzAuUpcF9Fco6vckorLll6iyuKFPU/6bFUnSzjRRO23LiisEWGjKHuR6/HJZZ1A3 rP4Aa14Ald4dRZ86R/UXfnozednnPkk6vKIweg92HHwoFcBvdedftaRW5QX/mZs0Vc2HubS4 dk605WgyYwAVzsj+2ZtVGLYt+UhZFwNNjH/p6kjGhF0D10DmrfZTJIFy6lWSiQfDwxojy5aC xvJHmQ4w6HIwFp+NZz7nD+/XfPkl2XoOQnTs2/Tc51JZBADi/8EAVzdii28l8ZcF6pE73Ok+ MzajrjFPzCJHVLP7ez/jqkqocxMmdzeE+VKvvnN1klKfYjDreDJ1O/4NcQdqmsc1isNUx890 wGga6IpMNKvCSdrSP+YkdwIzVQE1pCcYVaePjFzUOKvaRgx9inySxYC/+KD5Z64/EglEwxJy hMdi+q7AuB0xdbvT8M/Pay+ZsLHpHLJOxYTE9ZcKAI+h3jB2g7nKR7zSrrEDC6egevTLy8Wr vQ1SW7pfIfV2iqJ9RFF0qc4DtD3L5ZvE3XEUhLQDUOUd17aFfN73RXW//XMyMHXvlh1TUDmM MMJdMgkH7AjSE5jSuIJaghMLDFG2Rk9M7yfpDgygkq+uS7WR95wjNYqezw8AkHriAlhMeCVT ceLdKaCUewTWlkGQaecLbkc7oOYgl59WmBtyOBwEgBb9CcqQgwF6SsBaDYOt9dGW4DweI9PY oNGmjrjwjcYM4gsyMMP7PGdTo8AWpqTy4pLzHhvnTcZ3+nUjGau+IED0mNZMHAxdNRnlKsE1 z83ROwlBL6n43u1F4l2A4ARoCpTjcWFQxNeW+0TynHznTRgiNry384mBJ61e8urVl4ERuF0s hLhF39s0qK6zmTRO3mmql/+OUgJkoNpHvlUon7ip4C0ngrelHHL6LkX1z3MHiK4C5UraD56j KxstwC2kohmJ4c3Rc0TCCPGLDawCKSG+0XGMeswclZWPi99vS9RTW7191RVvnZX/295w/Uec aKcqxuKny3Btq6lcrMPm5WF+AZarcf5d0seiqyrKQ7I+gAUa2J+GvNPrKSD/EchwLi7euVe7 AiYuqOj59qZXW87zHT75y6zxoIr1bsrxQEheVRzGtDL9Um8UjSqofvB5ViU5VkyHwl4oespp 92eMvu0+6pSD1z4rfNBq8AF/4K1UnSP4FPssmqtVMezQDnIxdpMNyhRVbYzII3SWM5K/IwUI JcpHItZJF2iq4JOnpYNdI5PrMQDiIzelg0YxdjYT3kN6/Fb4bKtyZGZX6nPLyPME6eHLpNMC cR/DZzIUKWah0CRENR5mC3xRzS8PSROp+9q+3LCTT5c/axh9QVU/hmM3TcRENlshW4OIp84c SbZUjPN0WZNqPz67cGk6CyEhLNYzIXhgAwaVqh0Qgyx3HJ8yfwNkLU37/DOZWhi/bLL3M0qJ cJrZjC9C0+xSz4eP/aMe0H8JLX3Naop7GJ91ti07saGXMmwlWOn14Ow+0I6SOQR5bhAdEANv L1lQiPGXrDG6s1sBVeUs+u8C8nva7M7IEJEPWUccfNV8r8ObTJyO1Li6F0Iu+dTt/tk06SjH avvyLeVSfzQ48zy82lmIZPyel1lBu/uu5/uhYv45lGTuz8K0yNnQszX5VlqA+vhz3UhcXNif a+pGba3SKAtdVdKDX2y4R/km3bJGnn1si0RjY9YggJFpwypqlWv6tDjXvDthcH6t627LBL5s 1fKlNJ2M1p9raPBxC6SgEJgtZ0/tLFvWWj2PcB682O5cTEXY/wQn0/9sb9U/ssSEHmhMYJCP Fx07hZPat6kpDQ8pQRQg7jMsATnMY84WYLebA7PR6tcbQZhAyoKLqSqLOIk+pnsH9P3rgM4S aTjNF7icaNhSlB9QkNxayl+lvTtiRB+BouBb+u+nVoiw5c2CdwXDeu01wvZLRpq7MUyfusSn eXa6FTxQvuMof9Yo8giarKKyLZ6N88z4Ue6V8pkSkk5wZ9p6QOu8VuQ4MAVLE58acb2duUHB g2VEU/ojwt0415iTMCbJtUVd3FZYiXCKU8k1oL7Mkgp3+nIWAC4qgK5MnvfqC/C419uP8Dar YkfGPKQLA8UYGHwzK4bp36auwj0dKYrJ+KHnODJeTpryxmki2pDeuG/SB+R7/AZdCzrw2SCY vBtCmugt6wQ720bc+CTPsccFX4DOgmRpTXkpq7D+CLFQPuCceMxFDf6JJz+2A29xTYl5XzJg NHNX723gbb+mEeVlgj0v992uxNYqRh43iBWELsofGRZBwm0tWZ0/qSjqEKXnibZn0/GSApTA ma29GOjRUcb6WKHXSp3QWnwsP6uoznMTj2Exd6WYq4/rg7WFHLmKjE0jVv/zN/TZeSKCXfqh XrQXLoSzCcP5CS3uKOIl2K0knG7pFtAPvSUPTTCTW7LyGHJj88nurW421Pd6eum1w4OR6DRZ CWA1WwRljyF1KfzH81z1j8ALWTrZfCZJ8ayzjkAheNKcQMh/77BYlES7HiGLn/eszZdvc2eR 6Buj/Cg/DAkz7drNuydpitYMZzMGijHWtjbSEknZyAKVbqRW1NS8GO7xaWU81fuaOaQgMAyM FgSsmkDqQl8rwxeMGoeQE5X3jwwuuZhbWV0+ZionAXzSY+hC4QNWEdCZRniCmKm5AqDQVbQq qvir7dYMica4hEHb9eK/iR06N9YvvHX/kI99qxzRje5dr0z0euDDkxkJMR+ET2hDsD6HH3As GNTT1hzV8kidkfqYA6SY3AKZZTsfKdKiJEs2ZXtIT2x+wfTX+beX1snh0+3RYIaHo81Ip3aN rb+wodMETutxUQlHFlyRFesNQOsxcf8DQkPP3bjou/Dy+gB13TvHSSEVQdK1xSU+uJPan70W N+CnEM/W06aqxMRKAr8KiT8/PPnmwVXI9FWTp5LvAoZDz5+B/4EDw4EvvZOaxnNMMs8JxJfc JtWz7T34qypcY1iAMUXdzNbRi4Cy2J9B6KOoYGag9iGWEaax4BfphGOWMH6ypGPjeMwzUaXp 3QpwHkq300prGTlyYLJ8tmp2jhXVdT7PrOrixVCEvs0J8JyjF+kaHFTeF9GWv8r5kTqAvhVp +Bf4dB8zpm1alHcmJPcVncDHsVVqL+grMUYkMVxuns7vJ5Rvr+YfQZpM9wEePcuy9xiVDyGH hqzlhz1HSGU8f6lvvM7W1bx9l96BrWjrCu38qyw4+wa/+Az75kUMMJVRQ8OB52tfv5cI1xUd qAGLFjjyVKYtPVPcmnS7kha41A6RkQBi+xz6qreTb5ZUgcqUO9ZDkpDRAPqA0xzKz5/AnK3o rgNq2l1SBleH+ps57z5cfvb3aIcPceFOXuWmwaPcp+/rlUwAtRuenWi31ljKnf1RVcIv18Vq qFAAtj2Vzn8WJB9vSZuA4n5wX539aDoAGInv/J2EIVx88V+tiwTGQF1ezPYFNLfMlwH/XTl1 7xOggynUpJO781l+Hg8SDEyMuBomnTpUT5il6q2SjbEec73lNubg+u0ZJrKp3O4sB1+R4x23 sHsq+r+TNO/MYz+u0uc1aJtpMcVRGGNyhVZODkzJreDBI3JOtF4zrWfEAChfxLBaH6/yhIZp iL//rE1ed16UdbYs4FQKMhZ6aqE7qHr78CvZa5UIVgcoSx23UPAzgjMu+/1E9v+gdUQ9UBO5 4rsPHjt8grLfa+/5jRU0qp4QkXC4EEt6UgxR/YDwyR+R/UgB3qajXVJ4p4ww626KoKN8RES4 d+ZFX01y/Z/yos/ifPTzs56+BQPetUpUu6EYN3u1xMfFES9GK3YDwMwZXmFk2+AOFkHp3jwN VcPi9kkrFh3pbxCzjS74h4W2Xxk8tQAcImK3rzOGRsUC7/85TSm3Z6xxNXXJ3bTXLrBUgQcq 9UAT2bkEOjxMEcUFhUDETuubbiiDOkP5YXyBRjQC4APCQ7hA/0/wco1aRCnjZTBrPPGyF0L/ RsCoaLiUsSnLtpggU9ld5XRYA5n23P8pyOBP8nK1s+AQNz2dzafUqsnlppO7iCj3h6f5snUE aH3m8gtipIuvgTsYF51izTw02HKQ9eafyXoZAp5Eah53dtOux6m9WpLCOSkVmdlKZjlF5Y5V piNzzMY8X8ln8ozBiJfaVfnjBDg2BqOkpB3B2nHcs9NSZoq6A1otENjxqHCNBqMH7KONUFr2 YGjuaTEBup0Va+GN7K9i50+x0WqciY40PlO2edCXR3+m8ViLtwRGFOS3IpPBVUAWhTBa8ZMB DpEEwvbCYHWT4HS81aHRkTQmHf8j3PyUXCVQAFCuX0bMrighyidvcN3qBVqfsvpegWKeCyYA UJBMJuwQ47RHbZrKkccIelaOV3iELpfeJMUl65wcj1X3X/1LOC6qNCiHuc2Z4p4lOTaK7GMd PsSHFpNUT7sdWYQbXp5J92iP8QbbcP4atbtSUzbYoqgkWHMMsVcNE+Xa4oC1skc6mU6H92ZV gC7NGh8fg4cj5a58hbQ832i8G2vJI3rWRu02cN617OXlDQ28wMGsYjpYk9QgoST3lAKisEq3 uef3BWemSIuOf4oyvr2+nyMmq1B4Nv1FZVboz1C5fTSllo/lwBmdcsgFtcB7mdAdObjA4nVs qOvO2p6scbjMdTg6y1ipOSDFNtcUrbcJ5vuYZWMe/ZxxgBtDBe227Ybnc8zkyAJEmOwi1S+V tnQcQFrIr08Tj9HfqqLAikRcUU5hSP+bsL6Zq3UQPgYNYbIa6SpN6fMH2BwZQXEX+/QQtdgX tgTzOs9dNB1KOUrUcaOOpIlMf+IDL+Q+cqZX6zdkaW0YElUvo/jZ/xShPxrm0n+31DmNVJKe ry9nNTcWLTVkHuU1yHigw8/NleAmbo+0WaRM9NqKj+d3a3IZMgXoEw/5VlzcOJaXYwm2LcXS IXI7ABCZpWD9GezHlnXtRxyYkK1/O3Wcg/5MaFbz+SmTXZFgjWCkiN0WDbf91rozTU3VwA3r GiXxcAyyHYqqoQKHtAbbBhUmmOFRDwEOYT+tdNh3pqr7MxFlrmuHRTQx7IVleaxzA7R8zOER 6LUHYM2rWdavDnjA5j62e9l75X+eGUbqxTYUvo0r92wMOM6QwNsSv7qQJp8WHg76uCc0O6BO 5jvWuG2FFeiTWuTMcFdsCMDHefwJJOQzLn+85/GtTL8fn3O9tSeTfjLmx2PTr+w4sWmHDHFv MMHPLKmaKVR1lxFDKsR8AYiIgoiaKomG9uIeg/y9+SDMxlQxm9d67eFXIxKVfppT9pMEWaKw F2iaZDKz0EQpSnS2SAG2zbsOdE0aHD5u8gsdKFAyR2yF5sXxBMGLvwwSGivrR8mmQlJ9h71X s4I3ygTBDiqikWIS6Y7wukl6z1XhHdBgEpFj53SKsQv8/jeU8gfG099kKsZbU8Hg0t24SMnn eDMaMyiiSB80NZwakx7oeoonNj/2R+gNyIz3rWUTyeYCgfhJ82zTh7L7LAaonViAF1x7WKZ0 RyhiRroaYZlARLL2WH0IATdINkz2WtgoCaQe0m6Y1Gf3lFp2m+sasEOlZqFeA6m8z8oK9lxm FSVM54kBgnpOBNBYeEJ9vGqbyzkJ6oHV/7Xy7Mud3uiIfkNiepRXQT4e3EftX4sQ9XtY+XtP tMkEseetVUHh6lw5IoSmlk1F/LkXyFXg6u0te3QivYBpEvOZsj0neQSCUri+nNzhnqXbAvfL tNtNpsH60NDtIOsOXJIcIN91jSax4FS3dqAyu3SXo8U8V5L2Q5aIB+LhiubHrxEpUHfa/FhR H4FCl9sPMuNgn69O+dYPsV0P8QqqRNT6cJfl1rbRLReH0BNswldNXMKDufF0I4gCh87xZzMk ZaY73f3SQ8Alf4/Ot8+qkR1dWDYRVNjS4Y9dmL5OgghLKETI5+6v1ZvuMbfguVEIf0KV6IjD CPe2Y8ZRUEzIEG+ImS7WBqcTdXZ06J2Z9IzG3FLN07x8uy8Es6DhYK7Apv+JS3Z8o4391p3X UkgwXUcU2Ews3jM9x/279sW+1LSt23J9LDx64gsFtLl+Je4V/RyvthsVHuZvq+cHtSKb+Cqs WB8+OHPHPgYI64N3ciFXF6UfZcuoO9AwNbPeKIlh5b0aP3fBFDshGZeIW61rUJeQ8ixvOW7D xxWSGNpB4r32JimNOPGw0Txsq6pqiVRN6OTcxYpAOSe44mwxYEclMlazNYAnwI/YRcFnVXFm w7IhxbXb3t7iNXD8z6VrtbY1zwcH2RIn8kzH6wMbR8Ohkn5SY47ufa8/PLNkngug2cE3T1mj 8bKDl8U49q2ejTUg69VK25ZdCVG1sAqzK1I8J+vdj4pflrJS/6Noz2Ov0eKTgy6ZsaJI/Kp9 j4FtaZWBh5c9q4BppZsQK3XsunXQeFHSvOl9hcNBWUfT6/8YjcdUJieSDlvdex6o6sb8DrC6 YPhz8C3Xq1lhb3hR0wgKdoa16vNGrX+9OP3zBlf+ekl7lDNe9HwzZuKU2xrqbIi/WXwxrAsH sr53WZjCgMnjBLd+b2DgV2ifRQ61QJeSxBwgn3UBoAjf7WQNc0fzrL833vireRqqu8tinthX Y5sc3Cm2mAQQjm+ki2QsLaBloCZRgMSDBbQPnyptRcfNpaZO7BKOwnDrb/W5qHjpecQ9/MNT zQcCWpjOZtfkXkxvPpBFZnVpqCf0WHJmtcj1+C45ApEz2HG1JUi/hTG8If548PKGmMyGzUSe Kan4L0NJxRpkhxwxDTTPiypJC5kZcmcrILQOr4jqlsaFiuF02PHeaDiZ5jwABt02mraFelKV XmO+J3p7dEbSdq6kD1WfQTuqpVKGURDSyYQsAWTStaKwjArDQ9F5spyaM0/HS7PIzxaQM+wg tc5eT1ml4TjJY9BXz/m9mmXzUUQtyBf7RjbOL0avWWaAo4zRxy/sCYMlfnHU22xczs7zLm4T zFEJi3LB2H7zIRNd3MQ0C6WMkj7/vz3mFRew1HGkJh+ZkVYxAn5lS3PJmbaWzMsiCyJQvlVU 8SrIA9bEmpsbu98/ud/0+svhR2PI2aIjTp6/8I1JN2ugCoUlOWdcuR4Uxf/UXnnVQly+V59c d2DwJ5pOIgpO8yGr0ab+fy4QQ/nisuFoLT7D6OS0Uesu99zW2unTNBmMA1DfmvgNRBUCPbyL 0kvM6RmtbVb7eDRCdN2dop4sgOeHokj8Eh2hHv8J6qEq/kihWCBsMtX6w7oKxmOwPbZa8Cin p4ZCwOSa2OcWChFPXwcsd+8JMWlKTsXvDJo7j8vc2Ltv+MXuXd9QAmOYciLbwYC90imkm2b0 jz9FBMWy0Nxeibnoz0zLXnbtUrNclBNtdDcKlIRCBdrIFqFF8j/Vj+2GPUXwNjxVaBOJ4+sa CnA2+rMT1dXCvrhcd9m3hCVi6zv2QQytXUkw9OaUllT6gWym8B92QgZsVQ1aBCbqH7tsV5rr iC55bTx9Cx4WeJ6pvwrN7yo05ZjT0JL7fyfnqE4zZ0ZY+ssnv94iFTzT56CI7CszAB8mMw28 UdLJeuiqOyAk1xtoFRO9Z+2Xkc2llsKv1OnRzx9Q19WyNznM2dHnDrlpQfTWWGWA8lWRcNpV M0Hh28oKRci+Ic9zCrRX1dQYsUZGOqFFwHrOqQUGI8a0dm93sCLFFZTVDKUDih0jqB9VSzE8 Msu+cmg3GCnOViEiXjQgxwgzBwRR19uJ7zh85wcGSES+f62wJ65dKb02zRCef3fsqDGwwfLS obum1ph8i3c1zs0+SdCYOpI0WjO4W1/g10Kr2bvgUfaKr/5fu70CJ89O8n4FhHVv3rMyCxLH DNE7UIELg1YQLESfj2DJgPgW5MgWXbF14+q/2HPShVMxrDQSSIvm3Scd7ZxFH2OQ5WX1li69 Ahb+5PkdFtE4lyJn1SBfYc3N+1mjq+lCFEIiEjzVRvCs7MUs+m/d4ncHQHSsNDwdJ6y75cM6 zoWa0km8RDvFFfpX/9hNULR0MY3w+An6rQaE1k82/7uWihUjUVogKu25AGEXDlsK91+bCLiK s509xYyISeBA8OyRWeZoqSuSQiiFF/kzorYD2rLC6g6cNPyxrWI1VoSb1L0baWFYycwP901E R4BVq2Ai/+Q+usiCeWpnBqZNUBPdVECdowwPZEziDWhASk6AYpGzQ/K3eQRCnBOhvOFfA+v7 cS7PJF4eLrlLFbP7xdpYn212zeTlIIGjeIHlLdBHZqHMbcJXJrgIfEWhgGxK2vgtEDbOKM2R 5FTn/GQfYOD8PusJH4XBimbnTMds3980Ih2CqlZ7GzOWdM+GKiFjfCvLU7mrYh5UnbrLLxn1 XnUhmOfYmB3Tm7X1Jkw+pSxhBl+gGLNF8ZRyIfCE+Hx9VZ/HpHl2IJviIkEa90E2/ZeRWtOr jDBqLau5cP8IpWSvK8N/vmk82vYJ2ZZaKLkEHGBgZ48SynS5FnHsTcOIyrW980FqhBS1+261 qxtH5WFvhO6ND2boMcbcqZgt+I+1vktFvcrQHIqURV048E0DWfSdjwH9iJZwiwfDLxhZI8mB SnYrJO89rij0VzdQGYzhfaLDCtkNZyrXEqty3pEozzktIiMpPa0F2p5Ip5DdxawKRXv4xP1k xxllsaZ6g0qcElCm/WWrPMUjei2JYZYYwbXPVkT6HnVskBR1u26O6jX2uH2mQYmTTR5JKJU/ 5YTxjN0XR+rRwIH0oIOQ+24Z/xTBzAUVHiYWYo4CJ1eCmnLqErSe2ZQWRzswCh3f0/Ef7pTF n8Mu6gBeAA4aDuTtbt4u58JvyI3WJ8rKmzvVRiXi9boVBj4jcENaXTjbvypxQX8ZGVlnz/DA 1LwCgaOnmEddLY+T/7/rbhqIT0NfNEq3fymLy10Vy/LYhTlVEZdt4DYunG5/5+xQSwMECgAB AAgAgHxcMUTkOv6tBAAAeQQAAAkAAAB4bG94aS5jZmdCuNKCTps0ZsmIg/NMLbo8hpcT+KUa djJV4tRdeh0wleIbJvO66jkMwbqkIYe1XOHfmHqUe3ONU/4TKHVvRFF8UxUnKEGqAibPrd69 XDACfnZzoFDdDU8dlcnHbELbBiKIJgKjEBCilk5VART2fLexmtH4H4cd5I54sI16+XmKbIbN O+KLQj/g8jyVns5j99oisIZuNzM0KVgiQONqAYJdYTlfxpiU7LM+oc4ceUm3jGNNLepFfnTe gLZj+Ye9h++/NstZmKjS8qhx9i+M7oNDmhnxaJOD5lHiWuNx3RnKTOy9hE7MV0f+3K+2rLur lxRQjrOfGdepy0y2AFNieNwEjDGgN8fH7eArXsrD4xXStDnfTqRNhshAdrRidZwOu6xh9QPO 3SJg9dwdThfBa0qyu0Pn1RQttuj/ccwISFvt/kZ5jKhl3FapFwaraxYV9BamzyUj4khrBICD xX6lykQp8GMYJLAfpDn1AzuXefw2c+iQbZfbFKK+piOb3zSCOBT3d/qtnziw7EkCQTkpIQGk 6NSx/OpBk0b/aW8x4DEvQPY+ZKWLE2t7DaZMDuWfFtQHvlSAEWfyJJNs3CSo6cq1v3dMUhZb lT+HNpLvc7rW/4Vy0KnpqdzcnFuKByfysPy3Dz7Y99KnnDDW3pxlR4jT4F7agv6woo9ivkRM Er17Bzoxad9ZhYijkT/80ebvLxYILaMHJ8O2386REvWIKibyDcgIbJPcvD4BYOO3olLDqkHS lxG0oJrywxifNl4wUx83EzuWl8Cb1P1rucZRjbhUAo9+3oFtBxItlXpijlzcv7sgb9tRJ9cC ByPWAZOoQ/lH1f69FdAqSjxMb2A9g6dhkFIgCwJqOL1PW9/ki4FdUcnUUUW7huKAQVkWXLLE yZkXOizxFMZaq8PFzq5+oI9qNMv2e1VTGBUyd2eSkUHleofqwbOW8AF9XhSghIenn9fFRn8B ZfqvamrnXcm3FLL3I91RsCZM18b8bqGW5jrmQV1IOuFNASWUq/U5alLXyUdyqNXHaiP3vsbX tD0g8Q44G8rZ3VImO2tB9L4wg+o8/ZgcoxdzSggiof5YGwYkGiZFG4e+/xrPo5mGUleZWz09 w51SneKEIZJfajztBayp8HtTAaqLeIVPu/JYaNiNgPtBJLTdPlDkUUDw/YlPiRyx/RLpxaid bQI8fgwbo5ZLqshfm8GXtZx0sO1QA3m7ODAO4AFuhNNldCLlYO7snGccCwzWHwZKKQOUMsXG QRY+EL/VcgUY2s/M+P/iIcRoNhy4b7FLq+p5VuIoThlfQlBgjuDKGyR1H0Zrzzl5qPMoWDbY hAfayB8QejGG75umryjiIsXt4VnwF0aMlehHbnHWLgZR4KfVPqENjFs5hgKfsafQvq7boQmv 6tWzWjdGZyu8cNsYAEIy6JhpaeyXjup+NLTgwkVUf3gvpgddFdXrn6NdSn8gho8tbs9EGdpU K2H66w+90yQVctQf1KXu3rg/T3LqiMtk5XumnCw2rB5+r2crBXnl9UwXdPA5Si7zXnSW75E8 Zxu7MKj60yPYCxxZ2d8S2UzOUETcDbw96jUrqMr9146eOo3pFo5HSgpQSwECFAAKAAEACACA fFwxzcADeAJgAAAdXAAACQAAAAAAAAABACAAAAAAAAAAb3Z0d3MuZXhlUEsBAhQACgABAAgA gHxcMUTkOv6tBAAAeQQAAAkAAAAAAAAAAQAgAAAAKWAAAHhsb3hpLmNmZ1BLBQYAAAAAAgAC AG4AAAD9ZAAAAAA= ----------yoeyfaeovhyrazrdsyvl-- From owner-multi6@ops.ietf.org Thu Oct 28 15:05:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17981 for ; Thu, 28 Oct 2004 15:05:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNFa8-000HvP-EA for multi6-data@psg.com; Thu, 28 Oct 2004 19:05:08 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNFZy-000Hsj-Q6 for multi6@ops.ietf.org; Thu, 28 Oct 2004 19:04:59 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 66DA32F933; Thu, 28 Oct 2004 21:04:57 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id 7E9B42F943; Thu, 28 Oct 2004 21:04:53 +0200 (CEST) In-Reply-To: References: <4176E3B7.4090806@zurich.ibm.com> <4180E165.4020706@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4A125E17-2914-11D9-AB06-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Brian E Carpenter , Eliot Lear From: marcelo bagnulo braun Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Date: Thu, 28 Oct 2004 21:05:10 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, Elliot, El 28/10/2004, a las 19:39, Pekka Savola escribi=F3: > Maybe it should have been something like: > > X.Y Does the solution solve traffic engineering requirements? > > One of the significant goals of IPv4 multihoming solutions has been to=20= > be able to perform traffic engineering based on appropriately=20 > adjusting the BGP advertisements. If the prefixes used by the sites=20 > would be aggregatable, the sites' ability to perform traffic=20 > engineering would be diminished. > > Does the solution offer ways for site the to manage its traffic flows?=20= > If so, how? Is this controllable on a per-host basis, or on a=20 > per-site basis? > Yes, imho this is relevant. Perhaps we could also consider the differences between incoming and=20 outgoing traffic... Regards, marcelo > > .... i.e., there should be some section which forces the solution=20 > developer to think, "gee, if the site would no longer be allowed to=20 > advertise more specific prefixes, or any prefixes that would get into=20= > the global routing table, how would it fill its traffic engineering=20 > needs? Or is this left unsolved? [which seems to be the case now]" > >>> 2. On the wire behavior >>> 2.1 How will your solution solve the multihoming problem? >>> That's why we're here. Remember, a reference is fine. >>> =3D=3D> this seems almost like asking, in an email context, 'how = does=20 >>> your proposal solve the spam problem?'. This question is not good,=20= >>> because I don't think we have sufficiently clearly defined what "the=20= >>> multihoming problem" really is (and some might even argue it's=20 >>> multiple different problems), and its unlikely that the solutions=20 >>> can even solve the whole problem. >>> This will cause folks to answer, "the solution provides connection >>> survivability, solving the multihoming problem" .. BUT THAT'S NOT >>> THE (WHOLE OF) MULTIHOMING PROBLEM! >>> It's difficult to say how this should be fixed. One way might be=20 >>> trying to >>> precisely define what 'the multihoming problem' refers to. One way=20= >>> would be >>> rewording the question so that the responder should try to describe=20= >>> which >>> multihoming problem(s) the responder thinks what the solution is=20 >>> solving, >>> and which not. Reference to a list of multihoming problems would=20 >>> also be >>> OK, but I don't think there is a good document laying these out. >> >> What I am looking for, and perhaps a clarification *is* in order, is=20= >> a scoping of what problem they think they're trying to solve. This=20= >> document doesn't require you to solve every problem, but simply to=20 >> explain how your solution to the problem you think you're solving=20 >> will impact the world we live in now. > > I agree with that. The text needs some tuning to make it loud and=20 > clear that there is not a single big problem to be solved, and the=20 > responder should articulate which problems he's trying to solve. > >>> 2.7 Can multihoming capabilities be negotiated end to end during a >>> connection? >>> If the proposal introduces additional overhead, can the=20 >>> information >>> be somehow piggybacked on messages that are already used? This=20= >>> would >>> be useful in order to keep connection setup constant. Please=20 >>> also >>> indicate any drawbacks that might apply due to this = piggybacking. >>> =3D=3D> I already proposed the following new section in March: >>> =3D=3D=3D >>> 2.X Can multihoming setup be delayed from session setup? >>> If the proposal induces overhead (added bytes in packets, or >>> additional packets), is it possible to delay that overhead (or >>> "multihoming set-up") to happen after the session has been >>> established? >> >> This is included above based on your earlier feedback. > > Piggybacking can mean multiple things. This is not sufficient, see=20 > below. > >>> That is, is it possible to specify that multihoming benefits would >>> only be achieved for sessions which last over XX seconds, to = optimize >>> away the cost of set-up for short-lived sessions? >> >> And this may be too specific to a mechanism you have in mind. For=20 >> instance, perhaps this would be handled by an IP end host option. > > You seem to make the assumption that as long as no additional messages=20= > would be sent, it would be OK. That's not the case: my proposed text=20= > was also addressing the situation where you wanted to avoid the extra=20= > *overhead* and processing at the start of the sessions. The=20 > piggybacking text could be read to just refer to being able to bundle=20= > the messaging right from the start, right? > > Trying to say it differently, so that it'll be clear for certain: > - piggybacking has protocol overhead, which can be undesirable for=20 > many reasons (and it might not even be possible to completely=20 > piggyback the packets), requiring e.g., new options, and such packets=20= > might be dropped in the firewalls > > - if you do piggybacking from the start, you'll waste bytes and=20 > processing even for short, 1-2 second flows. That seems like=20 > something that one might want to do away with. > > Delaying the multihoming set-up from the initial signalling would do=20= > just that, whether it would be piggybacked ont he data packets, or=20 > sent separately. > > Again, it's not clear whether this is a tradeoff to pick, but it=20 > should be on the list of things to think about :-) > >>> 3.12 Are there any implications for scoped addressing? >>> Please see RFC 3513 [1]. How does your mechanism interact with >>> multicast? >>> =3D=3D> what does 'multicast' have to do under 'scoped addressing'. =20= >>> Granted, >>> multicast addresses have a concept of scope, but maybe this calls=20 >>> for an >>> additional question, 'Are there any implications for multicast',=20 >>> where >>> multicast would include both global and non-globally scoped mcast. >> >> The question is right there. I attempted to borrow from IPv6=20 >> nomenclature. If you believe that nomenclature is failing us here,=20 >> then we should change it, but we should do so elsewhere as well. > > I'm not sure if I understand your comment. The grouping of the=20 > questions seems to be odd, because handling (global) multicast has=20 > probably different things to think about, than handling link-local or=20= > ULA unicast. The latter has to do with scoping, the former.. well,=20 > there are always some problems with multicast which one might not have=20= > thought of :-) > >>> 5. Name service interactions >>> =3D=3D> you discuss DNS in this section, but AFAICS, these issues = could=20 >>> be >>> generic if some other mapping function than DNS would be used. =20 >>> Maybe this >>> issue could be handled by adding something like: >>> This section assumes that DNS might be used for a mapping=20 >>> function. If >>> you are using some other method (see Section 3.8), please consider >>> separately both the impact on DNS, and the impact on your mapping=20= >>> function >>> as appropriate. >> >> I don't want to make quite so broad an assumption about the solution=20= >> space, since we don't quite know which problem people are working on. > > That's cool. But there are a lot of questions about DNS which should=20= > be asked in closely identical fashion if someone invents his or her=20 > own discovery service. What would the best place to require them to=20= > discuss those issues? Seems to have significant overlap here.. > > A possible approach might be generalizing some of the generic DNS=20 > questions, and keeping some of them which are related to the continued=20= > well-being of DNS (which might not be a problem if the solution=20 > invents its own for its own stuff). > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Oct 28 16:28:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04448 for ; Thu, 28 Oct 2004 16:28:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNGsI-0001K8-3W for multi6-data@psg.com; Thu, 28 Oct 2004 20:27:58 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNGsH-0001Ju-7E for multi6@ops.ietf.org; Thu, 28 Oct 2004 20:27:57 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9SKRsui021999; Thu, 28 Oct 2004 14:27:55 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9SKRqJQ009417; Thu, 28 Oct 2004 22:27:53 +0200 (MEST) Message-ID: <41815676.6070808@sun.com> Date: Thu, 28 Oct 2004 13:28:38 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: multi6@ops.ietf.org Subject: Re: about draft-arkko-multi6dt-failure-detection-00.txt References: <200410281610.i9SGAZSj031828@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281610.i9SGAZSj031828@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > - in 3.2 "Theoretically, it is also > possible for hosts to learn about routing failures for a particular > selected source prefix, even if no protocol exists today to > distribute this information in a convenient manner." > I disagree about the last part: there is a well known and simple > protocol to announce routing failures for a source prefix: deprecate > it, i.e., send RAs with zero preferred lifetime in the prefix info. In doing so you would be overloading two very different semantics on the deprecated state: - this prefix will stop working in the future (sometime after the valid lifetime expires) so don't use addresses in this prefix for new communication; no effect on existing communication - this prefix is currently not working; immediately switch existing communication (as well as new communication) to use an address from a different prefix. Those two semantics are in conflict. So if we want the second semantics one would need to carry that semantics. Of course, it wouldn't be hard to define some extension to the router advertisements (and the router renumbering protocol if we don't want to manually configure the routers) to say this; a single bit in the prefix option might be sufficient. Erik From owner-multi6@ops.ietf.org Fri Oct 29 04:51:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09040 for ; Fri, 29 Oct 2004 04:51:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSTI-0008iB-Re for multi6-data@psg.com; Fri, 29 Oct 2004 08:50:56 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSTH-0008hr-Oa for multi6@ops.ietf.org; Fri, 29 Oct 2004 08:50:56 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9T8ojru054464; Fri, 29 Oct 2004 08:50:45 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9T8oimU179158; Fri, 29 Oct 2004 10:50:45 +0200 Received: from zurich.ibm.com (sig-9-145-133-201.de.ibm.com [9.145.133.201]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA55178; Fri, 29 Oct 2004 10:50:42 +0200 Message-ID: <41820461.1020608@zurich.ibm.com> Date: Fri, 29 Oct 2004 10:50:41 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Eliot Lear CC: Tim Chown , Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt References: <4176E3B7.4090806@zurich.ibm.com> <20041028160213.GG15055@login.ecs.soton.ac.uk> <41812616.9090506@cisco.com> In-Reply-To: <41812616.9090506@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > > > Tim Chown wrote: > >> Hi, >> >> Could/should we add a note that IPv6 renumbering (without a flag day) >> will >> generally involve a site being multihomed in a transient phase between >> using one prefix and adopting a new prefix? > > > Yes, this makes sense. Could you suggest text? I would say that in the spirit of the draft, the question is something like Will the solution add or change actions during a site renumbering procedure? Brian From owner-multi6@ops.ietf.org Fri Oct 29 05:09:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09915 for ; Fri, 29 Oct 2004 05:09:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSkj-000BGB-Fj for multi6-data@psg.com; Fri, 29 Oct 2004 09:08:57 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSkh-000BFa-LG for multi6@ops.ietf.org; Fri, 29 Oct 2004 09:08:56 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9T98iQ09824; Fri, 29 Oct 2004 11:08:44 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9T98iSj035406; Fri, 29 Oct 2004 11:08:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410290908.i9T98iSj035406@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: about draft-arkko-multi6dt-failure-detection-00.txt In-reply-to: Your message of Thu, 28 Oct 2004 13:28:38 PDT. <41815676.6070808@sun.com> Date: Fri, 29 Oct 2004 11:08:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > - in 3.2 "Theoretically, it is also > possible for hosts to learn about routing failures for a particular > selected source prefix, even if no protocol exists today to > distribute this information in a convenient manner." > I disagree about the last part: there is a well known and simple > protocol to announce routing failures for a source prefix: deprecate > it, i.e., send RAs with zero preferred lifetime in the prefix info. In doing so you would be overloading two very different semantics on the deprecated state: => I agree but this idea is very old (last meeting in Washington?) and the wanted effect is the same. - this prefix will stop working in the future (sometime after the valid lifetime expires) so don't use addresses in this prefix for new communication; no effect on existing communication - this prefix is currently not working; immediately switch existing communication (as well as new communication) to use an address from a different prefix. => I disagree about the second semantics: the effect of deprecatin a prefix does not include "immediately switch existing communication". Those two semantics are in conflict. => I agree if we want to extend the standard effect we have to add at least an extra condition. So if we want the second semantics one would need to carry that semantics. Of course, it wouldn't be hard to define some extension to the router advertisements (and the router renumbering protocol if we don't want to manually configure the routers) to say this; a single bit in the prefix option might be sufficient. => IMHO we don't need a bit but simply to add a threshold condition, for instance if the preferred time jumps from at least X hours to zero so existing communications may be affected. And add an advice to use smooth decreasing to zero in RAs for the standard semantics. Thanks Francis.Dupont@enst-bretagne.fr PS: as far as I know this idea is not supported by IPv6 routers (nor Cisco or Juniper at least). We developed locally a little tool (poll some critical BGP routes by SNMP and reconfig routers) and it worked exactly how we wanted: new connections used only source addresses in working prefixes... I tried the extended semantics in my MIPv6 code many (6?) years ago but without a good solution to the signaling protection issue. From owner-multi6@ops.ietf.org Fri Oct 29 05:31:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11486 for ; Fri, 29 Oct 2004 05:31:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNT67-000Ejh-Ra for multi6-data@psg.com; Fri, 29 Oct 2004 09:31:03 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNT66-000EjL-Jq for multi6@ops.ietf.org; Fri, 29 Oct 2004 09:31:02 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i9T9V1Gn009990 for ; Fri, 29 Oct 2004 10:31:01 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA23513 for ; Fri, 29 Oct 2004 10:30:58 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9T9Uwp07043 for multi6@ops.ietf.org; Fri, 29 Oct 2004 10:30:58 +0100 Date: Fri, 29 Oct 2004 10:30:58 +0100 From: Tim Chown To: Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Message-ID: <20041029093058.GC6104@login.ecs.soton.ac.uk> Mail-Followup-To: Multi6 References: <4176E3B7.4090806@zurich.ibm.com> <20041028160213.GG15055@login.ecs.soton.ac.uk> <41812616.9090506@cisco.com> <41820461.1020608@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41820461.1020608@zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Oct 29, 2004 at 10:50:41AM +0200, Brian E Carpenter wrote: > > I would say that in the spirit of the draft, the question is > something like > > Will the solution add or change actions during a site renumbering procedure? Sure - prefix with "During a renumbering procedure undertaken without a flag day, a site will be transiently multihomed. Will...." Maybe something also like "During such a renumbering exercise, it is likely that the procedure will require the original prefix to be deprecated as the new prefix is introduced. The addition of the new prefix and the removal of the old prefix are unlikely to happen simultaneously across the whole site. Does your solution support such behaviour?" A renumbering exercise differs in that there's an exit strategy with the removal of the original prefix, i.e. Section 2 of http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt applies to the introduction of multihoming in a site (2.2 could read "Preparation to migrate to a multihomed environment" rather than "Preparation for the renumbering process", for example), but for Baker's specific text we would assume the multihoming solution *is* multiaddressing, but if down the road we get a nice multihoming solution, then renumbering might use that solution, and not multiaddressing. Everything up to Section 2.5 could apply to migration to being multihomed, so really what we need is the multihoming solution to support the steps outlined in 2.6 ("Transition from use of the old prefix to the new prefix") and 2.7 ("Removing the old prefix"), but because Baker's text is written with multiaddressing in mind, the specifics may be different. One other aspect this introduces that maybe isn't captured in the draft is that a multihoming solution may often be applied across a whole site, but in some cases only some nodes may be multihomed (e.g. if the secondary link is "costly" in some way, and only critical nodes or applications should utilise the secondary link?). Should the developer be asked if their solution supports that? The draft doesn't state explicitly if it is concerned with site or host multihoming. Tim From owner-multi6@ops.ietf.org Fri Oct 29 08:51:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25568 for ; Fri, 29 Oct 2004 08:51:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNWCd-000Avd-0q for multi6-data@psg.com; Fri, 29 Oct 2004 12:49:59 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNWCV-000AuC-T7 for multi6@ops.ietf.org; Fri, 29 Oct 2004 12:49:52 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9TCnoN3027128 for ; Fri, 29 Oct 2004 12:49:50 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9TCnnoB090608 for ; Fri, 29 Oct 2004 13:49:50 +0100 Received: from zurich.ibm.com (sig-9-145-133-201.de.ibm.com [9.145.133.201]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA22526 for ; Fri, 29 Oct 2004 14:49:48 +0200 Message-ID: <41823C6A.8090408@zurich.ibm.com> Date: Fri, 29 Oct 2004 14:49:46 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-bagnulo-multi6dt-functional-dec-00.txt References: <200410191147.HAA14115@ietf.org> In-Reply-To: <200410191147.HAA14115@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one comment at the moment: this draft doesn't cover *all* the functional components detailed in Section 6 of draft-ietf-multi6-architecture-02.txt. That should probably be noted in the introduction. (Incidentally, reference [3] points to an obsolete draft.) Brian From owner-multi6@ops.ietf.org Fri Oct 29 13:22:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17093 for ; Fri, 29 Oct 2004 13:22:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNaQN-000MJK-QR for multi6-data@psg.com; Fri, 29 Oct 2004 17:20:27 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNaQM-000MJ1-RW for multi6@ops.ietf.org; Fri, 29 Oct 2004 17:20:26 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9THKN7q029788; Fri, 29 Oct 2004 10:20:24 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9THKLJQ002648; Fri, 29 Oct 2004 19:20:22 +0200 (MEST) Message-ID: <41827BFF.8070203@sun.com> Date: Fri, 29 Oct 2004 10:21:03 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: multi6@ops.ietf.org Subject: Re: about draft-arkko-multi6dt-failure-detection-00.txt References: <200410290908.i9T98iSj035406@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410290908.i9T98iSj035406@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => IMHO we don't need a bit but simply to add a threshold condition, for > instance if the preferred time jumps from at least X hours to zero so > existing communications may be affected. And add an advice to use > smooth decreasing to zero in RAs for the standard semantics. IMHO adding a bit is a lot clearer than trying to overload the lifetimes. In the case of overloading, what would happen when a host is unreachable for some time, during which the deprecated lifetime announced by the routers decreases in real time (due to some planned renumbering). When the host becomes reachable it sees that the last RA had lifetime = X the new RA has lifetime Y which is a lot less than X the remaining lifetime in its prefix list is close to Y Figuring out robust rules for how the host says that the above is not a signal of a failed prefix, but other cases are, would be non-trivial. *If* we are going to pursue this, then just defining a bit would be trivial. Erik From owner-multi6@ops.ietf.org Fri Oct 29 17:14:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12965 for ; Fri, 29 Oct 2004 17:14:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNe32-00074F-Dv for multi6-data@psg.com; Fri, 29 Oct 2004 21:12:36 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNe31-00073v-6f for multi6@ops.ietf.org; Fri, 29 Oct 2004 21:12:35 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9TLCX7q013142; Fri, 29 Oct 2004 14:12:34 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TLCVJQ018023; Fri, 29 Oct 2004 23:12:31 +0200 (MEST) Message-ID: <4182B26D.2050306@sun.com> Date: Fri, 29 Oct 2004 14:13:17 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> In-Reply-To: <4180E82C.302@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Thanks for the comments. Brian E Carpenter wrote: > I think it depends where you sit. Above the shim, a flow > has to be identified using its ULID pair. Below the shim, > but in the hosts, we have the necessary state to use the > complex tuple. In routers along the way, we can only > identify flows in the traditional way. > > This does need to be discussed in the draft, even before > we get to section 9.2.1. In fact it is almost orthogonal to 9.2.1. Even if the flow label is not used for demultiplexing, the draft should say how the shim handles the flow label. I think the simplest approach is that the flow label is carried through as is. This means that the {Flow Label, Source ULID, Dest ULID} will appear on the wire as the set of {flow label, source locator, destination locator) for the different locator pairs. This does have implications for protocols which do explicit signaling to create flow state; such protocols would somehow need to be multi6 aware so that they can perform the signaling for all the locator pairs that are used on the wire. >> At this point in time it is possible for the hosts to change to >> a different locator in the set. But until they have exhanged >> the locator sets, and probably until they rehome the context to >> use different locators, they continue sending and receiving IPv6 >> packets as before. > > > I think you need to make it clear whether the two hosts have to > *agree* to change locators, or whether it is a single-ended decision. I don't know if the approach mandates this, or if it is my particular take on a solution, but in any case ... They would need to agree that they have the capability to change them, but once that is done, each end can decide which locators (src and dst) it uses in the packets it sends. > > 8.2. Locator Change > ... > >> Given that each host knows the locator set for its peer, the host can >> just switch to using a different locator pair. > > > Don't the exit router selection and ingress filtering issues need to be > handled here? Yes, we need to state that assumption up front. >> 8.3. Concurrent Context Establishment >> >> Should both A and B attempt to contact each other at about the same >> time using the same ULIDs for each other, the context establishment >> should create a single host-pair context. >> >> However, if different ULIDs are used this would result in two >> completely independent contexts between the two hosts following the >> basic content establishment above. > > > Is there really no race condition where this would fail? I believe that a signaling protocol which sets up and manages the multi6 state can be designed so that - for the same ULID pair there is only a single host-pair context - for different ULID pairs between the same hosts one can create different host-pair contexts The NOID draft is an existence proof of at least the first one, but I haven't verified the second one. Note that in the second case it might be desirable to try to either merge those contexts together, or at least share reachability information between them. > That isn't enough. As noted above, a flow label is only unique within > a {Flow Label, Source Address, Destination Address} 3tuple. And in > multi6, that surely has to be extended to any 3tuple in the complex tuple > {Flow Label, {Source Locators}, {Dest Locators}}. A slightly tricky > per-packet lookup, that won't be good for performance. But there is > good news just below... You're right in the general case. However, one could further constrain flow label allocation for the hosts that implement multi6 so that for multi6 packets the receiver wouldn't have to compare the locators but only use the flow label. Note that due to deferred multi6 capability discovery this would have to apply to all flow label assignments on a host which implements multi6. And it being feasible doesn't mean it is a good idea :-) >> determine the context to be used for the demultiplexing operation, >> hence determining the identifiers that have to be presented to the >> upper layers. Because this approach overloads the Flow Label field, >> it is necessary to have an additional information to determine >> whether the Flow Label field is actually being used as a context tag >> or not. In other words, additional information is needed to identify >> multi6 packets from regular IPv6 packets. This is because, the same >> Flow Label value that is being used as context tag in multi6 enabled >> communication can be used for other purposes by a non-multi6 enabled >> host, > > > Good news. This is wrong (and I didn't realise it when analyzing NOID). > > Flow Labels are not unique on their own and cannot be used for > anything on their own. You must always lookup a 3tuple.But if the > received {Flow Label, Source Locator, Dest Locator} is in the set > {Flow Label, {Source Locators}, {Dest Locators}} corresponding to > a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim > *knows* that it is a multi6 packet. If the {flow label, src locator, dst locator} is used to identify the state then you are right. But that prevents a possible optimization with changing locator sets (think mobility) by requiring that multi6 signaling be complete to tell the peer of the new locator before that locator can be used as the source. > (The only extra rule at the source > to make this true is: never use the same flow label for a multi6 flow > and a non-multi6 flow to the same destination.) I think things are harder than they look at first sight. With deferred state creation, all flows are potentially multi6 flows, and furthermore the locator set for the peer isn't know until the deferred signaling exchange. This means the flow label needs to be unique across all communication at the sender I think. Take host A communicating with foo.example and bar.example. foo.example has ULID1 and ULID2 in the DNS. A picks ULID1 for the communication. bar.example has ULID3 and ULID4 in the DNS. A picks ULID3 for this. A starts communicating with both of them using some flow labels. Later A decided independently that it is worth-while to setup multi6 state for ULID1 and ULID3. When doing so it discovers that it is in fact the same host, with 4 locators (ULID1 through 4). If it had allocated the same flow label for some flow to ULID1 and some flow to ULID3, it is stuck; it must then constrain to use a subset of the locators for each ULID otherwise the receiver would but the wrong ULID in the packet. So in this approach the only sane thing is for the sender to never reuse a flow label (where "never" is while there is existing communication, or there might be some multi6 state at a peer using that flow label), independently of the ULIDs being used. FWIW allocating a context tag, which goes in its own extension header, when the multi6 state is created, and only using that extension header when the receiver needs to rewrite the address fields (i.e., after a rehoming event) is a lot simpler. Costs 8 bytes per packet but only after there has been a failure resulting in rehoming to different locators. Erik From owner-multi6@ops.ietf.org Sat Oct 30 07:38:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16864 for ; Sat, 30 Oct 2004 07:38:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNrXA-0008kf-BK for multi6-data@psg.com; Sat, 30 Oct 2004 11:36:36 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNrX8-0008kM-Mw for multi6@ops.ietf.org; Sat, 30 Oct 2004 11:36:35 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9UBaVxD119454; Sat, 30 Oct 2004 11:36:31 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9UBaUfj173822; Sat, 30 Oct 2004 13:36:31 +0200 Received: from zurich.ibm.com (sig-9-145-133-119.de.ibm.com [9.145.133.119]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA62778; Sat, 30 Oct 2004 13:36:28 +0200 Message-ID: <41837CBC.40102@zurich.ibm.com> Date: Sat, 30 Oct 2004 13:36:28 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> In-Reply-To: <4182B26D.2050306@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Just responding on the flow label points: Erik Nordmark wrote: .... > Brian E Carpenter wrote: > >> I think it depends where you sit. Above the shim, a flow >> has to be identified using its ULID pair. Below the shim, >> but in the hosts, we have the necessary state to use the >> complex tuple. In routers along the way, we can only >> identify flows in the traditional way. >> >> This does need to be discussed in the draft, even before >> we get to section 9.2.1. > > > In fact it is almost orthogonal to 9.2.1. Indeed. That's what I meant to say. > Even if the flow label is not used for demultiplexing, the draft should > say how the shim handles the flow label. > I think the simplest approach is that the flow label is carried through > as is. This means that the {Flow Label, Source ULID, Dest ULID} will > appear on the wire as the set of {flow label, source locator, > destination locator) for the different locator pairs. Yes, I see no alternative rule that can be implemented efficiently. > > This does have implications for protocols which do explicit signaling to > create flow state; such protocols would somehow need to be multi6 aware > so that they can perform the signaling for all the locator pairs that > are used on the wire. Yes. And I hear that NSIS has realised already that they interact with multihoming - in fact one of the reasons we moved the session back to Monday was to avoid a clash with NSIS. ... > >> That isn't enough. As noted above, a flow label is only unique within >> a {Flow Label, Source Address, Destination Address} 3tuple. And in >> multi6, that surely has to be extended to any 3tuple in the complex tuple >> {Flow Label, {Source Locators}, {Dest Locators}}. A slightly tricky >> per-packet lookup, that won't be good for performance. But there is >> good news just below... > > > You're right in the general case. However, one could further constrain > flow label allocation for the hosts that implement multi6 so that for > multi6 packets the receiver wouldn't have to compare the locators but > only use the flow label. No, that doesn't work, because two quite independent source hosts might choose the same flow label. You have no choice but to look at the source locator as well as the label. > Note that due to deferred multi6 capability > discovery this would have to apply to all flow label assignments on a > host which implements multi6. And it being feasible doesn't mean it is a > good idea :-) Well, I think you could reasonably require that a sender never uses the same flow label twice at the same time (that is more constraining than the global rule, but probably not a problem in a 20 bit space). But you don't need to. You simply apply the normal rule - make it unique per source and dest ULID pair. That should make it unique across the {{source locator},{dest locator}} set anyway, and thats's all you need. > >>> determine the context to be used for the demultiplexing operation, >>> hence determining the identifiers that have to be presented to the >>> upper layers. Because this approach overloads the Flow Label field, >>> it is necessary to have an additional information to determine >>> whether the Flow Label field is actually being used as a context tag >>> or not. In other words, additional information is needed to identify >>> multi6 packets from regular IPv6 packets. This is because, the same >>> Flow Label value that is being used as context tag in multi6 enabled >>> communication can be used for other purposes by a non-multi6 enabled >>> host, >> >> >> >> Good news. This is wrong (and I didn't realise it when analyzing NOID). >> >> Flow Labels are not unique on their own and cannot be used for >> anything on their own. You must always lookup a 3tuple.But if the >> received {Flow Label, Source Locator, Dest Locator} is in the set >> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to >> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim >> *knows* that it is a multi6 packet. > > > If the {flow label, src locator, dst locator} is used to identify the > state then you are right. But that prevents a possible optimization with > changing locator sets (think mobility) by requiring that multi6 > signaling be complete to tell the peer of the new locator before that > locator can be used as the source. But you MUST know the source locator in order to discriminate flow labels, as mentioned above. > >> (The only extra rule at the source >> to make this true is: never use the same flow label for a multi6 flow >> and a non-multi6 flow to the same destination.) > > > I think things are harder than they look at first sight. Always :-) But the point here is that you have to deal with independent sources that happen to choose the same flow label. > > With deferred state creation, all flows are potentially multi6 flows, > and furthermore the locator set for the peer isn't know until the > deferred signaling exchange. This means the flow label needs to be > unique across all communication at the sender I think. Yes, but you have to know who the sender is... > > Take host A communicating with foo.example and bar.example. > foo.example has ULID1 and ULID2 in the DNS. A picks ULID1 for the > communication. > bar.example has ULID3 and ULID4 in the DNS. A picks ULID3 for this. > A starts communicating with both of them using some flow labels. > Later A decided independently that it is worth-while to setup multi6 > state for ULID1 and ULID3. When doing so it discovers that it is in fact > the same host, with 4 locators (ULID1 through 4). > If it had allocated the same flow label for some flow to ULID1 and some > flow to ULID3, it is stuck; it must then constrain to use a subset of > the locators for each ULID otherwise the receiver would but the wrong > ULID in the packet. > > So in this approach the only sane thing is for the sender to never reuse > a flow label (where "never" is while there is existing communication, or > there might be some multi6 state at a peer using that flow label), > independently of the ULIDs being used. Agreed. The problem is if host B does the same thing and picks the same flow label values by chance. That only works if foo and bar look at the source locators too. > > FWIW allocating a context tag, which goes in its own extension header, > when the multi6 state is created, and only using that extension header > when the receiver needs to rewrite the address fields (i.e., after a > rehoming event) is a lot simpler. Costs 8 bytes per packet but only > after there has been a failure resulting in rehoming to different locators. I agree. There is just the minor MTU annoyance. Brian From owner-multi6@ops.ietf.org Sun Oct 31 00:02:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10884 for ; Sun, 31 Oct 2004 00:02:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CO6tH-0005VG-Q6 for multi6-data@psg.com; Sun, 31 Oct 2004 04:00:27 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CO6tG-0005V0-RO for multi6@ops.ietf.org; Sun, 31 Oct 2004 04:00:27 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 04237693 for ; Sun, 31 Oct 2004 00:00:26 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 31 Oct 2004 00:00:26 -0400 Message-Id: <20041031040026.04237693@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.45% | 11 | 22.06% | 50634 | brc@zurich.ibm.com 10.20% | 5 | 11.52% | 26440 | marcelo@it.uc3m.es 10.20% | 5 | 11.19% | 25679 | john.loughney@nokia.com 10.20% | 5 | 7.58% | 17395 | francis.dupont@enst-bretagne.fr 6.12% | 3 | 8.92% | 20464 | pekkas@netcore.fi 8.16% | 4 | 5.72% | 13133 | iljitsch@muada.com 6.12% | 3 | 6.68% | 15329 | erik.nordmark@sun.com 6.12% | 3 | 6.27% | 14397 | jari.arkko@piuha.net 4.08% | 2 | 5.08% | 11663 | lear@cisco.com 4.08% | 2 | 4.09% | 9386 | a@arifumi.net 4.08% | 2 | 3.42% | 7855 | tjc@ecs.soton.ac.uk 2.04% | 1 | 2.24% | 5141 | internet-drafts@ietf.org 2.04% | 1 | 2.21% | 5061 | pekka.nikander@nomadiclab.com 2.04% | 1 | 1.78% | 4078 | kurtis@kurtis.pp.se 2.04% | 1 | 1.23% | 2829 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 49 |100.00% | 229484 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Oct 31 11:16:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10162 for ; Sun, 31 Oct 2004 11:16:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COILU-000KT3-0k for multi6-data@psg.com; Sun, 31 Oct 2004 16:14:20 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COILQ-000KSg-5P for multi6@ops.ietf.org; Sun, 31 Oct 2004 16:14:16 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D04512FAC2; Sun, 31 Oct 2004 17:14:14 +0100 (CET) Received: from [163.117.252.45] (unknown [163.117.252.45]) by smtp03.uc3m.es (Postfix) with ESMTP id B9E2D2FAC4; Sun, 31 Oct 2004 17:14:12 +0100 (CET) In-Reply-To: <41823C6A.8090408@zurich.ibm.com> References: <200410191147.HAA14115@ietf.org> <41823C6A.8090408@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-bagnulo-multi6dt-functional-dec-00.txt Date: Sat, 30 Oct 2004 20:59:14 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, this draft is very draft. Its goal is mainly to present a protocol walkthrough that considers the=20= different types of messages that can be used in a multi6 protocol. several choices need to be made. I guess that when we decide which are=20= the preffered options, we will be able to provide a more complete=20 analysis do you think that for a prelimary analysis is there something very big=20= that is missing in the draft? thanks, marcelo El 29/10/2004, a las 14:49, Brian E Carpenter escribi=F3: > Just one comment at the moment: this draft doesn't cover > *all* the functional components detailed in Section 6 > of draft-ietf-multi6-architecture-02.txt. > That should probably be noted in the introduction. > > (Incidentally, reference [3] points to an obsolete > draft.) > > Brian > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Sun Oct 31 11:16:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10188 for ; Sun, 31 Oct 2004 11:16:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COILc-000KTR-8Z for multi6-data@psg.com; Sun, 31 Oct 2004 16:14:28 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COILT-000KSv-DB for multi6@ops.ietf.org; Sun, 31 Oct 2004 16:14:19 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6C2402FAC9; Sun, 31 Oct 2004 17:14:18 +0100 (CET) Received: from [163.117.252.45] (unknown [163.117.252.45]) by smtp03.uc3m.es (Postfix) with ESMTP id 62EB52FAC8; Sun, 31 Oct 2004 17:14:15 +0100 (CET) In-Reply-To: <4182B26D.2050306@sun.com> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> Content-Transfer-Encoding: 7bit Cc: Multi6 , Brian E Carpenter From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Sat, 30 Oct 2004 20:55:37 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Good news. This is wrong (and I didn't realise it when analyzing >> NOID). >> Flow Labels are not unique on their own and cannot be used for >> anything on their own. You must always lookup a 3tuple.But if the >> received {Flow Label, Source Locator, Dest Locator} is in the set >> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to >> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim >> *knows* that it is a multi6 packet. > > If the {flow label, src locator, dst locator} is used to identify the > state then you are right. But that prevents a possible optimization > with changing locator sets (think mobility) by requiring that multi6 > signaling be complete to tell the peer of the new locator before that > locator can be used as the source. > well, but in this case, there is also some security information nneded to authenticate the new locator, so the receiver will have additional information for the demux of this packet i guess. regards, marcelo ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------