Re: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

"Qasem, Mamoun" <M.Qasem@napier.ac.uk> Wed, 15 February 2017 15:13 UTC

Return-Path: <M.Qasem@napier.ac.uk>
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 DB261129A60 for <roll@ietfa.amsl.com>; Wed, 15 Feb 2017 07:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=livenapierac.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCN5fP-chC2u for <roll@ietfa.amsl.com>; Wed, 15 Feb 2017 07:13:20 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0045.outbound.protection.outlook.com [104.47.1.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFA6129A5B for <roll@ietf.org>; Wed, 15 Feb 2017 07:13:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livenapierac.onmicrosoft.com; s=selector1-napier-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XY1srKhmUW+4If6de8T8fIA4fNV7/Iw1CwtzvtuHeEM=; b=NaqF1z0TULLKLq6Uz4hKRcXZBR7FOqba6HRqLtpCVz78sOUTJG/Gk1P2BBmcYnWMl0id/9pAo0NVEy51z4PAxPI+gDWzz857GQrjSOpi0jEv57pNU3gXA+n53DkWUwkEQ2+3RsESarXq9oCmWt9sDvY7TvmAJ9x+DGaLbkw6R04=
Received: from HE1PR01CA0034.eurprd01.prod.exchangelabs.com (10.163.2.172) by DB5PR0101MB1990.eurprd01.prod.exchangelabs.com (10.167.224.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 15:13:15 +0000
Received: from HE1EUR02FT048.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::208) by HE1PR01CA0034.outlook.office365.com (2a01:111:e400:58e8::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16 via Frontend Transport; Wed, 15 Feb 2017 15:13:15 +0000
Authentication-Results: spf=pass (sender IP is 146.176.4.2) smtp.mailfrom=napier.ac.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=napier.ac.uk;
Received-SPF: Pass (protection.outlook.com: domain of napier.ac.uk designates 146.176.4.2 as permitted sender) receiver=protection.outlook.com; client-ip=146.176.4.2; helo=owa.napier.ac.uk;
Received: from owa.napier.ac.uk (146.176.4.2) by HE1EUR02FT048.mail.protection.outlook.com (10.152.10.243) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.904.16 via Frontend Transport; Wed, 15 Feb 2017 15:13:15 +0000
Received: from MER-EXCH1.napier.ac.uk ([fe80::f936:ca4b:b8b2:23c3]) by MER-EXCH2.napier.ac.uk ([fe80::c4c:e335:b1d8:973c%15]) with mapi id 14.03.0266.001; Wed, 15 Feb 2017 15:13:14 +0000
From: "Qasem, Mamoun" <M.Qasem@napier.ac.uk>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt
Thread-Index: AQHSgUzDv4x6GtEKt0GenVu9ngaiqqFqMVZA
Date: Wed, 15 Feb 2017 15:12:39 +0000
Message-ID: <CEB42D9A3A97D8429B05740EDE4119C50623A8AC@MER-EXCH1.napier.ac.uk>
References: <E71832BAF1628743B32A893D204095BF3CDDEF63@MER-EXCH2.napier.ac.uk> <8483508dd5ec4f6a9687305397c5a7b4@XCH-RCD-001.cisco.com>
In-Reply-To: <8483508dd5ec4f6a9687305397c5a7b4@XCH-RCD-001.cisco.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [146.176.9.241]
Content-Type: multipart/alternative; boundary="_000_CEB42D9A3A97D8429B05740EDE4119C50623A8ACMEREXCH1napiera_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:146.176.4.2; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(2980300002)(438002)(189002)(199003)(252514010)(6246003)(104016004)(2920100001)(6666003)(450100001)(84326002)(2900100001)(66066001)(106466001)(86362001)(110136004)(26826002)(4326007)(230783001)(38730400002)(107886003)(7736002)(3846002)(6116002)(229853002)(5660300001)(8936002)(7636002)(102836003)(966004)(53946003)(7906003)(53416004)(5890100001)(5250100002)(1720100001)(626004)(92566002)(606005)(74482002)(356003)(73180200002)(189998001)(512934002)(33656002)(55846006)(6306002)(50986999)(54896002)(246002)(7696004)(76176999)(54356999)(42882006)(236005)(106116001)(2906002)(2950100002)(6916009)(54906002)(55016002)(389900002)(5001870100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0101MB1990; H:owa.napier.ac.uk; FPR:; SPF:Pass; PTR:mer-exch2.napier.ac.uk,webmail.napier.ac.uk; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT048; 1:lW2joOmgGesq8RWFmOEUp4BZBytMhUTo4B9lviiR/RJXKEjeowClpV45lORSy68RaIPT7VCKcM6XAJCoRC28Zp7f1OdJUs+kd+fqWDNBsX6s+y29Tddm5ZaC84ZZPsALcV3ltdR5xT/1JbPLixEgUYO4MYLInTXQT8oRcZSaerk5vWhmFWB1xX1zV7GoDPiLokv+r/dKG5Fok9xG8p0zia2sJJkJpE77AIhXgvvoPcvcRgPrHHs5YyOraiJ3DajTjxR00n2Cnq4gjXYe8+XjiKqELTb6f0MXjKj+p9Y8JGQGPmYuOjVReMLj/B/sb1POsqzeLuP8x0wsPlAkCQI68KJSma11k5YiWq63tzNCqoYC9BJ/2IPs15x3IlhplP/UUHjrCLAFq3bk6HGkaLpZ/kmqrxjvfz3azAvOBSrse7hdCj4j1y3TsR9V4VBsa9lWqQYVczUa9TYYlN9RmxoKdC3zid58kPC2mPzN3ORRZd2Zn6aH/pEvmOqGklskBhVc
X-MS-Office365-Filtering-Correlation-Id: 6e60da53-d7de-4592-6970-08d455b52a77
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:DB5PR0101MB1990;
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 3:LBx74AlzEx0Hq/SF+Uh7KgpXLKZoVkOh1nEv2tp/YPsu3Fm+F/WKSXqrQNMAvNmF3RUd0PkLcb/5ihcARSZBSH394bnJnKDdcJgnalW+NQinrdyntYIvp5S89NVbTVU1sEgVNByd9DHUp1t3uX/AdyX9GkcVoeDTtoouGF5VnLTFPaG3+bSpOt1spH7UlKxy25ZrPyD0tQGnxq2kJ6B94ubvW2MZ3j4ycfjWT6d6Mx/VsrduIxbE70usC/qDU5uRXQVUBA6AM4NhstO3U75Rz72tBtDnCqJXH7lOION9s/2zCClDkLS6ZFuXooNYpv0NlsKAr+Odscx3tYiaprHQcCYVhUQti/HMY2cPOBnVla6gWJyo/a5RjU9RDUCOQXv82H6OFS0wPti43U50XUqGlw==; 25:WsPcfFFiGw/OrsIEbyZvlTrbV6UkFdLi421LJTWKtCSxAH1AFM5aW0eSdqlJNm1T6EVVRfB6Eqh3y3FRP4+4GEOZSBG8Y6S7njUNSF8dvsSQMzQUdxSmFYwCy1jYMeMRXzkWbL+9nxc2fX8/iheDCK3Y96FR6XeDVvKPt+qSidqKCs2PsOI0DROM3v0kqm3TBTdrbzjhXfd5BHhw8Tl4AeEP8/aaq33LrHKCSpymKwPwJKjtQwQZ5cXOjJ8kUj5beCxGHRnu04P9T0Ie1+jGSDyRl21pmAKYFeeHugIshsKsl3rzyQhFQWDj+zyyrapbbsKKS6AbOEw4Z0/6D3omdx1PagK4XwW9sYk+uNGicqOToysWfF0nxnoPKqDaO7NRv1pO3qv1ZWNOwjhpJxsnDpMVr4xqsNPhP4XsfPrpuWqZi3bpl+sjKxNJOgTu/lMFyjLpS/7qxKbVtmu+ZBGbZw==
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 31:HBU0JM2Vt9yDveicBi7fG4fgnFfBGzSnnd/IVQgFqaL4VHPenRHTIHvj2i8UXsb7ll/kqrCLq3fOMNCrTqP7Y2VFdMpAfFsTtf6wfRgpT9oaUvXOQRHMrKppDz8K5jWlYOnslxKpEHYeAS+XMHokahlQ18TqzhMPfQfdal/TxOu7LfX61HZqGzP+7/LxFc0HPCeOptSZehbG9AuTJ0GTcox1cb+RhuX9FTIoZYot34rB2uCs6YP47wCHRHzSqZV3Dea/blTcsk2z2c9oZ0MSMlIi4rEeVYFgN4eJhu8cHNs=; 20:bVtvTOzHji4r4iFBIMIERvu/KybOr6YUp/ZaFd2/6BfxSMzf6SL6f6lGf+VxHEDgTvm6+4ieuGIk9x56fXdCG3cRbTaGswv7PKQSFRfe46tGtlkDVDdwD+COdwHNZLj/mQ9f8VuFx4wl6sS6rCIN9aDaSxgKOPNQDVqyU5RwzZALs8kBPiKVov5HmAzFh/imfr0HOYRpXdEh7WXXjHwJH9F5tYYf32Ag43gwLSSt0FpZusKgDKpu4gbboYcfOfGeeVr6hiUy9WCGS6i8JvQyEooG1AizjK55DxtHTK0U/XvKBcpi/zUBsc/U6TuKjrgTlF1Y3bmHueAsLd4Yfdqhfw5FRvWttbAVzx7Y0czSDa7SsOce9d9IHb5d8ZMZ3JvqdSlEg1K0o9UUuagY4jpsRNOoDbvqg5lmLY3m4cpq7F2jB93I4A8j5JNi8xW2J9CaC0xgrAwBBfQGvCRiz6onSSJOAoUxJsPft1eeSqNJppnh/pX/OLpmWhEhfQBqI09S
X-Microsoft-Antispam-PRVS: <DB5PR0101MB1990013AE2C83674A2F12347CF5B0@DB5PR0101MB1990.eurprd01.prod.exchangelabs.com>
X-Exchange-Antispam-Report-Test: UriScan:(72170088055959)(67546534810915)(116415991822766)(268783453032223)(95692535739014)(21748063052155)(81160342030619)(131327999870524);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13012025)(13020025)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:DB5PR0101MB1990; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0101MB1990;
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 4:yHiX5oPN4ad5yCqMAGOfnTzxb1Lgx2PGROp1cPaNcIbuEbuVfBtRxLMun8SXfYk3BdiUF3T9u+GKlHPGZWygDW1NUw1TNaHD50k3/sQ5qbeRcCLu/SJ9V1Xdr/wqtJKKAULpDfCBYK0RmgB5qhZzaYLLPyc1JQYvYT0ixRou9TItSTw5QCEkTU7JYp4/eML3bor2lMCLY214bReuQooOycumg6a6EmuRsNRrjx2IBPUBn+Qko687ep7hwj0pgn1idTglwDe6r2R0InyacLXf+PX7cwJG7Bci3HhT9Yo8T7L0QpB4GIgbF/8kzeww/uDozCEtfTUeYi1LbiWe35lLvPErR5bKI/JKKlE6+3kdQ+0FYEFUF64dkgHJjGizkxNJQdEzBSWS7pYf+yCF+/uTO6ZA4iJhPeKDIxebxgrLi+yS0eHsQzQ0q84AJ/O4flyZ1QN+FzoQP4NnV6nPoWY6XXv6qRams2bCEFLBwdNy67Om2geNHWy6gpC6TehmRw3KdIR+/FWFaG06r4DDwS7fxZmBOaawTrzmpnNJqJw1U5B8U5qUp/uiMQT0KR8lcGy/+a7ezEzJ498rEW7GJ+QrFk8jLjZwQFxIyTJNySgeq00tmyY7RqO/J1m+W7Pxep8yg0PgRu7l0X27OZQO3vMXCCNt5NBwV1ieD/G1cRvlqml9KEvd8JK3xl9JG2uK32d4hv+DyTUf0NKwtO92PUSKX8BRkjaGbqMwQ8Nqa3SNVTlVTCSQBO3TJ1P6Pwr8bmAfqZB/0mDsVI+VwzYvekoS+X5Rdd9fQOpRsgHi8cce12FqNBo5evDrJFGFVsq4toVVA50po6OztlB+MarjzUVje3a0tRBgaf38Hu2z/2RkhCuIIIWPnjy4M1rsAC5wZxuzxyC0xjWC1Wny40K7BMQxZ55BlSxafk/NlUWt0fLBO7Y=
X-Forefront-PRVS: 021975AE46
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 23:JeW+ROQR8tmQtiNyBa2etxysKHGyzneGK1HwkLbPFsU7saBnS1Pvva/Js7vu+AEdm97IhUgj9QRKQNk1T61/T5DDEUM7tKGL7Pqcyj8Jn70wctcq9ZQ0WHTdtJXJtc1WOuSwLAoPYsP3cSl8ixl9nOdt61juJ+bIumGtxu3MLq3XcKDRoWAyrGS+NA6+dVeFOPpkW0Y34dLfvP6cIhYPzXbk9UKOoDkHIe0JIuRlP9Al1TU5YT6aJkiDRynaVBmXj7F+mYoW4SyDdJtx22N7Yc7rZUw92DfC5zsNBc/HWUwWUMmBD3uvxyyZE7CmafhYYrTb5q3jjXMiUis2wdBmyXZme+o3ezu1DULbikVPbqlhQCMhEmhX/sEq50Ae60hf1sPk0rml/W7IpTCiB6PmjEVbxvUcXVkoIIRRjBP1+8bBE0IEC5j62gikn3/An8ick+akxuj5gYKH+SRvI35z9mii4xP3Dz66wgYA5GbIlCf5jfvyZIDDhaDRrpFQWW/NYQ6D7dOuVX348MjeVzisC1/xxhI3BgkVauCbsRhigvk9ztbCdbMO1zMKDRGtc3MPwpcwF1FOyTR75ZaE5AQE2zSRXWMOXtqIJ90vwtVVatwU//uoC6+6jja/asQq6EDpwZVMwhQotm2LJkJtRuuXcumwnEw1xDwZTsru96PJb7mr1QXiNPya6KlJlWy7YNXZ+NVAk4iMF7wUD2KfbdsPEw5WmHC8efSKtPIjn2gZbzPgFey60rNw9vbCgq6wEa9F79d9O/NpLZx1co0AHPa+fWh3Bu1MGDOoEbzBCQSWjOizLTMD3JnuP0aRoivr6nOumfJQSeSNkHUyZdSvDzK1Rdqg/S1NiK7tQAjlHeo7WBtvoniJ0GhYRvDKCkFEC/AlSRWWpwELrW0MW4fcj0NH55E/5YM7I+uhGYj4WLnOxVPwgYO2ZWnLkviYOuGL9I+APsDu6dngkrgpNQon8ooGHF+7bmAjM/d7gjgc3/O7UpDPLyP3LLqNpl8CtMQ7EzQfBdPtKtdnQe3U3jJ7Mh0gBgRONxmpng4rIdYmaNkTPxPn395Xo0gQqB0eupUX07iXYLn9OReU812OEu1eTjvQiyQ2AhcI2Dcubpg9gWrawuNTWjdGpkgwyXnSJeOG0iuG5iwartfQ9+lIf60/8Av0mPrNvyW7xWAGVQ4z/NKeIjumoOMqJbGm/U1ClSySS6w1gNqpontD3tO+u4Xospb+ZrVDvZwIXgrfLfmKKpd2Bu23BfQCcXH1CBf8B2wcDOTHhiVDvEBNWpLsZgdS9cnPMudd/Uy3YrVfNw97iUKMW8CrbUrRI/ajZYbPvqL3Tu3mqksCsaN4QcRlYjuUv1iVli/Km8AWp9hR0lCBlCqPE79RY3wsyV2bk0NCm3RAzWf67OslfH4ue7kROpnpA0Gh05h87XIeYL5KxpaS5mKLc2wU15qOIzLft/PIeKVeUj50uO2PyET9Fr6TlSCESryQ6bjFuXpf7SmslikGXwIqgL8=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 6:/5dA+LMUFNEZKJoK8Bd+SqG6D/zkGe9CAC/Btiq0PxQqCNql6BZk3N9mkmHNKdUKw3oZxR4SlOoT2vTtW6VbSEkH1pPCIPtM0IHUYoKbQI1QQKm0QX4zZV+C+HKGx3rNHIssIWPcp2FDA4HS/dRRpTpF8zw5LcOGR/ok9F6k50mSEkh5NYkEGYELC2z0e19UcXMpwtGEteIAlc58Cd9YKieTLb/6w0neenidq5jtsH7bXUbN5bYvje2AP+vj70GmV9hjD0YiArLI5dnEAwLqbEkBN/RODp4g4LppMKoMU9zqKAjVB5dycMtn4dPl5xByNT8efNib2x1x/6uW1QlSacQcSevHE5PHVn8ya8EnMf09sfXQPPIu/wkk4XqMDUKwxljyDpc+iR+0mWGQcf/iLQ==; 5:x9aq5I2oaihtFCPQ+2Hgk+4FvcYdF9BiDggtGExYgjVL7IO6tV/IuO6zMezMr6RsVCqv9xln18INFMgn7uWvCmJEdUb+2/6lgeKsIcNZILyLZ0gHAkiRejZpatoWEMK/m4EzEgNScVA5nlyjhO+tAA==; 24:IqhY+PTJ1SbSrKI6Ua1NJg3w/ukqcdK5mozwSkLEB5QVgVR//3JM7Y0+k9JoyIxHuWy2WYIBLe5sHC68y14JwEuZP3fl5bsEXcpbz423j2g=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DB5PR0101MB1990; 7:FpOVGanm/xZ5/w9HsAA4Eic3IuwQF8JZhQYUylj8bJJDLCmCCIizD0qxgV0LuObbO/pkFrGuBxckorjzpA4iwuF0JAE7iyc6tosnuLwI9zqLbWYViG/weqEVzdPL7kr8BUXqAIB12fUM/zz5uElJzr1A8W9rLNy4WJFWACc6hHEbAPaEhcM30d8KuDbKl0/BY0egfd2TgdRcQbRor7cD+XnuqXbjTKrmeYYCNSIAJQ0rEIt9tWtnHLLsnjqd9VFWVguVeY0Z/YFXnMH7bD4VByEpBJIS0Kn12qD0uOJNCDvK2h7tJfvJMD7p/E6p4A3qYVwVbOB1L5wlkxcgTMVHTifkNa+YwYJ96gt7ZzDmH2rHvyqj1boDF95dURwB/SmkQ9siyJxmIPj0fqIp8taG0bEMnK7leZgUO5wItfhhXozq0aSPATcwLQjKcLV01zLWmgGyalZBFLfx3ShAxfdO0si1cbqz9sKO/jnvtClfN+LNCikgy2Db+7JnnWEI4Paq7E588qN9huL+PjjPmGA6IA==
X-OriginatorOrg: napier.ac.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2017 15:13:15.1774 (UTC)
X-MS-Exchange-CrossTenant-Id: 99e0dc58-9c4b-4820-8617-04c386c254c6
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=99e0dc58-9c4b-4820-8617-04c386c254c6; Ip=[146.176.4.2]; Helo=[owa.napier.ac.uk]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0101MB1990
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/NP_BltjVY951-ZhtW4psKBIJW2k>
Cc: "Al-Dubai, Ahmed" <A.Al-Dubai@napier.ac.uk>, "Ghaleb, Barraq" <B.Ghaleb@napier.ac.uk>, "Romdhani, Imed" <I.Romdhani@napier.ac.uk>
Subject: Re: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 15:13:25 -0000

Hi Pascal
Thanks a lot for your Comments,

Comment (1): The number of children is very indirect and thus not a  good representation of the load expressed in terms of packets/ battery consumption. The number of routes via the children is better but it is only known in storing mode; and the real amount of traffic may be what you are probably after; these could be exposed to the children in parent DIOs.

Response(1): In fact, we agree with you that load balancing is a wider context beyond the distribution of the children. However, we here specifically talk about the load balancing in terms of fairness while linking the children with the appropriate parents. The aim is to avoiding possible bottleneck or host-spot problems that result in congestion, delay and battery depletion at the parents with exceeded number of children. Thus, the number of children is a key factor in contributing to the overall load balancing of the network.

Comment(2): Changing routing based on load has been known to cause oscillations; this is to be considered / avoided.

Response(2): It is really trades-offs between unfairness and oscillation, and the oscillation can be kept to a minimum by two ways:
a) If we use the number of children besides another metrics (e.g. ETX, number of hops,
     etc) to optimize the selection and enhance the stability.
