From yoav@yitran.com Sat Dec 3 23:23:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704621F8876 for ; Sat, 3 Dec 2011 23:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mj3amqXDF7s for ; Sat, 3 Dec 2011 23:23:36 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id 13CD321F85BB for ; Sat, 3 Dec 2011 23:23:34 -0800 (PST) Received: from mail-ww0-f50.google.com ([74.125.82.50]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTtsf17k4Qn+nUq2lnX7GVY4ZkFIsPUS+@postini.com; Sat, 03 Dec 2011 23:23:35 PST Received: by wgbdr11 with SMTP id dr11so3560226wgb.7 for ; Sat, 03 Dec 2011 23:23:02 -0800 (PST) Received: by 10.227.205.197 with SMTP id fr5mr11805346wbb.3.1322983381257; Sat, 03 Dec 2011 23:23:01 -0800 (PST) From: Yoav Ben-Yehezkel References: <0368F388C03BB34BBBFA73209849D47A4EE53D93@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4EE53D93@ITR-EXMBXVS-2.itron.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxJKd0A3EZlFLNk7IBboWnEs17sgK1/LM5lWyp9LA= Date: Sun, 4 Dec 2011 09:20:56 +0200 Message-ID: <15020263cb81fb68e5e09ccb446e76fc@mail.gmail.com> To: "Jetcheva, Jorjeta" , roll@ietf.org Content-Type: multipart/related; boundary=000e0cdf9ac27bce8c04b33f12b2 Subject: Re: [Roll] RPL AMI Applicability Internet-Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 07:23:37 -0000 --000e0cdf9ac27bce8c04b33f12b2 Content-Type: multipart/alternative; boundary=000e0cdf9ac27bce7c04b33f12b1 --000e0cdf9ac27bce7c04b33f12b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I=92ve reviewed the draft, and have a question about section 4.1.4 (path metrics, see below). I=92m not sure that the ETX metric should be noted as the preferred one, wh= en the use case is wide range of varying link rates (in IEEE P1901.2 that is mentioned in this draft the rates range from a few kbps to a few hundreds of kbps). Would the authors be willing to include a note about this issue? I was given some inputs from the ROLL WG that ETT (Expected Transmission Time) or throughput might be more suitable metrics under such conditions. The related ROLL mailing list threads are: http://www.ietf.org/mail-archive/web/roll/current/msg06564.html and http://www.ietf.org/mail-archive/web/roll/current/msg06565.html Best regards, Yoav *4.1.4**. Path Metrics* Smart metering deployments utilize link technologies that may exhibit significant packet loss and thus require routing metrics that take packet loss into account. To characterize a path over such link technologies, AMI deployments can use the Expected Transmission Count (ETX) metric as defined in[I-D.ietf-roll-routing-metrics]. *From:* OpenSG SG Communications WG SG Network Task Force [mailto: OPENSG-SGCOMM-SGNET@SMARTGRIDLISTSERV.ORG] *On Behalf Of *Jetcheva, Jorjeta *Sent:* Friday, December 02, 2011 10:05 PM *To:* OPENSG-SGCOMM-SGNET@SMARTGRIDLISTSERV.ORG *Subject:* RPL AMI Applicability Internet-Draft Hi everyone, In case anyone is interested, the latest version of the RPL AMI Applicability Internet-Draft I mentioned on our last call can be found at http://tools.ietf.org/html/draft-ietf-roll-applicability-ami-05. Jorjeta [image: http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg] *Jorjeta Jetcheva, Ph.D.*** Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [image: http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg= ] [image: http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg] [image: http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg] [image: http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg] --000e0cdf9ac27bce7c04b33f12b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I=92ve reviewed the dr= aft, and have a question about section 4.1.4 (path metrics, see below).

I=92m not sure = that the ETX metric should be noted as the preferred one, when the use case= is wide range of varying link rates (in IEEE P1901.2 that is mentioned in = this draft the rates range from a few kbps to a few hundreds of kbps).

Would the authors be w= illing to include a note about this issue? I was given some inputs from the= ROLL WG that ETT (Expected Transmission Time) or throughput might be more = suitable metrics under such conditions.

=A0

The related ROLL mailing list = threads are: http://www.ietf.org/mail-archive/web/roll/current/msg0= 6564.html and http://www.ietf.org= /mail-archive/web/roll/current/msg06565.html

=A0

Best regards,

Yoav

=A0

=A0

4.1.4= .=A0 Path Metrics

=A0=A0 Smart metering deployments utilize link technologie= s that may exhibit

=A0=A0 significant packet los= s and thus require routing metrics that take

=A0=A0 packet loss into account.=A0 To characterize a path= over such link

=A0=A0 technologies, AMI deploym= ents can use the Expected Transmission Count

=A0=A0 (ETX) metric as defined in[I-D.ietf-roll-routing-me= trics].

=A0

=A0

=A0<= /p>

=A0

From: OpenSG SG Communications WG SG Network Task Force [mailto:OPENSG-SGCOMM-SGNET@SMART= GRIDLISTSERV.ORG] On Behalf Of Jetcheva, Jorjeta
Sent: Friday, December 02, 2011 10:05 PM
To: OPENSG-SGCOMM-SGNET@SMARTGR= IDLISTSERV.ORG
Subject: RPL AMI Applicability Internet-Draft<= /span>

=A0

Hi everyone,

=A0

In case anyone is interes= ted, the latest version of the RPL AMI Applicability Internet-Draft I menti= oned on our last call can be found at http://tools.ietf.org/html/dr= aft-ietf-roll-applicability-ami-05.

=A0

Jorjeta

=A0

3D"http://marketing.itr=

Jorjeta Jetcheva, Ph.D.<= /b>

Strategic Industry Standards and A= rchitecture

Office of the CTO
Mobile: = +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marke==A0=A0=A03D"http://marketing.itron.com/campaign/social_media_icon_faceboo==A0=A0=A03D"http://marketing.==A0=A0=A03D"http://marketing.itron.com/campaign/social_media_icon_youtu=

=A0

=A0

--000e0cdf9ac27bce7c04b33f12b1-- --000e0cdf9ac27bce8c04b33f12b2 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 11bcc992778f284a_0.1 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --000e0cdf9ac27bce8c04b33f12b2 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 11bcc992778f284a_0.2 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --000e0cdf9ac27bce8c04b33f12b2 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 11bcc992778f284a_0.3 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --000e0cdf9ac27bce8c04b33f12b2 Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 11bcc992778f284a_0.4 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --000e0cdf9ac27bce8c04b33f12b2 Content-Type: image/jpeg; name="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 11bcc992778f284a_0.5 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --000e0cdf9ac27bce8c04b33f12b2-- From pthubert@cisco.com Fri Dec 9 06:29:38 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B721F8593 for ; Fri, 9 Dec 2011 06:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.754 X-Spam-Level: X-Spam-Status: No, score=-10.754 tagged_above=-999 required=5 tests=[AWL=1.844, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFW-AvC6nYt6 for ; Fri, 9 Dec 2011 06:29:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF05821F8509 for ; Fri, 9 Dec 2011 06:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=72558; q=dns/txt; s=iport; t=1323440972; x=1324650572; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pgJlK+HJwPW2ag3f/9UlwrFltiYNdqhD+FZP7JQg2xk=; b=XxZm7Lnz/k2z7UDXAnXdhpLKHyVk96v0KRd+oEklrld246vjTD4mDZg3 Sv/ZDUNc9BBeO0A++ZkQJO1PwiiOPGfg1bJY3r2x6/HN35vcBXjJl1jHX KUbfM/eBr0dEylT06CU0NqU2rSofoIxuzNJKVL8u55zXipAbJ55o9vgUH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABsa4k6Q/khL/2dsb2JhbABDgk2COaRbgRiBBYFyAQEBBAwGAQkHCgNJEAIBCAQNBAEBCwYXAQICAgEBRAkIAQEEAQkJCBMHn1cBjFuRQopcM2MEpxg X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208,217";a="60948067" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Dec 2011 14:29:30 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB9ETUKk007783; Fri, 9 Dec 2011 14:29:30 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 15:29:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCB67E.F5EE91EC" Date: Fri, 9 Dec 2011 15:28:31 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mail regarding draft-thubert-roll-asymlink Thread-Index: Acyu04PCqW7QkuVjRCeei851PmupjAHqzNCg References: From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , X-OriginalArrivalTime: 09 Dec 2011 14:29:29.0972 (UTC) FILETIME=[F6353B40:01CCB67E] Cc: roll@ietf.org Subject: Re: [Roll] Mail regarding draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:29:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB67E.F5EE91EC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CCB67E.F5EE91EC" ------_=_NextPart_002_01CCB67E.F5EE91EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Yoav: =20 I just published the new version of the draft that accounts for your comments. =20 Thanks again! =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: mardi 29 novembre 2011 21:20 To: draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: [Roll] Mail regarding draft-thubert-roll-asymlink =20 Dear Roll-ers, Find below comments to the draft.=20 Mostly editorial, I hope they make sense. Best regards, Yoav =20 Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace "In one hand" with "On one hand"=20 2. Replace "on the other," with "on the other hand,". 3. Replace "whether links are based on radios or power-line" with "such as wireless radio or power-line links." =20 Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. =20 4. Replace "that the quality of both directions of a link is evaluated as very good" with "that the quality of both directions of a link is evaluated as operational at an acceptable level" - because they do not necessarily have to be very good. =20 Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term "instance" be replaced with the term "RPL instance"?=20 2. What does "general direction of the root" means? Shouldn't it simply be "towards the root"? 3. Replace "though may be usable but suboptimal for traffic coming form the direction of the root" with "though may be usable but suboptimal for traffic coming from the direction of the root" (form=3Dfrom) 4. Replace "The term downwards qualifies the same words for the opposite direction" with "The term downwards qualifies the same wording, only for opposite directions" 5. Question: shouldn't the terms "upwards" and "downwards" be included into the terminology draft? =20 =20 bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. =20 1. Replace "possible in both direction" with "possible in both directions" (missing 's'). =20 asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace "A link is assymetric" with "A link is asymmetric" (typo) 2. Replace "important" with "major" =20 Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. =20 Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and =20 downwards traffic;=20 1. Replace "very good" with "operational at an acceptable level". =20 In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. =20 1. Replace "can not" with "cannot". =20 OTOH, with RPL as it is specified,... 1. Replace "OTOH" with "On the other hand". =20 ... so that a node may transfer traffic from an instance onto another. 1. Replace "an instance onto another" with "an upwards instance onto the downwards instance". =20 Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace "and reset otherwise" with "and is reset otherwise". 2. Replace "upwards direction" with "upwards", or add the word "direction" to all subsequence indications of the word "downwards" 3. Replace "will be considered downwards" with "shall be considered downwards". =20 Comments to Operations section 6: =20 This specification allows an organization of Instances as follows: 1. Replace "Instances" with "instances" (non-capitalized 'I') =20 The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace "a MOP of 0 means" with "a MOP set to a value 0 indicates" 3. Replace "and otherwise is downwards" with "and indicates downwards if set otherwise". =20 Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. =20 1. Replace "if" with "is" 2. Remove "generally" and "general" or explain what they mean. 3. Replace "put in place" with "used" 4. Replace "ovreride" with "override" =20 Comments to Backward compatibility section 7: 1. Replace "Backward" with "Backwards" 2. Replace "compatibility" with "Compatibility" (capital 'C') =20 An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation.=20 1. Replace "diffent" with "different" 2. Missing space between "thus" and "obtain" =20 An OF that supports directional links SHOULD favor directional links over non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace "specified with the OF" with "specified by the OF" 2. Replace "section 4.2.1.," with "section 4.2.1," (remove extra dot) 3. =20 4. Replace "that is before Ranks and be calculated and compared" with "that is before ranks are calculated and compared" (is there anything else that needs comparison other than the rank?) =20 Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace "a bit in DIO be assigned" with "a bit in DIO shall be assigned" 2. Replace "as specified in section" with "as specified in section 5" =20 Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace "Security Considerations for this proposal" in the first line with "Security considerations for this proposal" (non-capitalized 'c') =20 =20 =20 =20 =20 =20 ------_=_NextPart_002_01CCB67E.F5EE91EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Yoav:

 

I just = published the new version of the draft that accounts for your = comments.

 

Thanks = again!

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Yoav Ben-Yehezkel
Sent: mardi 29 novembre 2011 = 21:20
To: = draft-thubert-roll-asymlink@tools.ietf.org
Cc: = roll@ietf.org
Subject: [Roll] Mail regarding = draft-thubert-roll-asymlink

 

Dear Roll-ers,

Find below comments to the draft. =

Mostly = editorial, I hope they make sense.

Best = regards,

Yoav

 

Comments to = Introduction section 1:

   In one hand, RPL requires bi-directional links for = the control, but

   on the = other, there is no requirement that the properties of a link

   are the same in both directions.  In fact, a = perfect symmetry is

   rarely = present in Low Power and Lossy Networks (LLNs), whether = links

   are = based on radios or power-line.

1.       = Replace “In one = hand” with “On one hand”

2.       = Replace “on the = other,” with “on the other = hand,”.

3.       = Replace “whether = links are based on radios or power-line” with “such as = wireless radio or power-line = links.”

 
   Some initial implementations require that the =
quality of both
   directions of a link is evaluated as very good =
so that the link can
   be used for control and data in both =
directions.  This eliminates
   asymmetrical links that are very good in one =
direction, but only good
   enough for scarce activity in the other =
direction.

 

4.       = Replace “that = the quality of both directions of a link is evaluated as very = good” with “that the quality of both directions of a link is = evaluated as operational at an acceptable level” – because = they do not necessarily have to be very good.

 

Comments to = Terminology section 2:

   =
The term upwards qualifies a link, a DODAG or an instance that =
is
   optimal =
for sending traffic in the general direction of the =
root,
   though =
may be usable but suboptimal for traffic coming form =
the
   =
direction of the root.  The term downwards qualifies the same =
words
   for =
the opposite direction.

1.       = Should the term = “instance” be replaced with the term “RPL = instance”?

2.       = What does = “general direction of the root” means? Shouldn’t it = simply be “towards the root”?

3.       = Replace “though = may be usable but suboptimal for traffic coming form the = direction of the root“ with “though may be usable but = suboptimal for traffic coming from the direction of the = root” (form=3Dfrom)

4.       = Replace “The = term downwards qualifies the same words for the opposite = direction” with “The term downwards qualifies the same = wording, only for opposite = directions”

5.       = Question: = shouldn’t the terms “upwards” and = “downwards” be included into the terminology = draft?

 
 
   bi-directional:  A link is bi-directional =
when traffic confirmed
      possible in both direction, =
in a fashion that is sufficient to
      operate RPL =
control.
 

1.       = Replace = “possible in both direction” with “possible in both = directions” (missing = ‘s’).

 
   asymmetric:  A link is assymetric if it =
is bi-directional, but
      exhibits important =
differences in link characteristics for =
both
      =
directions.

1.       = Replace “A link = is assymetric” with “A link is = asymmetric” (typo)

2.       = Replace = “important” with “major”

 

Comments to =
The asymmetrical link problem section =
3:

1.       = Capitalize first = letter of each word like in all other = sections.

 
Comments to Solution Overview =
section 4:
   One direct consequence of that =
design
   =
choice is that a topology must be very good for both upwards =
and
 
   downwards traffic;

1.       = Replace “very = good” with “operational at an acceptable = level”.

 

  =
 In that case, an asymmetrical =
link,
   that =
can only be used for traffic in one direction, can =
not
   =
participate to the routing topology. 

1.       = Replace “can = not” with “cannot”.

 
   OTOH, with RPL as it is =
specified,...

1.       = Replace = “OTOH” with “On the other = hand”.

 
   ... so that a node may transfer traffic from =
an instance onto another.

1.       = Replace “an = instance onto another” with “an upwards instance onto the = downwards instance”.

 
Comments to Modified DIO section =
5:
   =
Directional (D):  The Directional (D) flag is set to indicate =
that
         the =
instance is intended for directional operation, and =
reset
         =
otherwise.  When it is set, a MOP of 0 indicates the =
upwards
         direction =
whereas any other value specified in
         =
[I-D.ietf-roll-rpl] indicates downwards.  All other values =
of
         MOP will =
be considered downwards unless explicitly =
specified
         =
otherwise.

1.       = Replace “and = reset otherwise” with “and is reset = otherwise”.

2.       = Replace “upwards = direction” with “upwards”, or add the word = “direction” to all subsequence indications of the word = “downwards”

3.       = Replace “will be = considered downwards” with “shall be considered = downwards”.

 

Comments to Operations section =
6:
 
   This specification allows an organization of =
Instances as follows:

1.       = Replace = “Instances” with “instances” (non-capitalized = ‘I’)

 
      The direction is indicated =
by the MOP field, a MOP of 0 means
      upwards and otherwise is =
downwards.

2.       = Replace “a MOP = of 0 means” with “a MOP set to a value 0 = indicates”

3.       = Replace “and = otherwise is downwards” with “and indicates downwards if set = otherwise”.

 

  =
    Transferring from an upwards instance to a =
downwards instance if
      generally desirable. Other =
forms of transfers are generally not
      desirable.  Policies =
MAY be put in place to ovreride that =
general
      =
guidance.
 

1.       = Replace = “if” with “is”

2.       = Remove = “generally” and “general” or explain what they = mean.

3.       = Replace “put in = place” with “used”

4.       = Replace = “ovreride" with = “override”

 

Comments to Backward compatibility =
section 7:

1.       = Replace = “Backward” with = “Backwards”

2.       = Replace = “compatibility” with “Compatibility” (capital = ‘C’)

 

   An OF is generally designed to compute a Rank =
of a directional link
   in a fashion that is diffent from a =
bidirectional link, and in
   particular will not use the same metrics and =
thusobtain different
   ranks for a same situation. =

1.       = Replace = “diffent” with = “different”

2.       = Missing space between = “thus” and “obtain”

 

   An OF that supports directional links SHOULD =
favor directional links over
   non directional links, in a fashion that is to =
be specified with the
   OF.  In the case of OF0 =
[I-D.ietf-roll-of0], the 'D' flag should =
be
   accounted =
for before the computation of item 8 in the "Selection =
Of
   The =
Preferred Parent" section 4.2.1., that is before Ranks and =
be
   =
calculated and compared.

1.       = Replace = “specified with the OF” with “specified by the = OF”

2.       = Replace “section = 4.2.1.,” with “section 4.2.1,” (remove extra = dot)

3.   
4.  Replace =
“that is before Ranks and be calculated and compared” =
with “that is before ranks are calculated and =
compared” (is there anything else that needs comparison other than =
the rank?)

 

Comments to IANA Considerations =
section 8:
   This specification requires that a bit in DIO =
be assigned to indicate
   directional link operations as specified in =
section

1.       = Replace “a bit = in DIO be assigned” with “a bit in DIO shall be = assigned”

2.       = Replace “as = specified in section” with “as specified in section = 5”

 

Comments to Security Considerations =
section 9:
   Security Considerations for this proposal are =
to be developed in
   accordance with recommendations laid out in, =
for example,
   =
[I-D.tsao-roll-security-framework].

1.       = Replace = “Security Considerations for this proposal” in the = first line with “Security considerations for this = proposal” (non-capitalized = ‘c’)

 

 

 
 
 

 

------_=_NextPart_002_01CCB67E.F5EE91EC-- ------_=_NextPart_001_01CCB67E.F5EE91EC Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-108.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 15:24:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CCB67E.46641380" Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 15:24:35 +0100 Received: from rcdn-iport-1.cisco.com ([173.37.86.72]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 08:24:29 -0600 Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 09 Dec 2011 14:24:23 +0000 Received: from rcdn-inbound-f.cisco.com (rcdn-inbound-f.cisco.com [72.163.7.175]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pB9EOL0Q019582 for ; Fri, 9 Dec 2011 14:24:23 GMT Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-f.cisco.com with ESMTP; 09 Dec 2011 14:24:22 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944E921F853A for ; Fri, 9 Dec 2011 06:24:22 -0800 (PST) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDmYqFZuDS8m for ; Fri, 9 Dec 2011 06:24:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FB921F8510; Fri, 9 Dec 2011 06:24:22 -0800 (PST) Content-class: urn:content-classes:message Subject: New Version Notification for draft-thubert-roll-asymlink-02.txt Date: Fri, 9 Dec 2011 15:24:22 +0100 Message-ID: <20111209142422.26974.17256.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-roll-asymlink-02.txt Thread-Index: Acy2fkaDAUhCNAyKSbSdNfI9r8RSBA== From: To: "Pascal Thubert (pthubert)" Cc: "Pascal Thubert (pthubert)" This is a multi-part message in MIME format. ------_=_NextPart_003_01CCB67E.46641380 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMi50eHQg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGh1YmVydC1y b2xsLWFzeW1saW5rDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBSUEwgYWRhcHRhdGlvbiBmb3Ig YXN5bW1ldHJpY2FsIGxpbmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMi0wOQ0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQoNCkFic3RyYWN0Og0K ICAgVGhlIFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3Mg ZGVmaW5lcyBhDQogICBnZW5lcmljIERpc3RhbmNlIFZlY3RvciBwcm90b2NvbCBmb3IgTG93IFBv d2VyIGFuZCBMb3NzeSBOZXR3b3JrcywNCiAgIG1hbnkgb2Ygd2hpY2ggZXhoaWJpdCBzdHJvbmds eSBhc3ltbWV0cmljYWwgY2hhcmFjdGVyaXN0aWNzLiAgVGhpcw0KICAgZHJhZnQgcHJvcG9zZXMg YW4gZXh0ZW5zaW9uIGZvciB0aGF0IG9wdGltaXplcyBSUEwgb3BlcmF0aW9ucyB3aGVyZWJ5DQog ICB1cHdhcmRzIGFuZCBkb3dud2FyZHMgZGlyZWN0aW9uLW9wdGltaXplZCBSUEwgaW5zdGFuY2Vz IGFyZQ0KICAgYXNzb2NpYXRlZC4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg== ------_=_NextPart_003_01CCB67E.46641380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTUuMTAiPg0KPFRJVExFPk5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC1yb2xsLWFzeW1saW5rLTAyLnR4dDwvVElU TEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3Jt YXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1 YmVydC1yb2xsLWFzeW1saW5rLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RmlsZW5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluazwvRk9OVD4N Cg0KPEJSPjxGT05UIFNJWkU9Mj5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMDI8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+VGl0bGU6Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSUEwgYWRh cHRhdGlvbiBmb3IgYXN5bW1ldHJpY2FsIGxpbmtzPC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0y PkNyZWF0aW9uIGRhdGU6Jm5ic3A7Jm5ic3A7IDIwMTEtMTItMDk8L0ZPTlQ+DQoNCjxCUj48Rk9O VCBTSVpFPTI+V0cgSUQ6Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248L0ZPTlQ+DQoNCjxCUj48Rk9OVCBT SVpFPTI+TnVtYmVyIG9mIHBhZ2VzOiAxMDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PkFic3RyYWN0OjwvRk9OVD4NCg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgVGhlIFJv dXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgZGVmaW5lcyBh PC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyBnZW5lcmljIERpc3RhbmNl IFZlY3RvciBwcm90b2NvbCBmb3IgTG93IFBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcyw8L0ZPTlQ+ DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IG1hbnkgb2Ygd2hpY2ggZXhoaWJpdCBz dHJvbmdseSBhc3ltbWV0cmljYWwgY2hhcmFjdGVyaXN0aWNzLiZuYnNwOyBUaGlzPC9GT05UPg0K DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyBkcmFmdCBwcm9wb3NlcyBhbiBleHRlbnNp b24gZm9yIHRoYXQgb3B0aW1pemVzIFJQTCBvcGVyYXRpb25zIHdoZXJlYnk8L0ZPTlQ+DQoNCjxC Uj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IHVwd2FyZHMgYW5kIGRvd253YXJkcyBkaXJlY3Rp b24tb3B0aW1pemVkIFJQTCBpbnN0YW5jZXMgYXJlPC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0y PiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkLjwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQg U0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8L1A+DQo8QlI+ DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGUgSUVURiBTZWNyZXRhcmlhdDwvRk9OVD4NCjwvUD4NCg0K PC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_003_01CCB67E.46641380-- ------_=_NextPart_001_01CCB67E.F5EE91EC-- From prvs=3280cf979=mukul@uwm.edu Tue Dec 20 08:14:22 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCC321F8B8A; Tue, 20 Dec 2011 08:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r67z-Dkyn9r3; Tue, 20 Dec 2011 08:14:22 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8C821F8B7D; Tue, 20 Dec 2011 08:14:21 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 20 Dec 2011 10:14:21 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id ECD0F2B3EDA; Tue, 20 Dec 2011 10:12:34 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzcRm0EmTauY; Tue, 20 Dec 2011 10:12:34 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C2CBD2B3ED8; Tue, 20 Dec 2011 10:12:34 -0600 (CST) Date: Tue, 20 Dec 2011 10:14:21 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1076398681.709387.1324397661047.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055FAFECB2B53642884D29B0094D14751098099F@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:14:22 -0000 Jonathan The IESG-approved draft refers to the RPL instance as the scope where the routing header can be used. How would this routing header be used for general source routing (across RPL instances) in an LLN? How would a node use this routing header if it wants to travel along a source route discovered using P2P-RPL? Thanks Mukul From jonhui@cisco.com Tue Dec 20 08:27:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4121F84CD for ; Tue, 20 Dec 2011 08:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zarm0tplRXMS for ; Tue, 20 Dec 2011 08:27:30 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83821F8484 for ; Tue, 20 Dec 2011 08:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=687; q=dns/txt; s=iport; t=1324398450; x=1325608050; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=b1lgwPZxc4W9mc2E9Ka3mcDQQLvz1hSCoGv4w39HcJc=; b=boTjLaEdzphUtdKwRMeCiyTXpzhearFhcKP7QKGbiRx6JScreXpI5dVF UxcmLxSJBZ1T+xWaCqjqxYPZDaPgw7m9Qu+GqXw8mBPZuOWLUfDyxmH3O 08K56pPcI3KPhf1Zxzn+NAxpNEK57FveTSzve9t61MOFGyv2WmZCD61mG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL228E6rRDoI/2dsb2JhbABDDqtygQWBcgEBAQMBEgEnPwULC0ZXBjWHWJhfAZ48iyljBIg3jEiReVg X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; d="scan'208";a="21715504" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 20 Dec 2011 16:27:30 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBKGRTYu002728; Tue, 20 Dec 2011 16:27:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <1076398681.709387.1324397661047.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Tue, 20 Dec 2011 08:27:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1076398681.709387.1324397661047.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:27:30 -0000 Mukul, As defined in the draft today, you cannot use a RPL routing header to = cross RPL Instances. My understanding is that roll-p2p-rpl makes use of = local RPL instances. Can you describe the issue you are concerned = about? -- Jonathan Hui On Dec 20, 2011, at 8:14 AM, Mukul Goyal wrote: > Jonathan >=20 > The IESG-approved draft refers to the RPL instance as the scope where = the routing header can be used. How would this routing header be used = for general source routing (across RPL instances) in an LLN? How would a = node use this routing header if it wants to travel along a source route = discovered using P2P-RPL? >=20 > Thanks > Mukul >=20 From prvs=329774bb4=mukul@uwm.edu Wed Dec 21 09:24:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513C511E8098; Wed, 21 Dec 2011 09:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGXDLnYc8BxE; Wed, 21 Dec 2011 09:24:28 -0800 (PST) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 426D511E8094; Wed, 21 Dec 2011 09:24:28 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 21 Dec 2011 11:24:27 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 84EEA2B3EDD; Wed, 21 Dec 2011 11:22:40 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icawGKjDVtOb; Wed, 21 Dec 2011 11:22:40 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 54F872B3EDA; Wed, 21 Dec 2011 11:22:40 -0600 (CST) Date: Wed, 21 Dec 2011 11:24:27 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <2121048960.723525.1324488267237.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <439AF687-83D0-4581-A4EB-13104047B41C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:24:29 -0000 Hi Jonathan I have serious issues with the use of RPL Instance as the domain for SRH. >>[R Cragie] >> p7: RPL Instance ID - why is this needed for source routing? RPL is not even used for source routing. This flavors the SRH unnecessarily and the processing does not use it. If the reason is for checking entering and exiting a RPL domain, this processing needs to be stated. >[J Hui] >Page 12 describes processing rules intended to keep the SRH within a RPL Instance. Page 12 has no mention of RPL Instance. Page 13 does mention RPL Instance in the following rules: 2. Datagrams destined elsewhere within the same RPL Instance are forwarded to the correct interface. 3. Datagrams destined to nodes outside the RPL Instance are dropped if the outer-most IPv6 header contains a SRH not generated by the RPL router forwarding the datagram. My question is how does a router know whether the next hop is within the same RPL Instance or not? A router has no idea what RPL Instances its neighbors belong to. It seems that a router, that receives a packet with a SRH, does not need to check if it belongs to the RPL Instance mentioned in the SRH. It just needs to check if the next hop belongs to that RPL Instance or not. And as I said in the prev para, I am not sure how would the router make that check. It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain any state about it. Thanks Mukul From prvs=329774bb4=mukul@uwm.edu Wed Dec 21 09:26:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7607111E8098; Wed, 21 Dec 2011 09:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg1ZV6O+VsZa; Wed, 21 Dec 2011 09:26:59 -0800 (PST) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id DC92D11E8094; Wed, 21 Dec 2011 09:26:58 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 21 Dec 2011 11:26:42 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0303A12E3CC; Wed, 21 Dec 2011 11:26:43 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua8IxB6ARJzZ; Wed, 21 Dec 2011 11:26:42 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C73C612E3CD; Wed, 21 Dec 2011 11:26:42 -0600 (CST) Date: Wed, 21 Dec 2011 11:26:42 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <557570317.723557.1324488402749.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6 Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:26:59 -0000 Jonathan I described the problem in the message I sent just now. I think RPL Instance is not the correct scope for SRH. It has to be a RPL domain to be defined as we discussed some time back on the ROLL list. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "roll" Sent: Tuesday, December 20, 2011 10:27:29 AM Subject: Re: draft-ietf-6man-rpl-routing-header-07 Mukul, As defined in the draft today, you cannot use a RPL routing header to cross RPL Instances. My understanding is that roll-p2p-rpl makes use of local RPL instances. Can you describe the issue you are concerned about? -- Jonathan Hui On Dec 20, 2011, at 8:14 AM, Mukul Goyal wrote: > Jonathan > > The IESG-approved draft refers to the RPL instance as the scope where the routing header can be used. How would this routing header be used for general source routing (across RPL instances) in an LLN? How would a node use this routing header if it wants to travel along a source route discovered using P2P-RPL? > > Thanks > Mukul > From jonhui@cisco.com Wed Dec 21 10:07:11 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6121F8491; Wed, 21 Dec 2011 10:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzhRcYRawQ7d; Wed, 21 Dec 2011 10:07:11 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 505C121F841B; Wed, 21 Dec 2011 10:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=3021; q=dns/txt; s=iport; t=1324490831; x=1325700431; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BFwNogzvgSia6ijRzKNdlZ4L861D9pBqfbOgkGOCahA=; b=KgFNH7BYtMKmJQPpwqxB2rbk/1MBwx+wNdZUgX4J3OY7GSegSF1cyT3k CM0EYhqg5eTtbAYr51Il3DTEnqzXUmr9VzZBT37C0MMzCnCuxJDXJSbrj K3mUeojyNUGmj4m8OUPRUjyGvCFtj0nNOCywJLH+HanT0nuzM9BQxPFoS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALof8k6rRDoI/2dsb2JhbABDDqwPgQWBcgEBAQMBEgEnPwULC0ZXBjWHWJkzAZ5MiyxjBIg3jEiRe1g X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; d="scan'208";a="21936825" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 21 Dec 2011 18:07:09 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBLI79gQ021997; Wed, 21 Dec 2011 18:07:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <2121048960.723525.1324488267237.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 21 Dec 2011 10:07:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <55AAC580-DC07-4DAC-BAB0-A3DF27A11565@cisco.com> References: <2121048960.723525.1324488267237.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:07:12 -0000 On Dec 21, 2011, at 9:24 AM, Mukul Goyal wrote: >>> [R Cragie] >>> p7: RPL Instance ID - why is this needed for source routing? RPL is = not even used for source routing. This flavors the SRH unnecessarily and = the processing does not use it. If the reason is for checking entering = and exiting a RPL domain, this processing needs to be stated. >=20 >> [J Hui] >> Page 12 describes processing rules intended to keep the SRH within a = RPL Instance. Oops, typo. s/12/13/ > Page 12 has no mention of RPL Instance. Page 13 does mention RPL = Instance in the following rules: >=20 > 2. Datagrams destined elsewhere within the same RPL Instance are > forwarded to the correct interface. >=20 > 3. Datagrams destined to nodes outside the RPL Instance are dropped > if the outer-most IPv6 header contains a SRH not generated by = the > RPL router forwarding the datagram. >=20 > My question is how does a router know whether the next hop is within = the same RPL Instance or not? A router has no idea what RPL Instances = its neighbors belong to.=20 >=20 > It seems that a router, that receives a packet with a SRH, does not = need to check if it belongs to the RPL Instance mentioned in the SRH. It = just needs to check if the next hop belongs to that RPL Instance or not. = And as I said in the prev para, I am not sure how would the router make = that check. It knows whether or not RPL is running on an interface. It could at = least check that. By the same argument, how do you propose we limit = packets to a RPL routing domain? If we have no good way of limiting = packets, then the stated security considerations do not apply. > It would be a problem if the router were required to check its own = membership in the RPL Instance in order to accept a packet with SRH. = Routers part of a source route should not need to maintain any state = about it.=20 Note that in draft-ietf-roll-rpl, RPL routers do maintain such state = already. I agree the issue comes up with P2P. Remember that the original purpose of the RPL Instance is to support = MTR. The RPL Instance identifies what routing topology to use. This is = important especially if the SRH does not specify the entire path to the = destination. How does the tunnel exit-point know what routing topology = to use to reach the destination? The lack of and need for the RPL Instance identifier was raised during = IESG review. The options are (1) to require inclusion a RPL Option in = addition to the RPL routing header or (2) add a RPL Instance field in = the RPL routing header itself. I doubt that you would prefer option 1. If the RPL router has no idea of the RPL Instance when forwarding, it = can choose to forward the packet along anyway. At the very least, the = tunnel exit-point should enforce the use of the RPL Instance. Surely = the end-points of a source route should at least know what RPL Instance = they are in... -- Jonathan Hui From jonhui@cisco.com Wed Dec 21 10:22:12 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C303D21F8540; Wed, 21 Dec 2011 10:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnopPf3DU5rv; Wed, 21 Dec 2011 10:22:12 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2447F21F849C; Wed, 21 Dec 2011 10:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=1752; q=dns/txt; s=iport; t=1324491732; x=1325701332; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cOqcNIutCIUJceOtJipDBranyoErRV2aUvaBcj6CyAk=; b=J4QTPBW+T+3rNJoztOt6iIvH6Yjc4opMZq8apkzegQINkdLkysV+I7Fl GZdYp57nYa2NRNm60sPvSD/XRwuk11Qo4NeJLMljib6Rje+KX3Ld1RIO/ kNBR7ghmDqJyBUelACrolgCa7phtcp+HpZ7p0oVLgakQo12tbmzwP+fRX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAALYi8k6rRDoJ/2dsb2JhbABDDps4kFeBBYFyAQEBAwESASc/BQcECxEEAQEBLk8IBgESIodYmS4BnkyLLGMEiDeMSJF7WA X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; d="scan'208";a="20223423" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 21 Dec 2011 18:22:11 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBLIMBIo024547; Wed, 21 Dec 2011 18:22:11 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <557570317.723557.1324488402749.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 21 Dec 2011 10:22:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A89D3D3-1DA6-4698-BC4A-B8AEBE397906@cisco.com> References: <557570317.723557.1324488402749.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal , Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: roll WG , ipv6 Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:22:12 -0000 Personally, I am OK changing the scope to a RPL routing domain rather = than a RPL Instance. If one really wants to limit to a RPL Instance, = then they can also include a RPL Option. This is what we originally had = in rpl-routing-header-05. This change was made late during the IESG = review process. Jari, would you support reverting the scope of the RPL SRH to a RPL = routing domain rather than a RPL Instance? Thanks. -- Jonathan Hui On Dec 21, 2011, at 9:26 AM, Mukul Goyal wrote: > Jonathan >=20 > I described the problem in the message I sent just now. I think RPL = Instance is not the correct scope for SRH. It has to be a RPL domain to = be defined as we discussed some time back on the ROLL list. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "roll" > Sent: Tuesday, December 20, 2011 10:27:29 AM > Subject: Re: draft-ietf-6man-rpl-routing-header-07 >=20 >=20 > Mukul, >=20 > As defined in the draft today, you cannot use a RPL routing header to = cross RPL Instances. My understanding is that roll-p2p-rpl makes use of = local RPL instances. Can you describe the issue you are concerned = about? >=20 > -- > Jonathan Hui >=20 > On Dec 20, 2011, at 8:14 AM, Mukul Goyal wrote: >=20 >> Jonathan >>=20 >> The IESG-approved draft refers to the RPL instance as the scope where = the routing header can be used. How would this routing header be used = for general source routing (across RPL instances) in an LLN? How would a = node use this routing header if it wants to travel along a source route = discovered using P2P-RPL? >>=20 >> Thanks >> Mukul >>=20 >=20 From cedric-2.lavenu@edf.fr Wed Dec 21 13:03:56 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD93F11E80B9 for ; Wed, 21 Dec 2011 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N38ny3-3dLZB for ; Wed, 21 Dec 2011 13:03:56 -0800 (PST) Received: from mtagate2.edf.fr (mtagate2.edf.fr [192.54.193.62]) by ietfa.amsl.com (Postfix) with ESMTP id 079BD11E80B5 for ; Wed, 21 Dec 2011 13:03:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,389,1320620400"; d="scan'208,217";a="103732265" Received: from unknown (HELO xhub003au.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA2.edf.fr with ESMTP; 21 Dec 2011 22:00:38 +0100 Auto-Submitted: auto-generated From: Cedric-2 LAVENU To: roll@ietf.org Message-ID: Date: Wed, 21 Dec 2011 22:03:48 +0100 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=4EBBF3FEDFE032178f9e8a93df938690918c4EBBF3FEDFE03217" Content-Disposition: inline Subject: [Roll] Cedric-2 LAVENU est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 21:03:57 -0000 --0__=4EBBF3FEDFE032178f9e8a93df938690918c4EBBF3FEDFE03217 Content-type: text/plain; charset=US-ASCII Je serai absent(e) du 21/12/2011 au 05/01/2012. I will be out of office until january 5th. I will answer your email as soon as possible. Merry Christmas ! --0__=4EBBF3FEDFE032178f9e8a93df938690918c4EBBF3FEDFE03217 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Je serai absent(e) du 21/12/2011 au 05/01/2012.

I will be out of office until january 5th. I will answer your email as soon as possible.

Merry Christmas ! --0__=4EBBF3FEDFE032178f9e8a93df938690918c4EBBF3FEDFE03217-- From prvs=3304ccdf4=mukul@uwm.edu Wed Dec 21 17:15:53 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8B11E80C0 for ; Wed, 21 Dec 2011 17:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyznJhJkMLmn for ; Wed, 21 Dec 2011 17:15:53 -0800 (PST) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id EEEDE11E8096 for ; Wed, 21 Dec 2011 17:15:52 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 21 Dec 2011 19:15:51 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id CBE5F12E3C9; Wed, 21 Dec 2011 19:15:51 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnCk9qzNZiao; Wed, 21 Dec 2011 19:15:51 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A914012E3C6; Wed, 21 Dec 2011 19:15:51 -0600 (CST) Date: Wed, 21 Dec 2011 19:15:51 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <885849737.729755.1324516551604.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1395722419.729677.1324515316553.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] CmprI and CmprE in SRH X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 01:15:53 -0000 Hi Jonathan I think this was probably discussed earlier in your discussions with area director. But I was wondering if you could clarify again why do we need separate CmprI and CmprE? I think the last element in the Address vector specifies the ultimate destination (reachable using SRH) of the packet. Why would that destination need a separate number of elided prefix octets? Thanks Mukul From prvs=3304ccdf4=mukul@uwm.edu Wed Dec 21 18:10:36 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5B421F84B0; Wed, 21 Dec 2011 18:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxP9p2YyAvTv; Wed, 21 Dec 2011 18:10:35 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id A786F21F8491; Wed, 21 Dec 2011 18:10:35 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 21 Dec 2011 20:10:28 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B304E12E3CC; Wed, 21 Dec 2011 20:10:28 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFZQ646I298h; Wed, 21 Dec 2011 20:10:28 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 799CF12E3CA; Wed, 21 Dec 2011 20:10:28 -0600 (CST) Date: Wed, 21 Dec 2011 20:10:28 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <181400612.729968.1324519828382.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <55AAC580-DC07-4DAC-BAB0-A3DF27A11565@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 02:10:36 -0000 Hi Jonathan >It knows whether or not RPL is running on an interface. It could at least check that. By the same argument, how do you propose we limit packets to a RPL routing domain? If we have no good way of limiting packets, then the stated security considerations do not apply. Just the knowledge that the router is part of a particular RPL instance via a particular interface is no guarantee that all the neighbors reachable via that interface belong to the same RPL instance. On the other hand, a router would clearly know whether its particular interface belongs to the RPL domain or not. A packet wont be sent down an interface if that interface is not part of the RPL domain. Here, I am assuming that the RPL domain is defined in the manner you had suggested (analogous to the definition of a routing domain in Section 1.2 of RFC 1195). >> It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain any state about it. >Note that in draft-ietf-roll-rpl, RPL routers do maintain such state already. I agree the issue comes up with P2P. Indeed, this would be a big problem for P2P-RPL. >Remember that the original purpose of the RPL Instance is to support MTR. The RPL Instance identifies what routing topology to use. This is important especially if the SRH does not specify the entire path to the destination. How does the tunnel exit-point know what routing topology to use to reach the destination? There is no mention of MTR in the RPL specs. As far as RPL spec goes, an RPL Instance is simply a group of DAGs using the same OF. You can not assume that a tunnel exit-point would get any information from RPL Instance ID regarding how to reach the ultimate destination of the packet. That information would probably come from the routing table (which may be getting information via several routing protocols). >The lack of and need for the RPL Instance identifier was raised during IESG review. The options are (1) to require inclusion a RPL Option in addition to the RPL routing header or (2) add a RPL Instance field in the RPL routing header itself. I doubt that you would prefer option 1. I will try to go back and find the IESG review you have mentioned. If you could quickly direct me to right place, that will be helpful. But, at the moment, it is truly mind-boggling for me that RPL instance id is required to be specified in the source routing header. >If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway. Doing that would break the rules in SRH draft. > At the very least, the tunnel exit-point should enforce the use of the RPL Instance. Surely the end-points of a source route should at least know what RPL Instance they are in... Yes, this RPL Instance is a local instance which has no significance associated. I think you are trying to assign a meaning to RPL Instance ID which it does not currently have under RPL core spec. Thanks Mukul From prvs=3304ccdf4=mukul@uwm.edu Wed Dec 21 18:13:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F35C21F8593; Wed, 21 Dec 2011 18:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l7C0bEurgwZ; Wed, 21 Dec 2011 18:13:47 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C646721F84C5; Wed, 21 Dec 2011 18:13:47 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 21 Dec 2011 20:13:47 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4CB6312E3CD; Wed, 21 Dec 2011 20:13:47 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4klshojtMWTM; Wed, 21 Dec 2011 20:13:46 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id CEBAC12E3CC; Wed, 21 Dec 2011 20:13:46 -0600 (CST) Date: Wed, 21 Dec 2011 20:13:46 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1603574399.729992.1324520026797.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <7A89D3D3-1DA6-4698-BC4A-B8AEBE397906@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , ipv6 Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 02:13:48 -0000 >Personally, I am OK changing the scope to a RPL routing domain rather than a RPL Instance. If one really wants to limit to a RPL Instance, then they can also include a RPL Option. This is what we originally had in rpl-routing-header-05. This change was made late during the IESG review process. I support this. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" , "Jari Arkko" Cc: "roll WG" , "ipv6" Sent: Wednesday, December 21, 2011 12:22:11 PM Subject: Re: draft-ietf-6man-rpl-routing-header-07 Personally, I am OK changing the scope to a RPL routing domain rather than a RPL Instance. If one really wants to limit to a RPL Instance, then they can also include a RPL Option. This is what we originally had in rpl-routing-header-05. This change was made late during the IESG review process. Jari, would you support reverting the scope of the RPL SRH to a RPL routing domain rather than a RPL Instance? Thanks. -- Jonathan Hui On Dec 21, 2011, at 9:26 AM, Mukul Goyal wrote: > Jonathan > > I described the problem in the message I sent just now. I think RPL Instance is not the correct scope for SRH. It has to be a RPL domain to be defined as we discussed some time back on the ROLL list. > > Thanks > Mukul > > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "roll" > Sent: Tuesday, December 20, 2011 10:27:29 AM > Subject: Re: draft-ietf-6man-rpl-routing-header-07 > > > Mukul, > > As defined in the draft today, you cannot use a RPL routing header to cross RPL Instances. My understanding is that roll-p2p-rpl makes use of local RPL instances. Can you describe the issue you are concerned about? > > -- > Jonathan Hui > > On Dec 20, 2011, at 8:14 AM, Mukul Goyal wrote: > >> Jonathan >> >> The IESG-approved draft refers to the RPL instance as the scope where the routing header can be used. How would this routing header be used for general source routing (across RPL instances) in an LLN? How would a node use this routing header if it wants to travel along a source route discovered using P2P-RPL? >> >> Thanks >> Mukul >> > From jonhui@cisco.com Wed Dec 21 18:29:15 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81C11E8096 for ; Wed, 21 Dec 2011 18:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXb2LK-cLe1W for ; Wed, 21 Dec 2011 18:29:14 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3811E808C for ; Wed, 21 Dec 2011 18:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=690; q=dns/txt; s=iport; t=1324520954; x=1325730554; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RiMlRTIUo62r/niBcik3lZfGpX6Wt/ZPBbl0NOt5wh4=; b=XT1Wo9CAvhy/TRwn2/Up0g9uBXTUS99NCvMeMPcdetVGd1iYzLVTpBh4 /n29pa1jzWo44fZDXao4gzmgCdepvxA82TGvLLcAXcuhK6wZkEbOBEK06 a+JJ0IH7QK9IQIJu0AQSHiTe9WA5ky42jtX7QpeJ4Q197fFrz7yg2tkLq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJSV8k6rRDoG/2dsb2JhbABCDqwZgQWBcgEBAQMBEgEnPwULC0ZXBjWHWJkNAZ4zglWIV2MEiDeIb4NZkXxY X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; d="scan'208";a="20297817" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Dec 2011 02:29:12 +0000 Received: from sjc-vpn2-370.cisco.com (sjc-vpn2-370.cisco.com [10.21.113.114]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBM2TCT2014373; Thu, 22 Dec 2011 02:29:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <885849737.729755.1324516551604.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 21 Dec 2011 18:29:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4894235A-FC54-445A-B2FF-033B9CA3C997@cisco.com> References: <885849737.729755.1324516551604.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] CmprI and CmprE in SRH X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 02:29:15 -0000 On Dec 21, 2011, at 5:15 PM, Mukul Goyal wrote: > I think this was probably discussed earlier in your discussions with = area director. But I was wondering if you could clarify again why do we = need separate CmprI and CmprE? I think the last element in the Address = vector specifies the ultimate destination (reachable using SRH) of the = packet. Why would that destination need a separate number of elided = prefix octets? In the case that a RPL routing domain is used as a transit network. It = is important to support the case where the SRH only specifies a subset = of the path (see the 3 different cases in the image on page 5 of the = draft. -- Jonathan Hui From jonhui@cisco.com Wed Dec 21 18:42:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F4211E807F; Wed, 21 Dec 2011 18:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVUMQNEeuWlb; Wed, 21 Dec 2011 18:42:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7221F8B1D; Wed, 21 Dec 2011 18:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=4126; q=dns/txt; s=iport; t=1324521747; x=1325731347; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E3JqyJuNt7dk3EnL7CMhothIaop81qxVi6iDs6mWQXY=; b=nAuTOzpYoLGKe5aBGymlXaKnJ1jBkff90x1F1kXXc70CzjUnhhbffhgU ZRNlPubeNGq7hkgxbfubd4iVD22rIgLbqmkE4yDoQgh/tpDrVhd+5ezXm j4TGam0OKl/YXkETX+xMiT2tXYaacmdJhFJuYw+7lnk1vqtnBigtJALgV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADmY8k6rRDoI/2dsb2JhbAA4Cg6sGYEFgXIBAQECAQESASc/BQsLRlcGHBmHWAiZBAGeMohWglZjBIg3jEiRfFg X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; d="scan'208";a="21996853" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 02:42:26 +0000 Received: from sjc-vpn2-370.cisco.com (sjc-vpn2-370.cisco.com [10.21.113.114]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBM2gPqx002262; Thu, 22 Dec 2011 02:42:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <181400612.729968.1324519828382.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 21 Dec 2011 18:42:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <04F68F74-2053-4902-AB99-BDE5FD65FCCF@cisco.com> References: <181400612.729968.1324519828382.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 02:42:28 -0000 On Dec 21, 2011, at 6:10 PM, Mukul Goyal wrote: > Just the knowledge that the router is part of a particular RPL = instance via a particular interface is no guarantee that all the = neighbors reachable via that interface belong to the same RPL instance. = On the other hand, a router would clearly know whether its particular = interface belongs to the RPL domain or not. A packet wont be sent down = an interface if that interface is not part of the RPL domain. Here, I am = assuming that the RPL domain is defined in the manner you had suggested = (analogous to the definition of a routing domain in Section 1.2 of RFC = 1195). And by the same logic, when forwarding a message, there is no guarantee = that all neighboring nodes reachable via an interface belong to the same = RPL routing domain. >> Remember that the original purpose of the RPL Instance is to support = MTR. The RPL Instance identifies what routing topology to use. This is = important especially if the SRH does not specify the entire path to the = destination. How does the tunnel exit-point know what routing topology = to use to reach the destination? >=20 > There is no mention of MTR in the RPL specs. As far as RPL spec goes, = an RPL Instance is simply a group of DAGs using the same OF. You can not = assume that a tunnel exit-point would get any information from RPL = Instance ID regarding how to reach the ultimate destination of the = packet. That information would probably come from the routing table = (which may be getting information via several routing protocols). The *entire* point of the RPL Instance concept is to support MTR. The = RPL Instance is used to distinguish between different DODAGs from the = same root. It gives you the ability to have multiple different routes = to the same destination (e.g. one that minimizes latency vs. one that = minimizes energy consumption). If you don't have the RPL Instance = information when forwarding a packet, how do you know whether to forward = along the path that minimizes latency vs. the path that minimizes = energy? See slide 18 of = http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you = want one such reference of MTR and RPL Instances. >> The lack of and need for the RPL Instance identifier was raised = during IESG review. The options are (1) to require inclusion a RPL = Option in addition to the RPL routing header or (2) add a RPL Instance = field in the RPL routing header itself. I doubt that you would prefer = option 1. >=20 > I will try to go back and find the IESG review you have mentioned. If = you could quickly direct me to right place, that will be helpful. But, = at the moment, it is truly mind-boggling for me that RPL instance id is = required to be specified in the source routing header.=20 Not so mind boggling if you consider MTR. >> If the RPL router has no idea of the RPL Instance when forwarding, it = can choose to forward the packet along anyway. >=20 > Doing that would break the rules in SRH draft. Of course. I was making a proposal that we could relax the processing = rules to end-points of the SRH. >> At the very least, the tunnel exit-point should enforce the use of = the RPL Instance. Surely the end-points of a source route should at = least know what RPL Instance they are in... >=20 > Yes, this RPL Instance is a local instance which has no significance = associated. I think you are trying to assign a meaning to RPL Instance = ID which it does not currently have under RPL core spec. As I mentioned above, the RPL Instance allows you to have multiple = distinct paths towards the same destination. The RPL hop-by-hop option = includes a RPL Instance ID so that a forwarding node knows which routing = topology to use. If RPL did not allow multiple routes to the same = destination, then why bother having a RPL Instance? You would only need = the DODAGID to uniquely identify a DODAG (whereas the existing = definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a = DODAG". -- Jonathan Hui From prvs=3304ccdf4=mukul@uwm.edu Wed Dec 21 19:20:24 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257D311E8097 for ; Wed, 21 Dec 2011 19:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p-TpPWCoFdH for ; Wed, 21 Dec 2011 19:20:23 -0800 (PST) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10111E8096 for ; Wed, 21 Dec 2011 19:20:23 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 21 Dec 2011 21:20:23 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1AC81E6A75; Wed, 21 Dec 2011 21:20:23 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4rbY5uGG0qT; Wed, 21 Dec 2011 21:20:22 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A7B3DE6A74; Wed, 21 Dec 2011 21:20:22 -0600 (CST) Date: Wed, 21 Dec 2011 21:20:22 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <170960733.730376.1324524022582.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4894235A-FC54-445A-B2FF-033B9CA3C997@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] CmprI and CmprE in SRH X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 03:20:24 -0000 >In the case that a RPL routing domain is used as a transit network. It is important to support the case where the SRH only specifies a subset of the path (see the 3 different cases in the image on page 5 of the draft. If RPL domain is just a transit network, why would SRH include the ultimate destination? Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, December 21, 2011 8:29:12 PM Subject: Re: CmprI and CmprE in SRH On Dec 21, 2011, at 5:15 PM, Mukul Goyal wrote: > I think this was probably discussed earlier in your discussions with area director. But I was wondering if you could clarify again why do we need separate CmprI and CmprE? I think the last element in the Address vector specifies the ultimate destination (reachable using SRH) of the packet. Why would that destination need a separate number of elided prefix octets? In the case that a RPL routing domain is used as a transit network. It is important to support the case where the SRH only specifies a subset of the path (see the 3 different cases in the image on page 5 of the draft. -- Jonathan Hui From jonhui@cisco.com Wed Dec 21 19:35:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C489011E80EB for ; Wed, 21 Dec 2011 19:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQVixVg1eOEb for ; Wed, 21 Dec 2011 19:35:06 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E96E011E8097 for ; Wed, 21 Dec 2011 19:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=1755; q=dns/txt; s=iport; t=1324524906; x=1325734506; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6PmTeOHV8V+rNJ9XibyDTGgeWYMFEAI5JSJ8+GA3AhU=; b=T/MD3HmXhthmaiABCDH+mc7LCNrfEaOP8izxqPgT2xUc61yHM96nDk/4 oN14+VthJfRMm4hzXyVFJ1+6WtIZrSTjMn0HCMhM64jVb+/B5ibTZkotY pjhGNMEn5nNwFvAYXGB+JEAPApT6fAboKGxE+34FyoOMJkj1gCm6Rt8Ht 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAAMqk8k6rRDoG/2dsb2JhbABCDptCkFeBBYFyAQEBAwESASc/DAQLEQQBAQEuTwgGEyKHWJkOAZ4zglWIV2MEiDeIb4NZhU+MLVg X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; d="scan'208";a="20303657" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Dec 2011 03:35:06 +0000 Received: from [10.21.119.80] ([10.21.119.80]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBM3Z69R004229; Thu, 22 Dec 2011 03:35:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <170960733.730376.1324524022582.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 21 Dec 2011 19:35:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9F695FB6-1B4F-440A-A932-71994E4DD670@cisco.com> References: <170960733.730376.1324524022582.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] CmprI and CmprE in SRH X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 03:35:09 -0000 CmprI and CmprE were introduced when we allowed the use of SRH in = transport mode even when the destination was not a part of the RPL = network. The way the draft morphed, we eventually removed support for = that case, but forgot to remove CmprI and CmprE along with it. Would have been nice to get this comment as part of WGLC or IETF LC... -- Jonathan Hui On Dec 21, 2011, at 7:20 PM, Mukul Goyal wrote: >> In the case that a RPL routing domain is used as a transit network. = It is important to support the case where the SRH only specifies a = subset of the path (see the 3 different cases in the image on page 5 of = the draft. >=20 > If RPL domain is just a transit network, why would SRH include the = ultimate destination? >=20 > Thanks > Mukul =20 >=20 > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, December 21, 2011 8:29:12 PM > Subject: Re: CmprI and CmprE in SRH >=20 >=20 > On Dec 21, 2011, at 5:15 PM, Mukul Goyal wrote: >=20 >> I think this was probably discussed earlier in your discussions with = area director. But I was wondering if you could clarify again why do we = need separate CmprI and CmprE? I think the last element in the Address = vector specifies the ultimate destination (reachable using SRH) of the = packet. Why would that destination need a separate number of elided = prefix octets? >=20 >=20 > In the case that a RPL routing domain is used as a transit network. = It is important to support the case where the SRH only specifies a = subset of the path (see the 3 different cases in the image on page 5 of = the draft. >=20 > -- > Jonathan Hui >=20 From prvs=3304ccdf4=mukul@uwm.edu Thu Dec 22 07:04:52 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8AA21F8A7D; Thu, 22 Dec 2011 07:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3npceKxeo7r; Thu, 22 Dec 2011 07:04:48 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDD21F8A66; Thu, 22 Dec 2011 07:04:48 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 22 Dec 2011 09:04:35 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5B3281FD0AB; Thu, 22 Dec 2011 09:04:35 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIqWAzTiRgx1; Thu, 22 Dec 2011 09:04:34 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1989D1FD014; Thu, 22 Dec 2011 09:04:34 -0600 (CST) Date: Thu, 22 Dec 2011 09:04:33 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1026538192.732410.1324566273913.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <04F68F74-2053-4902-AB99-BDE5FD65FCCF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:04:52 -0000 Hi Jonathan >And by the same logic, when forwarding a message, there is no guarantee that all neighboring nodes reachable via an interface belong to the same RPL routing domain. The receiving router could check if it belongs to the RPL domain listed in the SRH. If not, it can drop the packet. >The *entire* point of the RPL Instance concept is to support MTR. The RPL Instance is used to distinguish between different DODAGs from the same root. It gives you the ability to have multiple different routes to the same destination (e.g. one that minimizes latency vs. one that minimizes energy consumption). If you don't have the RPL Instance information when forwarding a packet, how do you know whether to forward along the path that minimizes latency vs. the path that minimizes energy? Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit point? Is OF0 associated with minimizing of latency or of energy? What is preventing this particular RPL Instance ID 'x' with OF0 to be associated with two different DAGs - one minimizing latency and the other minimizing energy? >See slide 18 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you want one such reference of MTR and RPL Instances. >As I mentioned above, the RPL Instance allows you to have multiple distinct paths towards the same destination. The RPL hop-by-hop option includes a RPL Instance ID so that a forwarding node knows which routing topology to use. If RPL did not allow multiple routes to the same destination, then why bother having a RPL Instance? You would only need the DODAGID to uniquely identify a DODAG (whereas the existing definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG". All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem. Thanks Mukul -- Jonathan Hui From jonhui@cisco.com Thu Dec 22 07:40:16 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD8321F8B10; Thu, 22 Dec 2011 07:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLeCab3hjN2p; Thu, 22 Dec 2011 07:40:11 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B266421F8B09; Thu, 22 Dec 2011 07:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=2955; q=dns/txt; s=iport; t=1324568411; x=1325778011; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=M4PCcrHsk9nNkvZvNhDyIgSVUkJD8U/py4HbzxtIJus=; b=LXwUBSKsNWXzt5NNCzK+ADbRrRP6inRQnxZrZSD72XF/lTLgxXV8OR35 fcqn8eR/ElPlr7SFZLrlSSnOZZ74n0amb3H1xL/b7fFtUCx9ZDVbU7rc3 Sk8MDrQWIk/Z45eKg0qMS+Cwu4oZgxnZ+XmuvOEHukWcAMZClPywJjc58 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD1O806rRDoG/2dsb2JhbAA6Cg6sHYEFgXIBAQMCEgEnLRIQC0ZXBjWHYJkRAZ46iFaCVmMEiDeMSpF7WA X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; d="scan'208";a="22099927" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 15:34:38 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBMFYcrk017175; Thu, 22 Dec 2011 15:34:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <1026538192.732410.1324566273913.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Thu, 22 Dec 2011 07:34:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A027178-7819-4608-836E-940C9B25EB60@cisco.com> References: <1026538192.732410.1324566273913.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:40:16 -0000 On Dec 22, 2011, at 7:04 AM, Mukul Goyal wrote: >> And by the same logic, when forwarding a message, there is no = guarantee that all neighboring nodes reachable via an interface belong = to the same RPL routing domain. >=20 > The receiving router could check if it belongs to the RPL domain = listed in the SRH. If not, it can drop the packet. And what information does the SRH provide that indicates what RPL = routing domain it is coming from? A node now has to know what neighbors = are in its RPL routing domain? >> The *entire* point of the RPL Instance concept is to support MTR. = The RPL Instance is used to distinguish between different DODAGs from = the same root. It gives you the ability to have multiple different = routes to the same destination (e.g. one that minimizes latency vs. one = that minimizes energy consumption). If you don't have the RPL Instance = information when forwarding a packet, how do you know whether to forward = along the path that minimizes latency vs. the path that minimizes = energy? >=20 > Suppose a tunnel exit point knows that the SRH that carried the packet = so far had RPL Instance ID 'x' which happens to be associated with OF0. = What information does that give to the tunnel exit point? Is OF0 = associated with minimizing of latency or of energy? What is preventing = this particular RPL Instance ID 'x' with OF0 to be associated with two = different DAGs - one minimizing latency and the other minimizing energy? The tunnel exit-point knows what kind of paths the tunnel entry-point is = forwarding the packet along. Again, the whole purpose of RPL Instances = is to allow multiple paths optimized with different OFs towards the same = destination. If a forwarding device has no idea of what path to choose, = then why bother with a RPL Instance? >> See slide 18 of = http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you = want one such reference of MTR and RPL Instances. >=20 >> As I mentioned above, the RPL Instance allows you to have multiple = distinct paths towards the same destination. The RPL hop-by-hop option = includes a RPL Instance ID so that a forwarding node knows which routing = topology to use. If RPL did not allow multiple routes to the same = destination, then why bother having a RPL Instance? You would only need = the DODAGID to uniquely identify a DODAG (whereas the existing = definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a = DODAG". >=20 > All this discussion is really besides the point. If we could just have = the RPL domain and not the RPL Instance as the scope for an SRH, that = will solve my problem. Limiting to a RPL Instance is well-defined. Limiting to a RPL routing = domain requires a little more thought. Can you propose the exact = processing rules that would clearly limit a routing header to a RPL = routing domain? -- Jonathan Hui From prvs=3304ccdf4=mukul@uwm.edu Thu Dec 22 08:05:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825CF21F86AA; Thu, 22 Dec 2011 08:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF02BrAHqy6g; Thu, 22 Dec 2011 08:05:13 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0421F85C7; Thu, 22 Dec 2011 08:05:12 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 22 Dec 2011 10:05:11 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 06BD12B3EDB; Thu, 22 Dec 2011 10:03:24 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 515sfAWOB5xl; Thu, 22 Dec 2011 10:03:23 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BE9502B3ED8; Thu, 22 Dec 2011 10:03:23 -0600 (CST) Date: Thu, 22 Dec 2011 10:05:11 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <279988575.733200.1324569911307.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2A027178-7819-4608-836E-940C9B25EB60@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:05:13 -0000 >And what information does the SRH provide that indicates what RPL routing domain it is coming from? A node now has to know what neighbors are in its RPL routing domain? The simplest option would be for the router to decide before hand which of its interfaces belong to "the" RPL domain and which not. The SRH need not have any RPL domain field. The router would drop the packet if received over an interface not in "the" RPL domain. If the packet was received over an interface in the RPL domain, it wont be forwarded down the interfaces not in the RPL domain. A more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the packet accordingly. > >> Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit point? Is OF0 associated with minimizing of latency or of energy? What is preventing this particular RPL Instance ID 'x' with OF0 to be associated with two different DAGs - one minimizing latency and the other minimizing energy? >The tunnel exit-point knows what kind of paths the tunnel entry-point is forwarding the packet along. I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in use. > Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination. OF is just a way to calculate the rank. OF does not imply the use of particular routing metrics. Since RPL Instance ID does not identify the routing metrics in use, it can not tell what kind of route is being used to forward a packet. > If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance? RPL Instance is the top level identifier of the DAGs that can be used to forward the packet. It also maps to a particular OF. In my opinion and as per RPL spec, RPL instance has no other significance. >> >> All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem. >Limiting to a RPL Instance is well-defined. Limiting to a RPL routing domain requires a little more thought. Can you propose the exact processing rules that would clearly limit a routing header to a RPL routing domain? Lets assume that RPL domain is defined as you suggested some time back to be analogous to the routing domain definition in RFC 1195 (section 1.2). I interpret it to mean that the RPL router would characterize its interfaces as either belonging to the RPL domain or outside the RPL domain. With this interpretation of RPL domain in mind, the following processing rules would replace the rules 2 and 3 on page 13 of your draft: 2. Datagrams, carrying an SRH and received on an interface not belonging to the RPL domain, will be dropped with no further processing. 3. Datagrams, carrying an SRH and destined to be forwarded along interfaces outside the RPL domain, are dropped with no further processing. Thanks Mukul -- Jonathan Hui From jonhui@cisco.com Thu Dec 22 08:33:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B56221F8AFB; Thu, 22 Dec 2011 08:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjJb9kjA2+WL; Thu, 22 Dec 2011 08:33:24 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 48C7A21F8AF2; Thu, 22 Dec 2011 08:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=4253; q=dns/txt; s=iport; t=1324571604; x=1325781204; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wk6l4N8Pr8Lgn+hvNjXll+RAsMKQ9SFbH2+75QSIXbE=; b=UCbJq6chYzTP73kbqWhJGHVpWT8XmJA3qIsTGaDM7TJvJO1yRpjvwdN5 ktBkf9YGkvaEZKkY4NuGM164ChKJFeHDbfxKd29OPYT6ywROkE30GFB98 DnmO92mZH69HEvzwcMJVV/DmcY6Jw0Rc5OQQZh3WBuzsVKgTPKAvEyF++ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO9a806rRDoH/2dsb2JhbAA5Cg6sH4EFgXIBAQUSASc/BQsLRlcGNaBzAZ40iFaCVmMEiDeMSpF7WA Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 16:17:15 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBMGHEOG009320; Thu, 22 Dec 2011 16:17:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <279988575.733200.1324569911307.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Thu, 22 Dec 2011 08:17:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6C1711F1-AB47-4870-8228-A6A36A0C3164@cisco.com> References: <279988575.733200.1324569911307.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:33:25 -0000 On Dec 22, 2011, at 8:05 AM, Mukul Goyal wrote: >> And what information does the SRH provide that indicates what RPL = routing domain it is coming from? A node now has to know what neighbors = are in its RPL routing domain? >=20 > The simplest option would be for the router to decide before hand = which of its interfaces belong to "the" RPL domain and which not. The = SRH need not have any RPL domain field. The router would drop the packet = if received over an interface not in "the" RPL domain. If the packet was = received over an interface in the RPL domain, it wont be forwarded down = the interfaces not in the RPL domain. Again, just because you received a message on an interface for which = you've enabled RPL doesn't mean you know the message came from a router = that is within the same RPL routing domain. A router not running RPL = could have sent you that message. > A more complicated scheme would be to allow for multiple RPL domains = and list the RPL Domain ID in the SRH. The router would know which RPL = domains its interfaces belong to and would treat the packet accordingly. Except that there is no such concept. RPL Instance ID is the closest we = have. >> The tunnel exit-point knows what kind of paths the tunnel entry-point = is forwarding the packet along.=20 >=20 > I am trying to say that RPL Instance ID does not give that information = to the tunnel exit point. As per RPL spec, RPL Instance ID would have a = mapping to the OF. It nowhere says that RPL Instance ID also has a = mapping to metrics in use. =46rom Section 3.2.1 of draft-ietf-roll-rpl: The Objective Function (OF) defines how RPL nodes select and optimize routes within a RPL Instance. The OF is identified by an Objective Code Point (OCP) within the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints, which are themselves defined in [I-D.ietf-roll-routing-metrics], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 14, [I-D.ietf-roll-routing-metrics], [I-D.ietf-roll-of0], and related companion specifications. As you state, RPL Instance maps to OF which, from the cited text, maps = to metrics and route selection. By transitivity, RPL Instance ID does = map to metrics and how routes are formed. >> Again, the whole purpose of RPL Instances is to allow multiple paths = optimized with different OFs towards the same destination. >=20 > OF is just a way to calculate the rank. OF does not imply the use of = particular routing metrics. Since RPL Instance ID does not identify the = routing metrics in use, it can not tell what kind of route is being used = to forward a packet. In reality, it doesn't need to care. It just needs to care about = sending along routes that were created using the same OF. Having each = RPL router choose an arbitrary route created using an arbitrary OF does = not make any sense. >> If a forwarding device has no idea of what path to choose, then why = bother with a RPL Instance? >=20 > RPL Instance is the top level identifier of the DAGs that can be used = to forward the packet. It also maps to a particular OF. In my opinion = and as per RPL spec, RPL instance has no other significance. See above. RPL Instance does map to metrics. >> Limiting to a RPL Instance is well-defined. Limiting to a RPL = routing domain requires a little more thought. Can you propose the = exact processing rules that would clearly limit a routing header to a = RPL routing domain? >=20 > Lets assume that RPL domain is defined as you suggested some time back = to be analogous to the routing domain definition in RFC 1195 (section = 1.2). I interpret it to mean that the RPL router would characterize its = interfaces as either belonging to the RPL domain or outside the RPL = domain. The definition I proposed was simply a collection of routers running RPL = under the same administrative domain. As mentioned above, that does not = mean that every router on an interface belongs to a RPL routing domain. -- Jonathan Hui From prvs=3304ccdf4=mukul@uwm.edu Thu Dec 22 09:24:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9C21F899F; Thu, 22 Dec 2011 09:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUZjQBsZTOZj; Thu, 22 Dec 2011 09:24:43 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9EC21F893C; Thu, 22 Dec 2011 09:24:43 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 22 Dec 2011 11:24:42 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E7F6B1FD013; Thu, 22 Dec 2011 11:24:42 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXO5W0Vhr9RZ; Thu, 22 Dec 2011 11:24:42 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A8F311FD011; Thu, 22 Dec 2011 11:24:42 -0600 (CST) Date: Thu, 22 Dec 2011 11:24:42 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <6C1711F1-AB47-4870-8228-A6A36A0C3164@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:24:44 -0000 >Again, just because you received a message on an interface for which you've enabled RPL doesn't mean you know the message came from a router that is within the same RPL routing domain. A router not running RPL could have sent you that message. A router not running RPL could have sent me a message carrying SRH? >> A more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the packet accordingly. >Except that there is no such concept. RPL Instance ID is the closest we have. Yes, the concept of RPL domain needs to be defined - either in rpl-terminology draft or in your draft. >> I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in use. >From Section 3.2.1 of draft-ietf-roll-rpl: The Objective Function (OF) defines how RPL nodes select and optimize routes within a RPL Instance. The OF is identified by an Objective Code Point (OCP) within the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints, which are themselves defined in [I-D.ietf-roll-routing-metrics], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 14, [I-D.ietf-roll-routing-metrics], [I-D.ietf-roll-of0], and related companion specifications. >As you state, RPL Instance maps to OF which, from the cited text, maps to metrics and route selection. By transitivity, RPL Instance ID does map to metrics and how routes are formed. The text you quoted no where says that an OF maps to particular metric. OF0 is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04) applies to any additive metric. No RPL doc says that, for a particular LLN, a particular OF maps to a particular metric only. I think the following text clearly specifies what an RPL Instance is. Also, this text clearly says that an RPL Instance ID maps to a particular OF: rpl-19 section 3.1.2: A RPLInstanceID identifies a set of one or more Destination Oriented DAGs (DODAGs). A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different Objective Functions (OFs) and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance. All DODAGs in the same RPL Instance use the same OF. This definition says an RPLInstanceID identifies a set of DAGs with a common OF. No more and no less. A particular LLN may choose to map an OF to a particular metric but there is no such requirement as per RPL specs. >> RPL Instance is the top level identifier of the DAGs that can be used to forward the packet. It also maps to a particular OF. In my opinion and as per RPL spec, RPL instance has no other significance. >See above. RPL Instance does map to metrics. It need not. >The definition I proposed was simply a collection of routers running RPL under the same administrative domain. As mentioned above, that does not mean that every router on an interface belongs to a RPL routing domain. I think the definition you provided is sufficient. An RPL domain is a collection of routers running RPL under the same administrative domain. Each router in the RPL domain needs to classify all its interfaces regarding whether they belong to the RPL domain or not. A packet can be assumed to be coming from a router in the RPL domain if it carries an SRH. Thanks Mukul From jonhui@cisco.com Thu Dec 22 10:02:29 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1959B21F84CE; Thu, 22 Dec 2011 10:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpcuwoHl+aAA; Thu, 22 Dec 2011 10:02:28 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 829DA21F84CD; Thu, 22 Dec 2011 10:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=4452; q=dns/txt; s=iport; t=1324576948; x=1325786548; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rk6oJcPLieem4HkndKo6KGDOLHjm5a1wk2lVuo9vPhM=; b=k4ocyQ7V+5Azk3lx28eSteR3V3bZ9t8W1RqJ666znkcEY61YKZHVj9uA rMMJeCGG0o1W4EcXpNZLwdZxlEqA0niAZtaa61TQX8lfOt36Iz3uArb18 uvuG3As8mGTdQpJ8cWHtHtV7IaHMfu0eWtKGbKpSf4QfX1jUXfIZZwrHv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABZw806rRDoG/2dsb2JhbABDDqwfgQWBcgEBAQMBEgEnLRIFCwtGVwY1h1iZCAGeKYssYwSIN4xKkXtY X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; d="scan'208";a="22147265" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 18:02:28 +0000 Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBMI2SVe000675; Thu, 22 Dec 2011 18:02:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Thu, 22 Dec 2011 10:02:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 18:02:29 -0000 On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote: >> Again, just because you received a message on an interface for which = you've enabled RPL doesn't mean you know the message came from a router = that is within the same RPL routing domain. A router not running RPL = could have sent you that message. >=20 > A router not running RPL could have sent me a message carrying SRH? Sure. It could be a host as well. Part of limiting the scope is to = limit the scope of an attack. See the Security Considerations. >> =46rom Section 3.2.1 of draft-ietf-roll-rpl: >=20 > The Objective Function (OF) defines how RPL nodes select and = optimize > routes within a RPL Instance. The OF is identified by an Objective > Code Point (OCP) within the DIO Configuration option. An OF defines > how nodes translate one or more metrics and constraints, which are > themselves defined in [I-D.ietf-roll-routing-metrics], into a value > called Rank, which approximates the node's distance from a DODAG > root. An OF also defines how nodes select parents. Further details > may be found in Section 14, [I-D.ietf-roll-routing-metrics], > [I-D.ietf-roll-of0], and related companion specifications. >=20 >> As you state, RPL Instance maps to OF which, from the cited text, = maps to metrics and route selection. By transitivity, RPL Instance ID = does map to metrics and how routes are formed. >=20 > The text you quoted no where says that an OF maps to particular = metric. OF0 is metrics-independent. OF1 = (draft-ietf-roll-minrank-hysteresis-of-04) applies to any additive = metric. No RPL doc says that, for a particular LLN, a particular OF maps = to a particular metric only.=20 Incorrect. =46rom draft-ietf-roll-routing-metrics-19: The set of routing metrics and constraints used by an RPL deployment is signaled along the DAG that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DAG Information Option (DIO) message specified in [I-D.ietf-roll-rpl]. In other words, the combination of the OCP and the metrics identified by = the DODAG Root describes how to optimize the routes. In the case of = OF0, the metric is the Rank itself. > I think the following text clearly specifies what an RPL Instance is. = Also, this text clearly says that an RPL Instance ID maps to a = particular OF: >=20 > rpl-19 section 3.1.2: > A RPLInstanceID identifies a set of > one or more Destination Oriented DAGs (DODAGs). A network may > have multiple RPLInstanceIDs, each of which defines an = independent > set of DODAGs, which may be optimized for different Objective > Functions (OFs) and/or applications. The set of DODAGs = identified > by a RPLInstanceID is called a RPL Instance. All DODAGs in the > same RPL Instance use the same OF. >=20 > This definition says an RPLInstanceID identifies a set of DAGs with a = common OF. No more and no less. A particular LLN may choose to map an OF = to a particular metric but there is no such requirement as per RPL = specs. You never answered my question. Why bother having a RPL Instance ID if = you don't care how the routes are optimized? Why bother maintaining = multiple paths optimized using different OFs and/or metrics? >>> RPL Instance is the top level identifier of the DAGs that can be = used to forward the packet. It also maps to a particular OF. In my = opinion and as per RPL spec, RPL instance has no other significance. >=20 >> See above. RPL Instance does map to metrics. >=20 > It need not. You are incorrect again! >> The definition I proposed was simply a collection of routers running = RPL under the same administrative domain. As mentioned above, that does = not mean that every router on an interface belongs to a RPL routing = domain. >=20 > I think the definition you provided is sufficient. An RPL domain is a = collection of routers running RPL under the same administrative domain. = Each router in the RPL domain needs to classify all its interfaces = regarding whether they belong to the RPL domain or not. >=20 > A packet can be assumed to be coming from a router in the RPL domain = if it carries an SRH. Nope. As I stated before, that would invalidate the Security = Considerations section. -- Jonathan Hui From robert.cragie@gridmerge.com Fri Dec 23 10:07:12 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8E21F85F2; Fri, 23 Dec 2011 10:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhxRWAhg+x6C; Fri, 23 Dec 2011 10:07:11 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D121F85EF; Fri, 23 Dec 2011 10:07:10 -0800 (PST) Received: from client-82-31-21-125.midd.adsl.virginmedia.com ([82.31.21.125] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1Re9WG-0004Sf-7W; Fri, 23 Dec 2011 18:07:00 +0000 Message-ID: <4EF4C358.60103@gridmerge.com> Date: Fri, 23 Dec 2011 18:07:20 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jonathan Hui References: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040305020204050403030002" X-Authenticated-As: robert.cragie@gridmerge.com Cc: ipv6@ietf.org, roll Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:07:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040305020204050403030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jonathan, Some comments and questions below. Robert On 22/12/2011 6:02 PM, Jonathan Hui wrote: > On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote: > >>> Again, just because you received a message on an interface for which = you've enabled RPL doesn't mean you know the message came from a router t= hat is within the same RPL routing domain. A router not running RPL coul= d have sent you that message. >> A router not running RPL could have sent me a message carrying SRH? > Sure. It could be a host as well. Part of limiting the scope is to li= mit the scope of an attack. See the Security Considerations. I'm not getting this. The use of SRH is for non-storing mode,=20 correct? And only for non-storing mode? There is no current definition=20 of partial storing mode and stored mode doesn't need SRH. So the source=20 routes are created on the DAG root based on transit information obtained = by DAOs. How can any router outside of the RPL domain initiate a=20 source-routed message to a node in the RPL domain? It would be tunneled=20 at the point it got to the DAG root. Therefore, by implication, normally = the source and destination of the message with SRH must be in the RPL=20 domain. So we need to check for exceptions - surely the rules Mukul=20 stated are sufficient? > >>> From Section 3.2.1 of draft-ietf-roll-rpl: >> The Objective Function (OF) defines how RPL nodes select and optimi= ze >> routes within a RPL Instance. The OF is identified by an Objective= >> Code Point (OCP) within the DIO Configuration option. An OF define= s >> how nodes translate one or more metrics and constraints, which are >> themselves defined in [I-D.ietf-roll-routing-metrics], into a value= >> called Rank, which approximates the node's distance from a DODAG >> root. An OF also defines how nodes select parents. Further detail= s >> may be found in Section 14, [I-D.ietf-roll-routing-metrics], >> [I-D.ietf-roll-of0], and related companion specifications. >> >>> As you state, RPL Instance maps to OF which, from the cited text, map= s to metrics and route selection. By transitivity, RPL Instance ID does = map to metrics and how routes are formed. >> The text you quoted no where says that an OF maps to particular metric= =2E OF0 is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-o= f-04) applies to any additive metric. No RPL doc says that, for a particu= lar LLN, a particular OF maps to a particular metric only. > Incorrect. From draft-ietf-roll-routing-metrics-19: > > The set of routing metrics and constraints used by an RPL deploymen= t > is signaled along the DAG that is built according to the Objective > Function (rules governing how to build a DAG) and the routing metri= cs > and constraints are advertised in the DAG Information Option (DIO) > message specified in [I-D.ietf-roll-rpl]. > > In other words, the combination of the OCP and the metrics identified b= y the DODAG Root describes how to optimize the routes. In the case of OF= 0, the metric is the Rank itself. > >> I think the following text clearly specifies what an RPL Instance is. = Also, this text clearly says that an RPL Instance ID maps to a particular= OF: >> >> rpl-19 section 3.1.2: >> A RPLInstanceID identifies a set of >> one or more Destination Oriented DAGs (DODAGs). A network may >> have multiple RPLInstanceIDs, each of which defines an independe= nt >> set of DODAGs, which may be optimized for different Objective >> Functions (OFs) and/or applications. The set of DODAGs identifi= ed >> by a RPLInstanceID is called a RPL Instance. All DODAGs in the >> same RPL Instance use the same OF. >> >> This definition says an RPLInstanceID identifies a set of DAGs with a = common OF. No more and no less. A particular LLN may choose to map an OF = to a particular metric but there is no such requirement as per RPL specs.= > You never answered my question. Why bother having a RPL Instance ID if= you don't care how the routes are optimized? Why bother maintaining mul= tiple paths optimized using different OFs and/or metrics? The source route is determined by the transit options, nothing else.=20 There is no processing done at each hop - it simply forwards it to the=20 next based on what's in the SRH. So no need for RPL instance (or domain) = there. You could potentially build up multiple tables for each RPL=20 instance but you would just formulate a different SRH based on which=20 table you picked. When it gets to the destination, why would the=20 OF/metric of whatever DAG it happen to transit through have any bearing=20 on where it is subsequently going? I ask this because there is no=20 further information based on the domain it has just gone through. The=20 message originator would not even be aware of any subsequent RPL domains = beyond itself; it is bounded by the root and the leaf routers. Unless=20 the destination is on path between the DAG root and a leaf router, an=20 SRH will always go between the DAG root and a leaf router. I find the=20 concept of a partial SRH quite baffling even if it is for the purposes=20 of traceroute - even then at the point it emerges someway down the path, = it will return a time exceeded error. So basically, I am still failing to understand the need to carry RPL=20 instance in the SRH for non-storing mode. I could see its use in partial = storing mode whereby SRH carries it part of the way and the stored=20 information on subsequent routers the rest, but in this case surely you=20 would put a RPL option in the inner packet and tunnel? So when it=20 emerges from the source-routed tunnel, it is ready to be forwarded using = RPL. > >>>> RPL Instance is the top level identifier of the DAGs that can be use= d to forward the packet. It also maps to a particular OF. In my opinion a= nd as per RPL spec, RPL instance has no other significance. >>> See above. RPL Instance does map to metrics. >> It need not. > You are incorrect again! > >>> The definition I proposed was simply a collection of routers running = RPL under the same administrative domain. As mentioned above, that does = not mean that every router on an interface belongs to a RPL routing domai= n. >> I think the definition you provided is sufficient. An RPL domain is a = collection of routers running RPL under the same administrative domain. E= ach router in the RPL domain needs to classify all its interfaces regardi= ng whether they belong to the RPL domain or not. >> >> A packet can be assumed to be coming from a router in the RPL domain i= f it carries an SRH. > > Nope. As I stated before, that would invalidate the Security Considera= tions section. I agree with Mukul: in normal circumstances a packet with an SRH=20 will come from a router in the RPL domain and the rules Mukul stated can = be used to make sure it doesn't go beyond. > > -- > Jonathan Hui > > --------------ms040305020204050403030002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMzE4MDcyMFowIwYJKoZI hvcNAQkEMRYEFN6S88g8va+wNVxO0JuyotsKD2ZTMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQAGVrPUxKbMa9c0W15/C6oa h6V9GsLv1y5QqZGZSKZeilxNTDiDT6j11fY4tITmbpZ4uNTRlCaFVWl4egV5tASF8Cms/Zf4 43b2IU75XFOWz5QbJHh872cN6BTgnWrWaqfKuywO0PqfxM6cCtgGmGwA0d+vQFVtjEVRSrsu 8u6XBcxdhPK5TPOTLVtWeYInAJ5Z/zhLhys3p4tyZq3XMwiOvqCIdn6l0btK/Ccm9WzUGYQW Hhq7RTHktB1h4c6MtMiM1mQV/cZImyXtd7Ch5KBVsBycRWonlcKOnNQnCsWd7nbYQf3j0nDv 6x3VwPB18aR/ja6qEdg5yMWktAPVKjlsAAAAAAAA --------------ms040305020204050403030002-- From prvs=331fbc5f4=mukul@uwm.edu Fri Dec 23 10:33:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0EF21F8A6F; Fri, 23 Dec 2011 10:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvxGcjY95oQM; Fri, 23 Dec 2011 10:33:06 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9ED21F84E5; Fri, 23 Dec 2011 10:33:06 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 23 Dec 2011 12:33:05 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id ABE2FE6A75; Fri, 23 Dec 2011 12:33:05 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxY0yX0P4JkT; Fri, 23 Dec 2011 12:33:04 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 907C2E6A74; Fri, 23 Dec 2011 12:33:04 -0600 (CST) Date: Fri, 23 Dec 2011 12:33:04 -0600 (CST) From: Mukul Goyal To: "Jonathan Hui (johui)" Message-ID: <1431347815.744466.1324665184537.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , ipv6@ietf.org Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:33:07 -0000 If a packet, carrying an SRH, is received over an interface not in RPL doma= in, it is discarded. Thus, an attack may only be mounted within an RPL doma= in. Also, a packet, carrying an SRH, cant be sent over an interface not in RPL = domain. So, any attack can not propagate beyond the RPL domain. Also, whats wrong with defining RPL domain based on interfaces? As I mentioned before, using RPL Instance as the scope of SRH is a problem.= Rules on page 13 are difficult to meet. An RPL router has no idea whether = the next hop belongs to the particular RPL Instance or not. If the rules ar= e changed so that a router has to check if it itself belongs to the particu= lar RPL Instance, that will be a problem as well. This is because routers o= n a source route discovered using P2P-RPL dont remember RPL Instance under = which the route was discovered. Requiring maintenance of state to be part o= f a source route does not sound like a good idea.=20 Thanks Mukul ----- Original Message ----- From: "Jonathan Hui (johui)" To: "robert cragie" Cc: "Mukul Goyal" , ipv6@ietf.org, "roll" Sent: Friday, December 23, 2011 12:17:18 PM Subject: Re: draft-ietf-6man-rpl-routing-header-07 To alleviate some of the usual security concerns with source routing, we wa= nt to limit the scope if where attacks can be initiated. Any outside attacker can fabricate a SRH and send it to a RPL router. How = do you prevent that without some way of limiting the scope? Also, Mukul's proposal is to define the scope based on interfaces. That i= s not the same as limiting the scope to a collection of RPL routers. -- Jonathan Hui On Dec 23, 2011, at 10:07 AM, "Robert Cragie" = wrote: > Hi Jonathan, >=20 > Some comments and questions below. >=20 > Robert >=20 > On 22/12/2011 6:02 PM, Jonathan Hui wrote: >> On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote: >>=20 >>>> Again, just because you received a message on an interface for which y= ou've enabled RPL doesn't mean you know the message came from a router that= is within the same RPL routing domain. A router not running RPL could hav= e sent you that message. >>> A router not running RPL could have sent me a message carrying SRH? >> Sure. It could be a host as well. Part of limiting the scope is to lim= it the scope of an attack. See the Security Considerations. > I'm not getting this. The use of SRH is for non-storing mode, correc= t? And only for non-storing mode? There is no current definition of partial= storing mode and stored mode doesn't need SRH. So the source routes are cr= eated on the DAG root based on transit information obtained by DAOs. How ca= n any router outside of the RPL domain initiate a source-routed message to = a node in the RPL domain? It would be tunneled at the point it got to the D= AG root. Therefore, by implication, normally the source and destination of = the message with SRH must be in the RPL domain. So we need to check for exc= eptions - surely the rules Mukul stated are sufficient? >>=20 >>>> From Section 3.2.1 of draft-ietf-roll-rpl: >>> The Objective Function (OF) defines how RPL nodes select and optimize >>> routes within a RPL Instance. The OF is identified by an Objective >>> Code Point (OCP) within the DIO Configuration option. An OF defines >>> how nodes translate one or more metrics and constraints, which are >>> themselves defined in [I-D.ietf-roll-routing-metrics], into a value >>> called Rank, which approximates the node's distance from a DODAG >>> root. An OF also defines how nodes select parents. Further details >>> may be found in Section 14, [I-D.ietf-roll-routing-metrics], >>> [I-D.ietf-roll-of0], and related companion specifications. >>>=20 >>>> As you state, RPL Instance maps to OF which, from the cited text, maps= to metrics and route selection. By transitivity, RPL Instance ID does map= to metrics and how routes are formed. >>> The text you quoted no where says that an OF maps to particular metric.= OF0 is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04)= applies to any additive metric. No RPL doc says that, for a particular LLN= , a particular OF maps to a particular metric only. >> Incorrect. From draft-ietf-roll-routing-metrics-19: >>=20 >> The set of routing metrics and constraints used by an RPL deployment >> is signaled along the DAG that is built according to the Objective >> Function (rules governing how to build a DAG) and the routing metrics >> and constraints are advertised in the DAG Information Option (DIO) >> message specified in [I-D.ietf-roll-rpl]. >>=20 >> In other words, the combination of the OCP and the metrics identified by= the DODAG Root describes how to optimize the routes. In the case of OF0, = the metric is the Rank itself. >>=20 >>> I think the following text clearly specifies what an RPL Instance is. A= lso, this text clearly says that an RPL Instance ID maps to a particular OF= : >>>=20 >>> rpl-19 section 3.1.2: >>> A RPLInstanceID identifies a set of >>> one or more Destination Oriented DAGs (DODAGs). A network may >>> have multiple RPLInstanceIDs, each of which defines an independent >>> set of DODAGs, which may be optimized for different Objective >>> Functions (OFs) and/or applications. The set of DODAGs identified >>> by a RPLInstanceID is called a RPL Instance. All DODAGs in the >>> same RPL Instance use the same OF. >>>=20 >>> This definition says an RPLInstanceID identifies a set of DAGs with a c= ommon OF. No more and no less. A particular LLN may choose to map an OF to = a particular metric but there is no such requirement as per RPL specs. >> You never answered my question. Why bother having a RPL Instance ID if = you don't care how the routes are optimized? Why bother maintaining multip= le paths optimized using different OFs and/or metrics? > > The source route is determined by the transit options, nothing else. Ther= e is no processing done at each hop - it simply forwards it to the next bas= ed on what's in the SRH. So no need for RPL instance (or domain) there. You= could potentially build up multiple tables for each RPL instance but you w= ould just formulate a different SRH based on which table you picked. When i= t gets to the destination, why would the OF/metric of whatever DAG it happe= n to transit through have any bearing on where it is subsequently going? I = ask this because there is no further information based on the domain it has= just gone through. The message originator would not even be aware of any s= ubsequent RPL domains beyond itself; it is bounded by the root and the leaf= routers. Unless the destination is on path between the DAG root and a leaf= router, an SRH will always go between the DAG root and a leaf router. I fi= nd the concept of a partial SRH quite baffling even if it is for the purpos= es of traceroute - even then at the point it emerges someway down the path,= it will return a time exceeded error. >=20 > So basically, I am still failing to understand the need to carry RPL inst= ance in the SRH for non-storing mode. I could see its use in partial storin= g mode whereby SRH carries it part of the way and the stored information on= subsequent routers the rest, but in this case surely you would put a RPL o= ption in the inner packet and tunnel? So when it emerges from the source-ro= uted tunnel, it is ready to be forwarded using RPL. > >>=20 >>>>> RPL Instance is the top level identifier of the DAGs that can be used= to forward the packet. It also maps to a particular OF. In my opinion and = as per RPL spec, RPL instance has no other significance. >>>> See above. RPL Instance does map to metrics. >>> It need not. >> You are incorrect again! >>=20 >>>> The definition I proposed was simply a collection of routers running R= PL under the same administrative domain. As mentioned above, that does not= mean that every router on an interface belongs to a RPL routing domain. >>> I think the definition you provided is sufficient. An RPL domain is a c= ollection of routers running RPL under the same administrative domain. Each= router in the RPL domain needs to classify all its interfaces regarding wh= ether they belong to the RPL domain or not. >>>=20 >>> A packet can be assumed to be coming from a router in the RPL domain if= it carries an SRH. >>=20 >> Nope. As I stated before, that would invalidate the Security Considerat= ions section. > I agree with Mukul: in normal circumstances a packet with an SRH wil= l come from a router in the RPL domain and the rules Mukul stated can be us= ed to make sure it doesn't go beyond. >>=20 >> -- >> Jonathan Hui >>=20 >>=20 >=20