b)  Using the hysteresis threshold for the number of children to switch from parent to   another and thus, enhance the stability of the routs.


Comment(3): One possible angle is to smoothly adapt the load in the forwarding plane as opposed to change the Rank to abruptly. Children with multiple parents could balance their flows based on parent load. We had discussions in the past on the load in storing nodes to avoid having to maintain more routes than the node can actually store in memory. The idea at the time was to answer the DAO-ACK with a status and a metric that would discourage the child, or IOW encourage it to look elsewhere. The benefit of that approach was load balancing (of number of route entries). Problem was still that at some point there could be more routes than the nodes could do with, so people went for non-storing anyway.


Response(3):  Good point. Both storing and non-storing modes in DAO (i.e., the downward routes) is an optional feature in RPL as mentioned in the RFC6550 page 78, "If the MOP is 0, indicating no Downward routing, nodes MUST NOT transmit DAO messages and MAY ignore DAO messages." And the proposed idea targeting the RPL mode of operation without downward routes.


Comment(4): Changing the DIO in a non-backward-compatible fashion is probably not a good idea. Did you consider options?


Response(4): The option will be considered to find an approach that changes the DIO in a backward-compatible fashion.


Comment(5): Section 4 is really hard to read.  For the most part I'm still not sure I understood what is meant there.


Response(5):  This section will be rephrased for better clarity. In short, we injected the IP of the selected parent in the DIO to allow each node to count its number of children.



Comment(6): I figured that the design is that children send DIOs so that their parents will know that they are their parents? This is kind of weird since they parent should ignore DIOs with higher Ranks.  Also unsure why DAO or ND cache can't be used, the explanation confused me. In storing mode, parents have adjacencies for their children that inject DAOs, and these can be counted.


Response(6):  In fact, the DAO is an optional feature when MOP =0 [rfc6550], so I think it is not a good idea to relay on that, that's why using the back DIO from the child node has been considered just to count the number of children via matching the IPs as detailed in the Section 4 without affecting the rank.

Cheers,
Mamoun
From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: 07 February 2017 14:16
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: Al-Dubai, Ahmed <A.Al-Dubai@napier.ac.uk>; Qasem, Mamoun <M.Qasem@napier.ac.uk>; Ghaleb, Barraq <B.Ghaleb@napier.ac.uk>
Subject: RE: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

Hello Imed :

Thanks a bunch for sharing this work.

A bunch of preliminary notes:


-          The number of children is very indirect and thus not a  good representation of the load expressed in terms of packets/ battery consumption. The number of routes via the children is better but it is only known in storing mode; and the real amount of traffic may be what you are probably after; these could be exposed to the children in parent DIOs.

-          Changing routing based on load has been known to cause oscillations; this is to be considered / avoided.

-          One possible angle is to smoothly adapt the load in the forwarding plane as opposed to change the Rank to abruptly. Children with multiple parents could balance their flows based on parent load.

-          We had discussions in the past on the load in storing nodes to avoid having to maintain more routes than the node can actually store in memory. The idea at the time was to answer the DAO-ACK with a status and a metric that would discourage the child, or IOW encourage it to look elsewhere. The benefit of that approach was load balancing (of number of route entries). Problem was still that at some point there could be more routes than the nodes could do with, so people went for non-storing anyway.

-          Changing the DIO in a non-backward-compatible fashion is probably not a good idea. Did you consider options?

-          Section 4 is really hard to read. For the most part I'm still not sure I understood what is meant there. I figured that the design is that children send DIOs so that their parents will know that they are their parents? This is kind of weird since they parents should ignore DIOs with higher Ranks.  Also unsure why DAO or ND cache can't be used, the explanation confused me. In storing mode, parents have adjacencies for their children that inject DAOs, and these can be counted.

Cheers,

Pascal




From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Romdhani, Imed
Sent: lundi 6 février 2017 14:50
To: roll@ietf.org<mailto:roll@ietf.org>
Cc: Al-Dubai, Ahmed <A.Al-Dubai@napier.ac.uk<mailto:A.Al-Dubai@napier.ac.uk>>; Qasem, Mamoun <M.Qasem@napier.ac.uk<mailto:M.Qasem@napier.ac.uk>>; Ghaleb, Barraq <B.Ghaleb@napier.ac.uk<mailto:B.Ghaleb@napier.ac.uk>>
Subject: [Roll] New Draft Submission: Draft-qasem-roll-rpl-load-balancing-00.txt

Dear all,

Hope this finds you well.

We would like to draw your attention that we submitted a new draft for you to consider. You can access it from here:
https://www.ietf.org/id/draft-qasem-roll-rpl-load-balancing-00.txt

This draft proposes an extended Objective Function(OF) that balances the number of children nodes for potential overloaded parents to ensure node lifetime maximization in RPL. In addition, a new DODAG Information Object (DIO) message structure has been introduced to record the IPv6 address of the chosen parent before broadcasting the message.

We do believe that the draft is aligned with ROLL's works items and especially with the manageability issue and the need for additional protocol elements to reduce packet size and the amount of required routing states.

We look forward to receiving your comments and feedback.

Kind regards,
Imed
---------------------------------------------------
Imed Romdhani, PhD
IEEE Member, FHEA
Programme Leader of the MSc Advanced Networking
Room C 64
Edinburgh Napier University
School of Computing
10 Colinton Road
Edinburgh, EH10 5DT
UK
E-Mail:   I.Romdhani@napier.ac.uk<mailto:I.Romdhani@napier.ac.uk>
Home Page: http://www.dcs.napier.ac.uk/~cs244/
Linkedin: http://uk.linkedin.com/in/imedromdhani
Skype: Imed.Romdhani
Telephone: +44(0)131 455 2726
Fax: +44(0)131 455 2727
---------------------------------------------------


This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373



This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373