From jianzche@cisco.com Fri Feb 2 19:23:33 2018 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 E92CB1271DF for ; Fri, 2 Feb 2018 19:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HZS_VZJn2ALu for ; Fri, 2 Feb 2018 19:23:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AB2126CB6 for ; Fri, 2 Feb 2018 19:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8744; q=dns/txt; s=iport; t=1517628211; x=1518837811; h=from:to:cc:subject:date:message-id:mime-version; bh=CSIp8bJYhIQR7AcaTegUHKMWUDNpV6oRggqNjwDGsag=; b=U2sGZ9hhKQ3CR0czKqcfNss6E8CYgsmfF1pKZDal9ZMHnmizJiboIFJj IlhD8yZQkrLGZtCFCaAfHIBZDH9Az6u/zyU9F/jK135iQhKtw+ofMG+8k 9dEbprbwKvTiO8zjWJqCdCrJiJe71+KTPxdZNB7QB2ktmi2PBpnQB2YPF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQCQKnVa/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZRzFmcDKDW5hSk3WHbQqFOxyCHlgUAQEBAQEBAQECayiFTUQ?= =?us-ascii?q?SEgFKAgQwJwQOIIk2ZLZLgieFAIN6ggYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdh?= =?us-ascii?q?GmCFYNogXdeAYUrgz0xgjQFmhyKCAKCBZNpDpQml0QCERkBgTsBNiKBUHAVZwG?= =?us-ascii?q?CHIJUHIIGiluBM4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,452,1511827200"; d="scan'208,217";a="133376416" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2018 03:23:30 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w133NV4D008760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 3 Feb 2018 03:23:31 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 2 Feb 2018 21:23:30 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Fri, 2 Feb 2018 21:23:30 -0600 From: "Charlie Chen (jianzche)" To: Michael Richardson CC: "roll@ietf.org" Thread-Topic: Join preference calculation Thread-Index: AQHTnJ5c/n89yKNnGEiMqY1LhGrk9w== Date: Sat, 3 Feb 2018 03:23:30 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.79.97.86] Content-Type: multipart/alternative; boundary="_000_E370D2F63C2A4C3EAB1691B840247DD9ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 03 Feb 2018 03:30:07 -0000 --_000_E370D2F63C2A4C3EAB1691B840247DD9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KSSBhbSBDaGFybGllIGZyb20gQ2lzY28uIE91ciBncm91cCBpcyBkb2lu ZyBtZXNoIHByb2R1Y3RzIGZvciBncmlkLiBQQU4gbWlncmF0aW9uIGlzIG9uZSBvZiB0aGUgbW9z dCBpbXBvcnRhbnQgZmVhdHVyZXMgaW4gb3VyIG1lc2ggc29sdXRpb24sIHdoaWNoIHdlIHdvdWxk IGxpa2UgdG8ga2VlcCByZWZpbmluZy4NCg0KV2UgYXJlIGludGVyZXN0ZWQgaW4geW91ciBwcm9w b3NhbCBhYm91dCBqb2luIHByZWZlcmVuY2UgYW5kIHdhbnQgdG8gZm9sbG93IGl0IHVwIGluIG91 ciBmdXR1cmUgc29sdXRpb24uDQoNCldlIHRoaW5rIHRoZXJlIGFyZSB0d28gZmFjdG9ycyB0aGF0 IG1heSBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIGNhbGN1bGF0aW9uIGZvciBqb2luIHBy ZWZlcmVuY2UuDQoNCkZpcnN0LCBEQUcgc2VsZWN0aW9uIGFmZmVjdHMgKHNvbWV0aW1lcyBkZWNp ZGVzKSBwYXJlbnQgc2VsZWN0aW9uLiBXZSBmb3VuZCB0aGF0IHNvbWUgbm9kZXMgbWF5IHNlbGVj dCBhIERBRyB3aXRoIGxlc3Mgbm9kZXMgYnV0IGFsc28gYSBwYXJlbnQgd2l0aCB0b28gbWFueSBj aGlsZHJlbi4gSXQgdGFrZXMgYSBjZXJ0YWluIG9mIHRpbWUgZm9yIHRoZSBub2RlIHRvIHJlc2Vs ZWN0IGEgYmV0dGVyIHBhcmVudC4NClRodXMsIGlmIGpvaW4gcHJlZmVyZW5jZSBnaXZlcyBzb21l IGluZGljYXRpb24gbGlrZSByYW5rIGFuZCBjaGlsZHJlbiBudW1iZXIsIGEgbm9kZSB3b3VsZCBt YWtlIGEgcmlnaHQgZGVjaXNpb24gYXQgdGhlIGJlZ2lubmluZy4NCg0KU2Vjb25kLCBjYXBhY2l0 eSBsaW1pdCBpcyBhbm90aGVyIHNlbWFudGljcyB0aGF0IGpvaW4gcHJlZmVyZW5jZSBtYXkgbmVl ZCB0byBjYXJyeSwgY29uc2lkZXJpbmcgYWdncmVnYXRlZCBiYW5kd2lkdGggYW5kIG1lbW9yeSBz aXplIG9uIHRoZSByb290IG5vZGUuIEVzcGVjaWFsbHksIHdoZW4gcm9vdCBub2RlcyB3aXRoIGRp ZmZlcmVudCBjYXBhY2l0eSBhcmUgZGVwbG95ZWQsIG1lc2ggbm9kZXMgaGF2ZSBubyBjbHVlIHRv DQpkZWNpZGUgd2hldGhlciB0byBqb2luIGEgREFHIHdpdGggNjAtbm9kZXMgY2FwYWNpdHkgYW5k IDUwIG5vZGVzIGpvaW5lZCBvciBhIERBRyB3aXRoIDEwMDAtbm9kZXMgY2FwYWNpdHkgYW5kIGFs c28gNTAgbm9kZXMgam9pbmVkLiBJZiB0aGUgbGltaXQgb2Ygc3VwcG9ydGVkIG5vZGVzIG9yIGN1 cnJlbnQgdXRpbGl6YXRpb24gaXMgY2FycmllZCwgYSBtZXNoIG5vZGUgY2FuIGNvbXBhcmUgdHdv IERBR3MgaW4gYSByZWFzb25hYmxlIHdheS4NCg0KQWJvdmUgYXJlIG91ciBwcmVtYXR1cmUgdGhv dWdodHMuIFdlIGFyZSBsb29rIGZvcndhcmQgdG8gdGhlIG5hcnJvd2luZyBkb3duIG9mIGpvaW4g cHJlZmVyZW5jZSBjYWxjdWxhdGlvbi4NCg0KVGhhbmsgeW91Lg0KDQpCZXN0IHJlZ2FyZHMsDQpD aGFybGllDQo= --_000_E370D2F63C2A4C3EAB1691B840247DD9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOetiee6 vyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4 dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OkRlbmdYaWFuO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OkRlbmdYaWFuOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+SGkgTWljaGFlbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SSBhbSBDaGFybGllIGZyb20gQ2lzY28uIE91ciBn cm91cCBpcyBkb2luZyBtZXNoIHByb2R1Y3RzIGZvciBncmlkLiBQQU4gbWlncmF0aW9uIGlzIG9u ZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZXMgaW4gb3VyIG1lc2ggc29sdXRpb24sIHdo aWNoIHdlIHdvdWxkIGxpa2UgdG8ga2VlcCByZWZpbmluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5XZSBhcmUg aW50ZXJlc3RlZCBpbiB5b3VyIHByb3Bvc2FsIGFib3V0IGpvaW4gcHJlZmVyZW5jZSBhbmQgd2Fu dCB0byBmb2xsb3cgaXQgdXAgaW4gb3VyIGZ1dHVyZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+V2Ug dGhpbmsgdGhlcmUgYXJlIHR3byBmYWN0b3JzIHRoYXQgbWF5IG5lZWQgdG8gYmUgY29uc2lkZXJl ZCBpbiB0aGUgY2FsY3VsYXRpb24gZm9yIGpvaW4gcHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Rmly c3QsIERBRyBzZWxlY3Rpb24gYWZmZWN0cyAoc29tZXRpbWVzIGRlY2lkZXMpIHBhcmVudCBzZWxl Y3Rpb24uIFdlIGZvdW5kIHRoYXQgc29tZSBub2RlcyBtYXkgc2VsZWN0IGEgREFHIHdpdGggbGVz cyBub2RlcyBidXQgYWxzbyBhIHBhcmVudCB3aXRoIHRvbyBtYW55IGNoaWxkcmVuLiBJdCB0YWtl cyBhIGNlcnRhaW4gb2YgdGltZQ0KIGZvciB0aGUgbm9kZSB0byByZXNlbGVjdCBhIGJldHRlciBw YXJlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5UaHVzLCBpZiBqb2luIHByZWZl cmVuY2UgZ2l2ZXMgc29tZSBpbmRpY2F0aW9uIGxpa2UgcmFuayBhbmQgY2hpbGRyZW4gbnVtYmVy LCBhIG5vZGUgd291bGQgbWFrZSBhIHJpZ2h0IGRlY2lzaW9uIGF0IHRoZSBiZWdpbm5pbmcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPlNlY29uZCwgY2FwYWNpdHkgbGltaXQgaXMgYW5vdGhlciBzZW1hbnRpY3MgdGhh dCBqb2luIHByZWZlcmVuY2UgbWF5IG5lZWQgdG8gY2FycnksIGNvbnNpZGVyaW5nIGFnZ3JlZ2F0 ZWQgYmFuZHdpZHRoIGFuZCBtZW1vcnkgc2l6ZSBvbiB0aGUgcm9vdCBub2RlLiBFc3BlY2lhbGx5 LCB3aGVuIHJvb3Qgbm9kZXMgd2l0aCBkaWZmZXJlbnQNCiBjYXBhY2l0eSBhcmUgZGVwbG95ZWQs IG1lc2ggbm9kZXMgaGF2ZSBubyBjbHVlIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 Ij5kZWNpZGUgd2hldGhlciB0byBqb2luIGEgREFHIHdpdGggNjAtbm9kZXMgY2FwYWNpdHkgYW5k IDUwIG5vZGVzIGpvaW5lZCBvciBhIERBRyB3aXRoIDEwMDAtbm9kZXMgY2FwYWNpdHkgYW5kIGFs c28gNTAgbm9kZXMgam9pbmVkLiBJZiB0aGUgbGltaXQgb2Ygc3VwcG9ydGVkIG5vZGVzIG9yIGN1 cnJlbnQgdXRpbGl6YXRpb24gaXMgY2FycmllZCwNCiBhIG1lc2ggbm9kZSBjYW4gY29tcGFyZSB0 d28gREFHcyBpbiBhIHJlYXNvbmFibGUgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BYm92ZSBhcmUgb3VyIHBy ZW1hdHVyZSB0aG91Z2h0cy4gV2UgYXJlIGxvb2sgZm9yd2FyZCB0byB0aGUgbmFycm93aW5nIGRv d24gb2Ygam9pbiBwcmVmZXJlbmNlIGNhbGN1bGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5UaGFuayB5b3Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PkNoYXJsaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_E370D2F63C2A4C3EAB1691B840247DD9ciscocom_-- From nobody Mon Feb 5 00:22:04 2018 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 1FDBF128C0A for ; Mon, 5 Feb 2018 00:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL6f1GnaEiti for ; Mon, 5 Feb 2018 00:22:01 -0800 (PST) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4B91241F5 for ; Mon, 5 Feb 2018 00:22:01 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:217]) by smtp-cloud9.xs4all.net with ESMTPA id ic2IeFWV6oWCOic2IeqD5B; Mon, 05 Feb 2018 09:21:59 +0100 Received: from AMontpellier-654-1-119-113.w90-0.abo.wanadoo.fr ([90.0.134.113]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 05 Feb 2018 09:21:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 05 Feb 2018 09:21:58 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfADHtJinAepV75JAXaYYRXroZbjAq7d+5Wt1/dHwlBm0qJtTQj9wX41z/W6a8XaPGp566nloMa+C0/TJ7P1rg9aBp3Kcj/QV5HwH0kCXwqJOn6YOwYjJ C6lycSJebAPjr8ZiBuCvvvYQJLv+hYEqCLcSv+4CTeXCUovlqQao1/SnxbXkQ2DbYJKY3DMl0u7KYGEm6v+UtXSaWOC5+U8mN72JDXwAtdD6CA0bRJho6bZ8 ZhZkybvN3hfxsPG9n6LUZQ== Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 05 Feb 2018 08:22:04 -0000 Hi Charlie, is is an interesting subject that needs more reflection. It is not clear to me when the join selection takes place; Is this before or after enrollment of the node in the mesh? Dependent on that choice, different techniques are called for, in my view. I like to draw your attention to the ROLL meeting in London that will discuss the coordination of the different parent selection and ranking algorithms that are currently proposed. It would be good if we could give your subject a place in the currently ongoing and proposed ROLL work. Cheerio, Peter Charlie Chen (jianzche) schreef op 2018-02-03 04:23: > Hi Michael, > > I am Charlie from Cisco. Our group is doing mesh products for grid. > PAN migration is one of the most important features in our mesh > solution, which we would like to keep refining. > > We are interested in your proposal about join preference and want to > follow it up in our future solution. > > We think there are two factors that may need to be considered in the > calculation for join preference. > > First, DAG selection affects (sometimes decides) parent selection. We > found that some nodes may select a DAG with less nodes but also a > parent with too many children. It takes a certain of time for the node > to reselect a better parent. > > Thus, if join preference gives some indication like rank and children > number, a node would make a right decision at the beginning. > > Second, capacity limit is another semantics that join preference may > need to carry, considering aggregated bandwidth and memory size on the > root node. Especially, when root nodes with different capacity are > deployed, mesh nodes have no clue to > > decide whether to join a DAG with 60-nodes capacity and 50 nodes > joined or a DAG with 1000-nodes capacity and also 50 nodes joined. If > the limit of supported nodes or current utilization is carried, a mesh > node can compare two DAGs in a reasonable way. > > Above are our premature thoughts. We are look forward to the narrowing > down of join preference calculation. > > Thank you. > > Best regards, > > Charlie > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Feb 5 05:34:34 2018 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 113AF12D7E8 for ; Mon, 5 Feb 2018 05:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3vDF0fxeyEqe for ; Mon, 5 Feb 2018 05:34:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BCF12426E for ; Mon, 5 Feb 2018 05:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6206; q=dns/txt; s=iport; t=1517837670; x=1519047270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j82BIpQNMgwPhZ5SMuity1IMeQ27AgLJ1kaL1HY5JmY=; b=BVWNtwgJG9AHzl/3KiYkUGB+3B7+DOL3UMz+0XxvgoBFWyi8G055f9Ig C0gs041ojM6xRd1Fikxt+Jiv4OzE29eOb/JIlUsVZZNk17HQxr5W3nxLr 62oRoUJr7vR59SK0y0vodScH4uttDyNwaSz11NONDUZbL3wqSDZrrfK6d U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AQDtXHha/5pdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkLWZwKAqcLIICl0iCGAoYC4UYAoJHVRcBAQEBAQEBAQJrKIU?= =?us-ascii?q?jAQEBBAEBZQcGBQwEAgEIEQEDAQEoBycLFAMGCAIEAQ0FCBOKGhDBc4hyggYBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYRqghWBV4FogiCBDoMvAQECgS4NDgMHSIV?= =?us-ascii?q?QBYgCgl2IM4Eoj2sCkBOFU5RAl0kCERkBgTsBIQI1gVBwFT2CRoJVHIEKAQF6e?= =?us-ascii?q?It0gTOBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,464,1511827200"; d="scan'208";a="352134853" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2018 13:34:18 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w15DYIES027948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2018 13:34:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 5 Feb 2018 07:34:17 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 5 Feb 2018 07:34:17 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Michael Richardson" CC: "Charlie Chen (jianzche)" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] Join preference calculation Thread-Index: AQHTnJ5c/n89yKNnGEiMqY1LhGrk96OV4B8A//+gtRA= Date: Mon, 5 Feb 2018 13:34:01 +0000 Deferred-Delivery: Mon, 5 Feb 2018 13:33:48 +0000 Message-ID: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 05 Feb 2018 13:34:33 -0000 Hello Peter and Michael >From an architecture point of view, RPL either ignores or mixes the prefere= nce for the network, the DODAG in the network, the Join Proxy in the DODAG = at join time, the parent in the DODAG once joined, and then the next hop at= forwarding time, all in one concept of Rank.=20 This is way to concise and creates all sorts of side effects in the field, = such as nodes flapping between DODAGs. The metrics to be used for the different stages vary widely. As a summary = of a talk with you and Michael, I see that the stages should be: 1) Select a Network. The network ID whatever that is could be hashed into o= ne octet. An example could be the /64 folded on itself using XOR. A network= in which the join process failed should be blacklisted for a while, and pl= aced at the bottom of the queue of networks to be tried then. 2) Select a DODAG in that network. There is a need for a DODAG-level Rank v= alue that is different from the RPL Rank; a new node should join the DODAG = with the best value for that DODAG-Rank and for which a Join Proxy exists. = A node that already participates to a DODAG should also jump onto the best = DODAG with appropriate dampening to avoid mass jumps and oscillations. Metr= ics that contribute to that DODAG-Rank could include the load at the root, = in terms of available bandwidth and capacity to accept new children. Batter= y levels could also be accounted for there. This can be compressed into a o= ne-octet DODAG-Rank using a new PAN-Selection-OF. 3) Select a Join Proxy within the preferred DODAG. There is a need for a JP= -Rank value that is also different from the RPL Rank. Join-Proxy is a capab= ility which decreases with the number of attached nodes down to a maximum. = That maximum can be bound to a maximum number of devices that are attemptin= g a join via this proxy. Other parameters may influence the JP-Rank, e.g. n= etwork selection, DODAG selection, the bandwidth to the root, the Rank of t= he JP in the DODAG, etc... A candidate JP must advertise the relevant infor= mation in its beacons for nodes to make an appropriate selection. This can = be compressed into a one-octet JP-Rank using a new join-OF. 4) Once joined, select parent(s) within the preferred DODAG to extend it wi= th self. This is what the Rank in RFC 6550 does. Though new OFs and metrics= can be devised, this is not the object of this discussion 5) Once routing is established, select a parent or a child for packet forwa= rding. Forwarding time needs metrics that reflect the immediate state of th= e next hop whereas routing builds longer term topologies that leave multipl= e possible selections for the forwarding to make. This is why RPL builds DO= DAG but does not discuss forwarding at all. This is not the object of this = discussion either. I see that defining all the above belongs to ROLL and that 6TiSCH is concer= ned with expressing requirements and mapping the information back into IEEE= std 802.15.4 beacons. All in all, 6TiSCH recommends not to beacon till L3 = is up and running (including RPL) and then to set the 802.15.4 Join prefere= nce in beacons with the Rank. Michael's draft indicates that this is not en= ough and propose a 4 tuple: netID, DODAG_Rank, JP-Rank, and RPL Rank. This = will probably require a new IE. Cheers, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: lundi 5 f=E9vrier 2018 09:22 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] Join preference calculation Hi Charlie, is is an interesting subject that needs more reflection. It is not clear to me when the join selection takes place; Is this before o= r after enrollment of the node in the mesh? Dependent on that choice, different techniques are called for, in my view. I like to draw your attention to the ROLL meeting in London that will discu= ss the coordination of the different parent selection and ranking algorithm= s that are currently proposed. It would be good if we could give your subject a place in the currently ong= oing and proposed ROLL work. Cheerio, Peter Charlie Chen (jianzche) schreef op 2018-02-03 04:23: > Hi Michael, >=20 > I am Charlie from Cisco. Our group is doing mesh products for grid. > PAN migration is one of the most important features in our mesh=20 > solution, which we would like to keep refining. >=20 > We are interested in your proposal about join preference and want to=20 > follow it up in our future solution. >=20 > We think there are two factors that may need to be considered in the=20 > calculation for join preference. >=20 > First, DAG selection affects (sometimes decides) parent selection. We=20 > found that some nodes may select a DAG with less nodes but also a=20 > parent with too many children. It takes a certain of time for the node=20 > to reselect a better parent. >=20 > Thus, if join preference gives some indication like rank and children=20 > number, a node would make a right decision at the beginning. >=20 > Second, capacity limit is another semantics that join preference may=20 > need to carry, considering aggregated bandwidth and memory size on the=20 > root node. Especially, when root nodes with different capacity are=20 > deployed, mesh nodes have no clue to >=20 > decide whether to join a DAG with 60-nodes capacity and 50 nodes=20 > joined or a DAG with 1000-nodes capacity and also 50 nodes joined. If=20 > the limit of supported nodes or current utilization is carried, a mesh=20 > node can compare two DAGs in a reasonable way. >=20 > Above are our premature thoughts. We are look forward to the narrowing=20 > down of join preference calculation. >=20 > Thank you. >=20 > Best regards, >=20 > Charlie > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Feb 5 06:09:54 2018 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 C4DAC12D7FC for ; Mon, 5 Feb 2018 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2LBG7pb6fiU for ; Mon, 5 Feb 2018 06:09:51 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3375112D7F9 for ; Mon, 5 Feb 2018 06:09:50 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:217]) by smtp-cloud9.xs4all.net with ESMTPA id ihSveIcbJoWCOihSves8Fg; Mon, 05 Feb 2018 15:09:49 +0100 Received: from AMontpellier-654-1-119-113.w90-0.abo.wanadoo.fr ([90.0.134.113]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 05 Feb 2018 15:09:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 05 Feb 2018 15:09:49 +0100 From: peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <9bb9508ceb881410de286f4a5f5a44d1@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFQyBfUjDyEhJTvaZ4xz+aYYg+qKdpqlIYDW0ZOglJpMX9QHEfYuiVdPwnixIVDVab65a7pzsxp/hAjzxeoQsXt6IJfYla1E605B3gs7Oz72DvJ+7rCJ 4JRsq+173WQ8EcGx7hq8JoNwSqQg7tpulTEV1n8sTDTaR4EdRrE4R4NwOwm6wI/yO0da3r7Lvbj33OFMSnKKhy40eFKvT9GrKZ0= Archived-At: Subject: [Roll] ietf 101 agenda of ROLL WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 05 Feb 2018 14:09:53 -0000 Hi ROLL members, At ietf101 there will be two sessions. One session concerns two special subjects not relevant to this mail. A second session concerns the ROLL drafts and progress. For this second session I ask for your suggestion for topics with the following info, Presenter (remote/London based) draft specific subject reason needed time Looking forward to a lively discussion in London, because the Mailing List is relatively silent. Also there were promises about drafts which were dormant for some time. Many thanks, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Wed Feb 7 12:33:09 2018 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 E42AA12778E for ; Wed, 7 Feb 2018 12:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHXtShT8JnpG for ; Wed, 7 Feb 2018 12:33:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D78126D05 for ; Wed, 7 Feb 2018 12:33:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D8DA200A3 for ; Wed, 7 Feb 2018 15:39:38 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4542980F9C for ; Wed, 7 Feb 2018 15:33:04 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 20:33:08 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > is is an interesting subject that needs more reflection. > It is not clear to me when the join selection takes place; Is this before or > after enrollment of the node in the mesh? yes, that's exactly the tusscle. My take is that the enrolling pledge should not care about parent selection. If it turns out the Join Proxy it selected is not a good Parent, then that's okay, it will see other DIOs and pick them. Others suggest that the there may be different LLNs with different credentials, and that enrolling in the wrong LLN (even though one has appropriate credentials) means that the new node will not see the right parent offers. I dispute that such a situation is secure. I would like to separate the discussions, I really don't want to conflate them. >> Hi Michael, >> >> I am Charlie from Cisco. Our group is doing mesh products for grid. "grid" == smartgrid, meaning AMI? >> PAN migration is one of the most important features in our mesh >> solution, which we would like to keep refining. I would like to understand what "PAN migration" really means. I understand that the PANID could change, but what else will change? Why does the PANID need to change? Has the node moved? How are the administration/management of the two PANs related? Will a new 2-byte layer-2 short address need to be assigned? >> Second, capacity limit is another semantics that join preference may >> need to carry, considering aggregated bandwidth and memory size on the >> root node. Especially, when root nodes with different capacity are >> deployed, mesh nodes have no clue to >> >> decide whether to join a DAG with 60-nodes capacity and 50 nodes >> joined or a DAG with 1000-nodes capacity and also 50 nodes joined. If >> the limit of supported nodes or current utilization is carried, a mesh >> node can compare two DAGs in a reasonable way. Can you explain the topology and the management situation such that these LLNs are separate, yet a node has the ability to see/hear traffic from both? To me, what I see is a problem that occurs only in a network with no security. Looking forward to talking about this at 101. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7Yn8ACgkQgItw+93Q 3WWVSggAiJkYmhzlGpMy+htky+XnoEDQAMkNL/YAXXYwXA0runQrisYPtSwIWZeF 3drSNS/VCaKM5WJSd97mwaRHLs1y6ad2VbdfTu75MYkSHvLJpYqfwxivkPUEDs0l R90OW+5mx2YKMiToaU6dK+bBHPZyZ5In/laF57dsXt6wSEX0lDeNixQh3nOgk1RH bg1NUqDAo5VVj+bGwcT3ssHmSvsz27f1PgVQoxvsGK4H6RtCEvlXbwIeSTDuJHuC OVyAgbMsKGUFRANSNZPI6ZMRw+lU+m1Kj2DgJxsQoScXFk25KHdRwmywHV3nTNJT drdK50bXBHP7W+RJjBciM6J17nMZrw== =w51x -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 8 04:38:04 2018 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 20045129BBF for ; Thu, 8 Feb 2018 04:38:03 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 whMF1M3Jqknx for ; Thu, 8 Feb 2018 04:38:00 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAC9124D6C for ; Thu, 8 Feb 2018 04:37:59 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 7E5138E7 for ; Thu, 8 Feb 2018 13:37:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1518093477; bh=8He4d/gUnu4fAsQKNgBh6XIwqbVc9noD8Ow+jdDYAU4=; h=In-Reply-To:References:From:Date:Subject:To:From; b=ibMMd20oXDP+5BF3sAnHvXqauKWjRMn4yg1OTwKL6B06EdmyzO4W/QfRpNzDptdcz rzg/XPOwTo7zkT1fugRPUpCIHrqDC+xRIrszEwx6/WEqhfExP9BB9G4C1a++pD/ydP vjUOpgq6JXVgtYA2AriqknKx/rLjc/2FV1RkgzAb7vBE3uVbrHVCFkW6dqVqqXanyo YDgKW4qnwL97+uan8NRL3fFc3LeSgCVO2JRaxZUuIhQZdjEBSEF5KcLVlnkSQ4eOKf 3ys7rNTyAVNz72bD3Tv7n5bu3DFHSriQqhiTN4RfM8FdLVW8c8W937wPpCGbfJIE+y BnKnZwmZDerMA== Received: from mail-qt0-f175.google.com ([209.85.216.175]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Thu, 8 Feb 2018 13:37:53 +0100 (CET) Received: by mail-qt0-f175.google.com with SMTP id f4so5926536qtj.6 for ; Thu, 08 Feb 2018 04:37:52 -0800 (PST) X-Gm-Message-State: APf1xPCCD9TYJ5PI6OpR+iFh/PyJlhzwgrsTOizTWHK5zAdFBXxSUhl6 PD142c7FuHUvZ81QmHEyacBHpKW3Z1j89iiVFQ8= X-Google-Smtp-Source: AH8x226xqTg+9Rvf52rUi3HuSJgC9wd2GwXdytjJx99nHOWTWRJIyDeba4wU1hTzLEd0viOI1Bkr9XS4KeXPbpuadbM= X-Received: by 10.200.55.182 with SMTP id d51mr818034qtc.61.1518093470528; Thu, 08 Feb 2018 04:37:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.181.173 with HTTP; Thu, 8 Feb 2018 04:37:30 -0800 (PST) In-Reply-To: <9bb9508ceb881410de286f4a5f5a44d1@xs4all.nl> References: <9bb9508ceb881410de286f4a5f5a44d1@xs4all.nl> From: Remous-Aris Koutsiamanis Date: Thu, 8 Feb 2018 13:37:54 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a114628880c14600564b2aea7" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] ietf 101 agenda of ROLL WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 12:38:03 -0000 --001a114628880c14600564b2aea7 Content-Type: text/plain; charset="UTF-8" Dear Peter, I would like to request time to do two short presentations at IETF 101: Topic 1: Presenter: London-based draft: draft-ji-roll-traffic-aware-objective-function-00 specific subject: A Traffic-aware Objective Function, to aid in better network traffic load balancing. reason: Present some preliminary results. Discussion on potential extensions / improvements. needed time: 5 minutes. Topic 2: Presenter: London-based draft: draft-koutsiamanis-roll-nsa-extension-01 specific subject: RPL DAG Metric Container (MC) Node State and Attribute (NSA) object type extension reason: The definition of a new optional TLV in the Node State and Attribute (NSA) object type (within DAG Metric Containers) to allow sending a list of parent addresses. The primary envisioned use is to aid in parent selection when doing packet replication and elimination. needed time: 5 minutes. Regards, Aris On Mon, Feb 5, 2018 at 3:10 PM, peter van der Stok wrote: > Hi ROLL members, > > At ietf101 there will be two sessions. > One session concerns two special subjects not relevant to this mail. > A second session concerns the ROLL drafts and progress. > > For this second session I ask for your suggestion for topics with the > following info, > Presenter (remote/London based) > draft > specific subject > reason > needed time > > Looking forward to a lively discussion in London, because the Mailing List > is relatively silent. > Also there were promises about drafts which were dormant for some time. > > Many thanks, > > Peter > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a114628880c14600564b2aea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Peter,

I would like to re= quest time to do two short presentations at IETF 101:

Topic 1:
= =C2=A0Presenter: London-based
=C2=A0draft: draft-ji-roll-traffic-aware-<= wbr>objective-function-00
=C2=A0specific subject: A Traffic-aware Object= ive Function, to aid in better network traffic load balancing.
=C2=A0rea= son: Present some preliminary results. Discussion on potential extensions /= improvements.
=C2=A0needed time: 5 minutes.

Topic 2:
=C2=A0Pr= esenter: London-based
=C2=A0draft: draft-koutsiamanis-roll-nsa-exte= nsion-01
=C2=A0specific subject: RPL DAG Metric Container (MC) Node Stat= e and Attribute (NSA) object type extension
=C2=A0reason: The definition of a new optional TLV in the Node State and Attribute=20 (NSA) object type (within DAG Metric Containers) to allow sending a=20 list of parent addresses. The primary envisioned use is to aid in parent selection=C2=A0 when doing packet replication and elimination.
=C2=A0ne= eded time: 5 minutes.

Regards,
Aris

On Mon, Feb 5, 2018 at 3:10 PM,= peter van der Stok <stokcons@xs4all.nl> wrote:
Hi ROLL members,

At ietf101 there will be two sessions.
One session concerns two special subjects not relevant to this mail.
A second session concerns the ROLL drafts and progress.

For this second session I ask for your suggestion for topics with the follo= wing info,
Presenter (remote/London based)
draft
specific subject
reason
needed time

Looking forward to a lively discussion in London, because the Mailing List = is relatively silent.
Also there were promises about drafts which were dormant for some time.

Many thanks,

Peter --
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

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

--001a114628880c14600564b2aea7-- From nobody Thu Feb 8 05:40:51 2018 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 06CB912D963 for ; Thu, 8 Feb 2018 05:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UnWOLAgpGbN6 for ; Thu, 8 Feb 2018 05:40:48 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1149B12D961 for ; Thu, 8 Feb 2018 05:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4823; q=dns/txt; s=iport; t=1518097248; x=1519306848; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1X+L2fkCteqm9AbNhKCPvbJHcNePpVPsl2y01Up9MUc=; b=AXQmEsaHzqtTYK0wRJcos4pGqzQY/8LI1sVB1/9+kw9UAQsDitgCZ4Ue gsXEdtb3bRSGjOObci+wtLeo4zQeHkWyJj61ie3cFXwBsmEY9Mjl5KB9y aLmn9vJLhVFK5H5hMg4xnbgqg/QPr21wBx7wkBDvpzaXEps1zeD7h1fh1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAADVUnxa/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkLWZwKAqNf44mggKXVYIYChgLhRgCgipUGAECAQEBAQEBAms?= =?us-ascii?q?ohSMBAQEBAwEBOA8lFwQCAQgRAQMBAR8JBycLFAMGCAIEEwiKLRCxU4h3ggoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhHmCFYFXgWiDLoMvAQECAYFHhiMFimIIh2K?= =?us-ascii?q?BdYVjigcJAogchAWJUIInhieLeYsTgmmJYwIRGQGBOwEfOYFQcBU9gkYJg3IBA?= =?us-ascii?q?wpueIsGgTSBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,478,1511827200"; d="scan'208";a="356549961" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 13:40:10 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w18DeAUk028737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2018 13:40:10 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 8 Feb 2018 07:40:10 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Thu, 8 Feb 2018 07:40:10 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] Topics and drafts within Roll charter Thread-Index: AQHTQNLOqoJTgwkJDU+rpGwODgjDXqObQeYw Date: Thu, 8 Feb 2018 13:40:04 +0000 Deferred-Delivery: Thu, 8 Feb 2018 13:40:01 +0000 Message-ID: <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> In-Reply-To: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 13:40:50 -0000 Hello Peter: I encourage the WG to consider your list carefully and respond. My personal priorities would be: 1) Item 4. This deals with actual field problems, and is a preerq for the J= oin Process that 6TiSCH is working on. Michael has a draft and I'm willing = to contribute together with Charlie from Cisco. 2) item 2+5, seem to be the same to me. This is a rather easy work once rfc= 6775-update is passed and I'm willing to start/contribute Take care, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: lundi 9 octobre 2017 09:47 To: Roll Subject: [Roll] Topics and drafts within Roll charter Hi Roll, In a discussion with Rahul and Pascal, it transpires that there are still m= any topics to address that fit within our charter. The proliferation of top= ics worries us a bit. We have only a limited number of active authors and s= ome topics also seem to be competing. The result of this situation might be= that we have an overflowing work agenda.=20 Therefore, we need to find additional people to work on those topics; or re= duce the number of topics. It is our suggestion that we discuss these topics, find dedicated authors, = and prioritize them after some debate on the M-L. Also we should like to remove the competitive subjects by joining them into= one draft. Your comments please. Ines + Peter ------------------------ List of topics ------------------------------------------ 1 Route invalidation as a standalone topics The topic is mentioned in sever= al drafts, but we need to come to one general approach. 2.A draft that allows a ND only device to connect, be reachable and move in= a RPL network. 3. Not all implementers are aware of the design issues of storing mode of R= PL vs non-storing. Both of the modes have issues with their design.=20 Some issues are getting sorted out by drafts such as dao-projection and no-path = DAO optimization. But still considerable design issues need to be handled. = To name few: a. handling parent switching optimally in storing MOP. Currently with Stori= ng MOP it would lead to DIO/DAO storm in the sub-path from the child node w= ho switches the parent. This is handled well in NS MOP (Non-storing MOP). b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is t= rivial, but in most cases it is not (considering dependence on several stat= e variables such as DTSN across reboots)! Also for practical point of view,= need to consider that writing to flash/NV-memory is not a good option in e= mbedded devices and should be avoided as far as possible. c. Problems of current DAO-ACK in storing MOP. There was a discussion on ML= long time back, but there is no draft in the space. d. problem of bulging IPv6 headers in NS MOP. Most part of this will be tak= en care of by SRH compression and dao-projection. 4. Confusion between DAG selection (for joining and jumping) vs. parent sel= ection (for re-parenting within a DODAG). 6TiSCH has isolated the need for = a join preference which is different from the Rank used in parent selection= . The resulting Rank may be used in the join preference, but not only. The = size of the DODAG, the number of children of that parent, etc... may influe= nce. There is basically the need for a new sort of objective function, this= time in order to select a DODAG to join. 5. Integration with 6LoWPAN. We need to write that draft that standardizes = the procedures suggested in the 6TiSCH architecture and shows a non RPL awa= re joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP DA= O, we now have all the tools to do it. Unless we consider that the referenc= e is the 6TiSCH architecture in which case we complete the design there. 6. Exposing (some of) the structure of the Mesh to the root to enable the D= AO projection for transversal routes and in storing mode in general. 7. Using bitmaps for multicast and unicast routing, used in 7a routing tables, or 7b in header for source routing 8. Guidance to implementers who are relatively new to RPL are not aware of = many design considerations and there should be a doc which talks about it. = Similar work is started in https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but it= does not list all the issues imo. 9. What to do with expired YANG model drafts 10. What else do you think that we should consider? -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Thu Feb 8 09:58:23 2018 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 9CD2C126E64 for ; Thu, 8 Feb 2018 09:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMxqctAPDEZX for ; Thu, 8 Feb 2018 09:58:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBEA126C2F for ; Thu, 8 Feb 2018 09:58:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 981BB200A3 for ; Thu, 8 Feb 2018 13:04:55 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 27D7880BBF for ; Thu, 8 Feb 2018 12:58:18 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 17:58:21 -0000 --=-=-= Content-Type: text/plain I would like 5 minutes for two slides on: > 4. Confusion between DAG selection (for joining and jumping) vs. parent > selection (for re-parenting within a DODAG). 6TiSCH has isolated the > need for a join preference which is different from the Rank used in > parent selection. The resulting Rank may be used in the join > preference, but not only. The size of the DODAG, the number of children > of that parent, etc... may influence. There is basically the need for a > new sort of objective function, this time in order to select a DODAG to > join. I specifically want to provide definitions for: 1) enrollment. 2) joining. 3) jumping. I will add these definitions to: draft-richardson-6tisch-roll-enrollment-priority-00 (which I've renamed from draft-richardson-6tisch-roll-join-priority-02) I've already presented the above document (was it at 98?), but still no WG adoption call. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp8j7kACgkQgItw+93Q 3WWMoQf/Q8VTLF5KuB9YomvFUHNzF7jmUS4IgAiW+yuXFQdwSEpIMvrC0JoiUufv SXmy2ykXOujfzNTqNh9PTODivS1pTtvjKnG9ivngNB++xsGsDhxi/16DaoTYa+ur tEMM+5MdEdJksFPsIUNSo3jcIQZSxY91af1lmjU1/JyX0AnOVUQ5DBHaVOfVRZSW n+Fost0HvtuXQ87vH3DzIspHEllt9ggcLcs6kc6jONnj8mx/QJKei44SI8aMFDMv jEdUHkrDYVmkd8RLGMapjyBJ9u2ADta/8u4ZJdcDcf4JZN4Nr8Ee8kNUVR41TZ9D qkw2lYQ27iZpjVmUKUgqf5aEPd4pwQ== =Ik7X -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 10 00:52:51 2018 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 21C63127871; Sat, 10 Feb 2018 00:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 P3UIZhTN31hc; Sat, 10 Feb 2018 00:52:45 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B89E124234; Sat, 10 Feb 2018 00:52:44 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id f18so9941879otf.6; Sat, 10 Feb 2018 00:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gwi3l1anZAAgy53vuXXc39bOQl3S0WqwHe7VrrLGQUQ=; b=hcJ7crF366tn61cYQpwTYJnuzQKRth774XkxfPxwLc8akX9OHBcKkcHtwhBtAsmaRc X2fiDnM+MVnGfi9CLWdqAI0fVZ9VYQCoXBaGhJFx5q5eRb5fjg8rc7uxg3dlsSJ6v6WG Ybdw+vnDLtaAO4xKqIbPuOk/7/ihu5Og3HAVsR9peS5/re9FQhdrQNuDUSwQtE6Cu0LP DUummWWgUuT5G4pT9sqa46Tf/xPyAQfwnI+Dt6gbcYK/lV/oCn9fozm8uFuz1RBm+ElM WkVG3xEKoG/R+WEQkxhHb6kjDvGTb6alOHigklQg+pV0R79ZVrqdNkawu2jb+lWhXHRv YzbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gwi3l1anZAAgy53vuXXc39bOQl3S0WqwHe7VrrLGQUQ=; b=cdSH5ROFAzvfbKa3bLj4L0hCi01ktKWhQzFrli589+L7qqSujKbLA2BCzM+OmYXtIb zBnI629ozq6DMtOVMVk6gk00Oqv1KEx2nooM37QyL4ATQQjusxonZjn/YqYOlLg5CKhs bK8W0FmcvK47dSzenfbSJtUjN1LqcC2ZO0SFBofTzlzGClEWLERPjBELM55n0/16JD/e B7mHpe8Nyfc1X6m9wsmUMOCOxMvPhEFrXxKhIlppnCvRB1k7MFUKWFMKWqCia755FzI3 F4MDjDAPyGSUqlghHrGuJkFYBBUmELHzDZOabyGHU6hsEpCJiljWlx0621OtGC2XIPPf enzw== X-Gm-Message-State: APf1xPAmw0ZOq5bIsLqaf4JWJVthasHaFTAVZrkF2fHzPVjqoePaaq3x wi7FFx8qTmII7TvqEcRwGMOdzzXc9xBxY28Z624= X-Google-Smtp-Source: AH8x224vHrdqKnUH6KZDuRMIG0QOve2/kawc7vqrMcu225AXzWSJO2s6v4tVfm8hfYeYcfWbQ2DD4VP0qenrUG5SOm0= X-Received: by 10.157.63.225 with SMTP id i30mr4291481ote.51.1518252763960; Sat, 10 Feb 2018 00:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Sat, 10 Feb 2018 00:52:43 -0800 (PST) In-Reply-To: References: From: Abdussalam Baryun Date: Sat, 10 Feb 2018 10:52:43 +0200 Message-ID: To: roll , draft-ietf-roll-aodv-rpl@ietf.org Cc: IETF Chair Content-Type: multipart/alternative; boundary="001a113e4fcaacd95c0564d7c449" Archived-At: Subject: Re: [Roll] Comments for AODV-RPL protocol X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 10 Feb 2018 08:52:47 -0000 --001a113e4fcaacd95c0564d7c449 Content-Type: text/plain; charset="UTF-8" after a month of no reply, this is a second reminder to editor and WG chair, please discuss, AB On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi WG, > > The abstract needs to delete any indication that this is a routing > protocol. IMHO, this is a route discovery for the RPL protocol. > > The discovery of route is part of the routing protocol so we have a > different routing which is AODV-RPL routing protocol. The draft needs to > mention if this AODV-RPL can work with RPL or not in the same network. > > IMO, the draft needs to describe the neighbor discovery combined with > AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 > in rfc6550. Or the draft shows the difference from RFC6650 discovery. > Please refer to sections in RFC6550 RPL. > > AODV-RPL instance are another type of RPL-Instances, so why you write the > AODV instance. Please note that this will conflict with MANET routing > instances. Please delete AODV instance. This draft needs to have only RPL > instances or this AODV-RPL instance defined as RPL instance. > > Delete the writing words 'AODV routing' from the draft, and delete AODV > reference as the IPv4-RFC mentioned (can be confusing). The AODV is already > well known. > > IMO the operation mode is not used correctly, we need to identify the > protocol not by the MoP, we will use them all then, it should be reserved > for network operations not for protocols. > > IMHO, the Message format of dio is not correct needs to have type then the > length format as shown in the dio format specification rfc6550. > > IMO, this protocol Sequence number is not different than the sequence > number of destination mentioned in RFC6550. You must include the DTSN in > this draft. If you thinks I am wrong please mention why here and then it > should be clear what is the different than RPL in the draft? > > Security section needs to include rfc6552/rfc6553 > > I suggest to delete future work section. > > > Best Regards > > AB > --001a113e4fcaacd95c0564d7c449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
after a month of no reply, this is a second reminder = to editor and WG chair,

please discuss,
=
AB

On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun <abd= ussalambaryun@gmail.com> wrote:
Hi WG,

= The abstract needs to delete any indication that this is a= routing protocol. IMHO, this is a route discovery for the RPL protocol.

The discovery of route is part of th= e routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to me= ntion if this AODV-RPL can work with RPL or not in the same network.=

IMO, the draft needs to describe the neighbo= r discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or= =C2=A0the draft shows the difference from RFC6650 discovery. Please refer t= o sections in RFC6550 RPL.=C2=A0

<= /span>AODV-RPL instance are another type of RPL-Ins= tances, so why you write the AODV instance. Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL i= nstances or this AODV-RPL instance defined as RPL instance.

Delete the writing words 'AODV routing&#= 39; from the draft, and=C2=A0delete AODV reference as the IPv4-RFC mentione= d (can be confusing). The AODV is already well known.

IMO the operation mode is not used correctly= , we need to identify the protocol=C2=A0not by the MoP, we will use them all then, it should be reser= ved for network operations not for protocols.

IMHO, the Message format of dio is not correct needs to have type then the length format as s= hown in the dio format specification rfc6550.

IMO, this protocol Sequence number is not different than the sequence number of destination mentioned i= n RFC6550. You must include the DTSN in this draft. If you thinks I am= wrong please mention why here and then it should be clear what is the diff= erent than RPL=C2=A0in the draft?

Security section needs to include rfc6552/rf= c6553

I suggest to delete future work section.


Best Regards

= AB


--001a113e4fcaacd95c0564d7c449-- From nobody Sat Feb 10 01:03:19 2018 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 DF2A5127601; Sat, 10 Feb 2018 01:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 8dz3rcZ3fwpI; Sat, 10 Feb 2018 01:03:13 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F17F124234; Sat, 10 Feb 2018 01:03:13 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id e1so1235604ita.0; Sat, 10 Feb 2018 01:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DIq+TR1Nxs8t+BaJ89L9wsIWFPvT1GGC6TByMLL67y0=; b=JvuRG01MvlVofX0MtQxYPbzx75xbYyUK+vYd016scTT6PPrjmiKDCK2sK7zhJeStgD hMlRqGFHcEn4MHlKjdtmJsjEJqbQbHfEHJD3Z1maoEFDXcArXnIRgR1lbW29NiJVbpou 0s3rMvstn9IcuRhouAgf2uvyOvf952wgbcUwPQo1XA7VOor1i7LPIJ9MCeMcZAK9wY8T yNhVoEBLyoCCSLI/r2NavnNjF33+zwrqAotaZERC319IhXIAo9sivjFezbtBMU/p9+bQ whXVjGT3teNe5ckKjiAp6YyKBbyzwANJ9brHBnQdWwMbQ2YvDA38Z8lcP4+iN4InjwyZ ycFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DIq+TR1Nxs8t+BaJ89L9wsIWFPvT1GGC6TByMLL67y0=; b=AZeTqZDYlVDi5vyRIndhmrTHoihDmMfAnOpKSFawmuuHeLV2BHp8W7j40cqH+g2GML qGeALHmOOr1zipOlAmsT3tJWAUbar/aTpIcXwFdNBfUa+28TswdrWXk1lLT4rJmAE+ih QXSJ+5wTqegUhXqvWGgZTk7a4bS3VbW+0IfP4NY/BULCMn8KBRrLIJ9/vdEmWQxp9rTy sYHrPhOvYxXeEj3G4Nd1d1iMnSdhQ9izAY67QBmpUIAXCEauDaVN3yMvVg+I9xBPQcbp xNEppmKlA2onaew7U6MwzDO0Fcx7AChU3cCZdJniIqylTvgJlJ7F9PD2+hdIW3sYpG1A Lmfw== X-Gm-Message-State: APf1xPCDNv1M1XbMTfuNQ/lfCB/S/ZkPfPOr0CtzoQiFPGcge7eC4NH5 Y6sq/6G2ddWaEhBCGKnSYLamAkzjEAc7QCMOToa/7g== X-Google-Smtp-Source: AH8x22472FPi98oS8K0AwJsfk5LoiTIeCfVE6Fe0zrr9ocQbTEv6hGcGAxj60tFLgbpaeG3myU5B1K9K+7QnZQ9P51s= X-Received: by 10.36.9.73 with SMTP id 70mr6283802itm.133.1518253391944; Sat, 10 Feb 2018 01:03:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.33.84 with HTTP; Sat, 10 Feb 2018 01:03:11 -0800 (PST) In-Reply-To: References: From: Ines Robles Date: Sat, 10 Feb 2018 11:03:11 +0200 Message-ID: To: Routing Over Low power and Lossy networks Cc: draft-ietf-roll-aodv-rpl@ietf.org, IETF Chair , Charlie Perkins Content-Type: multipart/alternative; boundary="001a11373de21b39ee0564d7ea54" Archived-At: Subject: Re: [Roll] Comments for AODV-RPL protocol X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 10 Feb 2018 09:03:17 -0000 --001a11373de21b39ee0564d7ea54 Content-Type: text/plain; charset="UTF-8" Hi AB, Apologizes for late reply. Ticket 184 was created to track those issues: https://trac.ietf.org/trac/roll/ticket/184#ticket Please authors, address these comments. Thanks, Ines and Peter 2018-02-10 10:52 GMT+02:00 Abdussalam Baryun : > after a month of no reply, this is a second reminder to editor and WG > chair, > > please discuss, > > AB > > On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi WG, >> >> The abstract needs to delete any indication that this is a routing >> protocol. IMHO, this is a route discovery for the RPL protocol. >> >> The discovery of route is part of the routing protocol so we have a >> different routing which is AODV-RPL routing protocol. The draft needs to >> mention if this AODV-RPL can work with RPL or not in the same network. >> >> IMO, the draft needs to describe the neighbor discovery combined with >> AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 >> in rfc6550. Or the draft shows the difference from RFC6650 discovery. >> Please refer to sections in RFC6550 RPL. >> >> AODV-RPL instance are another type of RPL-Instances, so why you write the >> AODV instance. Please note that this will conflict with MANET routing >> instances. Please delete AODV instance. This draft needs to have only RPL >> instances or this AODV-RPL instance defined as RPL instance. >> >> Delete the writing words 'AODV routing' from the draft, and delete AODV >> reference as the IPv4-RFC mentioned (can be confusing). The AODV is already >> well known. >> >> IMO the operation mode is not used correctly, we need to identify the >> protocol not by the MoP, we will use them all then, it should be reserved >> for network operations not for protocols. >> >> IMHO, the Message format of dio is not correct needs to have type then >> the length format as shown in the dio format specification rfc6550. >> >> IMO, this protocol Sequence number is not different than the sequence >> number of destination mentioned in RFC6550. You must include the DTSN in >> this draft. If you thinks I am wrong please mention why here and then it >> should be clear what is the different than RPL in the draft? >> >> Security section needs to include rfc6552/rfc6553 >> >> I suggest to delete future work section. >> >> >> Best Regards >> >> AB >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11373de21b39ee0564d7ea54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi AB,

Apologizes for late reply.
=

Ticket 184 was created to track those issues:=C2=A0https://trac.ietf= .org/trac/roll/ticket/184#ticket

Please author= s, address these comments.

Thanks,

<= /div>
Ines and Peter

2018-02-10 10:52 GMT+02:00 Abdussalam Baryun <abdussalambaryun@gmail.com>:
after a month of no reply, this is a second remin= der to editor and WG chair,

please discuss,
<= div>
AB

On Fri, Jan 5, 2018 at 10:04 PM, Abdus= salam Baryun <abdussalambaryun@gmail.com> wrote:
Hi WG,

= The abstract needs to delete any indication that this is a= routing protocol. IMHO, this is a route discovery for the RPL protocol.

The discovery of route is part of th= e routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to me= ntion if this AODV-RPL can work with RPL or not in the same network.=

IMO, the draft needs to describe the neighbo= r discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or= =C2=A0the draft shows the difference from RFC6650 discovery. Please refer t= o sections in RFC6550 RPL.=C2=A0

<= /span>AODV-RPL instance are another type of RPL-Ins= tances, so why you write the AODV instance. Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL i= nstances or this AODV-RPL instance defined as RPL instance.

Delete the writing words 'AODV routing&#= 39; from the draft, and=C2=A0delete AODV reference as the IPv4-RFC mentione= d (can be confusing). The AODV is already well known.

IMO the operation mode is not used correctly= , we need to identify the protocol=C2=A0not by the MoP, we will use them all then, it should be reser= ved for network operations not for protocols.

IMHO, the Message format of dio is not correct needs to have type then the length format as s= hown in the dio format specification rfc6550.

IMO, this protocol Sequence number is not different than the sequence number of destination mentioned i= n RFC6550. You must include the DTSN in this draft. If you thinks I am= wrong please mention why here and then it should be clear what is the diff= erent than RPL=C2=A0in the draft?

Security section needs to include rfc6552/rf= c6553

I suggest to delete future work section.


Best Regards

AB



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


--001a11373de21b39ee0564d7ea54-- From nobody Sat Feb 10 01:21:41 2018 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 722E0128C0A for ; Sat, 10 Feb 2018 01:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fc7zz1IzVXNR for ; Sat, 10 Feb 2018 01:21:37 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62328124D37 for ; Sat, 10 Feb 2018 01:21:37 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 73so9958992oti.12 for ; Sat, 10 Feb 2018 01:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=M9cnpyEGAEHB594N8nHpfAOC8zeHzgKkZDTGJCEDY7g=; b=DnDFjgvPyN10dP1NO+X/2HSltxR0MRXeu1dHZFz2OPpQlbgN8IBEq8G5dzCFy+qJqG 8PYp/pQ/sYiga46PhUYoPfQ6AdYDoEgbYWKwkWQaapoitxo40fi9m5E+Ci53YrVluDN2 9SWeoMKsLuG47t+oQ4fj9TPmtnHFKhvDY8ADGSvKt+aG1uVnKtXHqAabgRFQ+LEzjHfe 4U4HZ8kHxexbNkjHppOFbDQRUO/bHyTOro1DDWPV86CrESPnEa5eDe2RNucAMt6Tb4bM YRy8lgSxFG3wxr/Kza7oOdJL3jHPSpx+w1eqc/a7Wa7daCf7eUtOnLW2VSJwOxEcsAAQ zKJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=M9cnpyEGAEHB594N8nHpfAOC8zeHzgKkZDTGJCEDY7g=; b=odYNqG3glG++ZMMRc21CsE9KzbJQ1yhs/pu57aXHhvnuZF6RugCJOftEidgE0dPTPW VcquW3qW1fSHDruO+ArKVVM0zHTp/3nuA9yJ4V34fPKi8kqDNUhTw4yJWISFnTVSKKJo 60s7F3Q+gkA8HLILp/AVsXs1B48HhySIo/PlvpuMoxgmbgFh4I51I8kBDtdHdVyI4+aA mWKduZ1Kk+nEUoP4u9d6bmomLnkzfrfvo/BgEomiB2Wk9dnks8Aik99c70YyRb4DLBUF LjKGAyxGb1ydVRhBxk1xA/qo3vvzEAzwgE1vV9D8UfbzzJqloircjxXKGedlbK9UUmCR amhw== X-Gm-Message-State: APf1xPCbRwvboP8ZnWOi2LSd59RQUnjOp0O+AHAJ/uggRldUs4QKIeAb 0yH3uGczwyjTkqxeuqR+thMYUisXL2IRA/dXHk0= X-Google-Smtp-Source: AH8x2257JarpVxyETLvYEBvZ51gq49rtWuFiDC5Ekt19NPUS/dVh6PkuKJE5ztGI/obve83z0jm6rDDgMQtLiGr5IVo= X-Received: by 10.157.89.205 with SMTP id u13mr3950814otg.339.1518254496434; Sat, 10 Feb 2018 01:21:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Sat, 10 Feb 2018 01:21:36 -0800 (PST) In-Reply-To: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> From: Abdussalam Baryun Date: Sat, 10 Feb 2018 11:21:36 +0200 Message-ID: To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks , Ines Robles Content-Type: multipart/alternative; boundary="f4030435bf0cf04d5d0564d82bba" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 10 Feb 2018 09:21:39 -0000 --f4030435bf0cf04d5d0564d82bba Content-Type: text/plain; charset="UTF-8" Hi WG, I disagree to discuss new issues before discussing our adopted drafts, especially WGLC ones, I suggest that our editors reply to discussions in our list, related to adopted drafts before the ietf meeting, I hope that this WG managers or Chairs, and the IETF chair follow up to solve this important issue, the issue of no replies from ietf lists. AB On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok wrote: > Hi Roll, > > In a discussion with Rahul and Pascal, it transpires that there are still > many topics to address that fit within our charter. The proliferation of > topics worries us a bit. We have only a limited number of active authors > and some topics also seem to be competing. The result of this situation > might be that we have an overflowing work agenda. Therefore, we need to > find additional people to work on those topics; or reduce the number of > topics. > It is our suggestion that we discuss these topics, find dedicated authors, > and prioritize them after some debate on the M-L. > Also we should like to remove the competitive subjects by joining them > into one draft. > > Your comments please. > > Ines + Peter > > ------------------------ List of topics ------------------------------ > ------------ > > 1 Route invalidation as a standalone topics The topic is mentioned in > several drafts, but we need to come to one general approach. > > 2.A draft that allows a ND only device to connect, be > reachable and move in a RPL network. > > 3. Not all implementers are aware of the design issues of storing mode of > RPL vs non-storing. Both of the modes have issues with their design. Some > issues are getting sorted out by drafts such as dao-projection and no-path > DAO optimization. But still considerable design issues need to be handled. > To name few: > a. handling parent switching optimally in storing MOP. Currently with > Storing MOP it would lead to DIO/DAO storm in the sub-path from the child > node who switches the parent. This is handled well in NS MOP (Non-storing > MOP). > b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is > trivial, but in most cases it is not (considering dependence on several > state variables such as DTSN across reboots)! Also for practical point of > view, need to consider that writing to flash/NV-memory is not a good > option in > embedded devices and should be avoided as far as possible. > c. Problems of current DAO-ACK in storing MOP. There was a discussion on > ML long time back, but there is no draft in the space. > d. problem of bulging IPv6 headers in NS MOP. Most part of this will be > taken care of by SRH compression and dao-projection. > > 4. Confusion between DAG selection (for joining and jumping) vs. parent > selection (for re-parenting within a DODAG). 6TiSCH has isolated the need > for a join preference which is different from the Rank used in parent > selection. The resulting Rank may be used in the join preference, but not > only. The size of the DODAG, the number of children of that parent, etc... > may influence. There is basically the need for a new sort of objective > function, this time in order to select a DODAG to join. > > 5. Integration with 6LoWPAN. We need to write that draft that standardizes > the procedures suggested in the 6TiSCH architecture and shows a non RPL > aware joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP > DAO, we now have all the tools to do it. Unless we consider that the > reference is the 6TiSCH architecture in which case we complete the design > there. > > 6. Exposing (some of) the structure of the Mesh to the root to enable the > DAO projection for transversal routes and in storing mode in general. > > 7. Using bitmaps for multicast and unicast routing, used in > 7a routing tables, or 7b in header for source routing > > 8. Guidance to implementers who are relatively new to > RPL are not aware of many design considerations and there should be a doc > which talks about it. Similar work is started in > https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but > it does not list all the issues imo. > > 9. What to do with expired YANG model drafts > > 10. What else do you think that we should consider? > > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --f4030435bf0cf04d5d0564d82bba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

I disagree to discuss= new issues before discussing our adopted drafts, especially WGLC ones,

I suggest that our editors reply to discussions in ou= r list, related to adopted drafts before the ietf meeting,

I hope that this WG managers or Chairs, and the IETF chair follow = up to solve this important issue, the issue of no replies from ietf lists.<= /div>

AB

On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok <s= tokcons@xs4all.nl> wrote:
Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are still m= any topics to address that fit within our charter. The proliferation of top= ics worries us a bit. We have only a limited number of active authors and s= ome topics also seem to be competing. The result of this situation might be= that we have an overflowing work agenda. Therefore, we need to find additi= onal people to work on those topics; or reduce the number of topics.
It is our suggestion that we discuss these topics, find dedicated authors, = and prioritize them=C2=A0 after some debate on the M-L.
Also we should like to remove the competitive subjects by joining them into= one draft.

Your comments please.

Ines + Peter

------------------------ List of topics ------------------------------= ------------

1 Route invalidation as a standalone topics The topic is mentioned in sever= al drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be
reachable and move in a RPL network.

3. Not all implementers are aware of the design issues of storing mode of RPL vs non-storing. Both of the modes have issues with their design. Some issues are getting sorted out by drafts such as dao-projection and no-path<= br> DAO optimization. But still considerable design issues need to be handled. = To name few:
a. handling parent switching optimally in storing MOP. Currently with
Storing MOP it would lead to DIO/DAO storm in the sub-path from the child node who switches the parent. This is handled well in NS MOP (Non-storing MOP).
b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is trivial, but in most cases it is not (considering dependence on several
state variables such as DTSN across reboots)! Also for practical point of view, need to consider that writing to flash/NV-memory is not a good option= in
embedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a discussion on ML long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will be
taken care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs. parent sel= ection (for re-parenting within a DODAG). 6TiSCH has isolated the need for = a join preference which is different from the Rank used in parent selection= . The resulting Rank may be used in the join preference, but not only. The = size of the DODAG, the number of children of that parent, etc... may influe= nce. There is basically the need for a new sort of objective function, this= time in order to select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that standardizes = the procedures suggested in the 6TiSCH architecture and shows a non RPL awa= re joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP DA= O, we now have all the tools to do it. Unless we consider that the referenc= e is the 6TiSCH architecture in which case we complete the design there.
6. Exposing (some of) the structure of the Mesh to the root to enable the D= AO projection for transversal routes and in storing mode in general.

7. Using bitmaps for multicast and unicast routing, used in
=C2=A07a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to
RPL are not aware of many design considerations and there should be a doc w= hich talks about it. Similar work is started in
https://tools.ietf.org/html/dra= ft-clausen-lln-rpl-experiences-09 ... but
it does not list all the issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?



--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

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

--f4030435bf0cf04d5d0564d82bba-- From nobody Sat Feb 10 03:17:11 2018 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 129E2126C22; Sat, 10 Feb 2018 03:17:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151826142904.23090.3583940399499775454@ietfa.amsl.com> Date: Sat, 10 Feb 2018 03:17:09 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-21.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2018 11:17:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : When to use RFC 6553, 6554 and IPv6-in-IPv6 Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-21.txt Pages : 46 Date : 2018-02-10 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-21 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 10 05:24:21 2018 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 16EB712D948; Sat, 10 Feb 2018 05:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 z7TDPJNFT9js; Sat, 10 Feb 2018 05:24:16 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB99712D94A; Sat, 10 Feb 2018 05:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1518269056; bh=AVRj8L/Duu/agQgzcfve8EdnI2rAmLv8y9j6 Dzyh/cc=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=p+Q0nYmIY2OrrXjetb4cQoBcDuZ3kMEmh y+rdPd7rlJUoXTNMIGNypv4dcAATFN/rJYiZAwHlbOruJrMBNnveNOEGf5eI8GEQ+os XP/xb61Nxd5P7tKPG6bCk2Ay/3SLMMZ/OVaA4mULEFPzPm17rVw9bOnCdt/0O+ItGX9 +QRl0a7cuOh/V6RiKwnrzlHpzMIJnw1pWB9zIYYI+NJKLk204+4/hLA38wTjgVb4CXr j2xgL98rTLBYOxMH3wYbSHiUgb6D4u9JMfzV54k2a3sRI9/dadAL8jebTDH+yI7/4Bj +rHugAcf4JQxrM19o1uZD+j7Kl1RPL1h6gz0sm4RQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=cE6sncK4VjF5s00eUo1NVhaujI5YXlBIEx+raq72W5wLSEmFI09Np+Xns8gIbfQTBB3ZP89uM03r6mRmmPqalk23mOe38mPuK4FCiRDAb101UMllgwSIsJie4yzL4X0l6PYCXgyiAcTPQb4TG9MUIgANlcNt92C6jhUNoITvrH6SRpjLHvHJ+eqEmF6c0HLggkyfPaOte0ZFAmF9VJtAIxNl3kS1CpbLHcBPsD5EH8I/TRtwGAlJnuA5eysaUzmMb/xL9B/EDOmsv4tuo3XOL3trEukXc6AVQYQ6Yo/+bVNxWkRPZ5xaBe72PvUsRXz9hdcpm1DGFpyTd52jQ7um7Q==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1ekV8Y-000ED3-QJ; Sat, 10 Feb 2018 08:24:14 -0500 To: Abdussalam Baryun , roll , draft-ietf-roll-aodv-rpl@ietf.org Cc: IETF Chair References: From: Charlie Perkins Message-ID: Date: Sat, 10 Feb 2018 05:24:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8148B42750109FC4CD4147FE" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c9573b3f8e4f3d7de09a782ad66f23cd8f4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] Comments for AODV-RPL protocol X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 10 Feb 2018 13:24:19 -0000 This is a multi-part message in MIME format. --------------8148B42750109FC4CD4147FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello folks, We have been debating various updates to the protocol.  Some fairly far-reaching modifications have been proposed which we expect to adopt.  But these discussions among the authors were not reflected on the list.  We will respond more fully later in the week -- please excuse the delay. Regards, Charlie P. On 2/10/2018 12:52 AM, Abdussalam Baryun wrote: > after a month of no reply, this is a second reminder to editor and WG > chair, > > please discuss, > > AB > > On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun > > wrote: > > Hi WG, > > The abstract needs to delete any indication that this is a routing > protocol. IMHO, this is a route discovery for the RPL protocol. > > The discovery of route is part of the routing protocol so we have > a different routing which is AODV-RPL routing protocol. The draft > needs to mention if this AODV-RPL can work with RPL or not in the > same network. > > IMO, the draft needs to describe the neighbor discovery combined > with AODV-RPL route discovery. Also needs to refer to sections > 18.4.1 and 18.6 in rfc6550. Or the draft shows the difference from > RFC6650 discovery. Please refer to sections in RFC6550 RPL. > > AODV-RPL instance are another type of RPL-Instances, so why you > write the AODV instance. Please note that this will conflict with > MANET routing instances. Please delete AODV instance. This draft > needs to have only RPL instances or this AODV-RPL instance defined > as RPL instance. > > Delete the writing words 'AODV routing' from the draft, and delete > AODV reference as the IPv4-RFC mentioned (can be confusing). The > AODV is already well known. > > IMO the operation mode is not used correctly, we need to identify > the protocol not by the MoP, we will use them all then, it should > be reserved for network operations not for protocols. > > IMHO, the Message format of dio is not correct needs to have type > then the length format as shown in the dio format specification > rfc6550. > > IMO, this protocol Sequence number is not different than the > sequence number of destination mentioned in RFC6550. You must > include the DTSN in this draft. If you thinks I am wrong please > mention why here and then it should be clear what is the different > than RPL in the draft? > > Security section needs to include rfc6552/rfc6553 > > I suggest to delete future work section. > > > Best Regards > > AB > > --------------8148B42750109FC4CD4147FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello folks,

We have been debating various updates to the protocol.  Some fairly far-reaching modifications have been proposed which we expect to adopt.  But these discussions among the authors were not reflected on the list.  We will respond more fully later in the week -- please excuse the delay.

Regards,
Charlie P.


On 2/10/2018 12:52 AM, Abdussalam Baryun wrote:
after a month of no reply, this is a second reminder to editor and WG chair,

please discuss,

AB

On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi WG,

The abstract needs to delete any indication that this is a routing protocol. IMHO, this is a route discovery for the RPL protocol.

The discovery of route is part of the routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to mention if this AODV-RPL can work with RPL or not in the same network.

IMO, the draft needs to describe the neighbor discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or the draft shows the difference from RFC6650 discovery. Please refer to sections in RFC6550 RPL. 

AODV-RPL instance are another type of RPL-Instances, so why you write the AODV instance. Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL instances or this AODV-RPL instance defined as RPL instance.

Delete the writing words 'AODV routing' from the draft, and delete AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV is already well known.

IMO the operation mode is not used correctly, we need to identify the protocol not by the MoP, we will use them all then, it should be reserved for network operations not for protocols.

IMHO, the Message format of dio is not correct needs to have type then the length format as shown in the dio format specification rfc6550.

IMO, this protocol Sequence number is not different than the sequence number of destination mentioned in RFC6550. You must include the DTSN in this draft. If you thinks I am wrong please mention why here and then it should be clear what is the different than RPL in the draft?

Security section needs to include rfc6552/rfc6553

I suggest to delete future work section.


Best Regards

AB



--------------8148B42750109FC4CD4147FE-- From nobody Sat Feb 10 21:14:34 2018 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 115B51201F8 for ; Sat, 10 Feb 2018 21:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kCh6bYILEROG for ; Sat, 10 Feb 2018 21:14:31 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569A71270B4 for ; Sat, 10 Feb 2018 21:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4476; q=dns/txt; s=iport; t=1518326071; x=1519535671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vTgvc1WXV/WnU/+4w4oW8LgqKzXlDdi66/LCrIJ2D7M=; b=dB8/cGTaUuLZyAC12L9AIo7B+PW+MT2wKds9r7lgMNdNQ630msmzGP6P d0tMkGcGW4YgqCsmyrT8xhajevRYt/Vjq9tXGBMB/C0tMF184lkS4Th/e X3oco9KoJQkrxTKj2yFf/GaLkBiS85CubL71F5jfOXT3JqxEabOA6UV58 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgDoz39a/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbmEabcgoYC4UYAhqCIFgUAQIBAQEBAQECayiFJAI?= =?us-ascii?q?EAQEhETMHCxACAQYCGgImAgICJQsVEAIEDgUbihoQkmuddIInhQGDcIINAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBD4NtghWDPymBd4EOgy8BAYE9DgMjF4MAMYI?= =?us-ascii?q?0BYgEkiKKCAkCkCOFXw6UNpdrAhEZAYE7ATYigVBwFT0qAYIbglUcggZ4ig+BM?= =?us-ascii?q?4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,494,1511827200"; d="scan'208";a="68663122" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2018 05:14:30 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1B5EUN4001382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 11 Feb 2018 05:14:30 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 10 Feb 2018 23:14:29 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Sat, 10 Feb 2018 23:14:29 -0600 From: "Charlie Chen (jianzche)" To: peter van der Stok CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Join preference calculation Thread-Index: AQHTnJ5c/n89yKNnGEiMqY1LhGrk96OV4B8AgAm/uIA= Date: Sun, 11 Feb 2018 05:14:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.140.40.62] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 05:14:33 -0000 SGkgUGV0ZXIsDQoNClNvcnJ5IGZvciBsYXRlIHJlcGx5LiBKb2luIHNlbGVjdGlvbiB0YWtlcyBw bGFjZSBiZWZvcmUgZW5yb2xsbWVudCBvZiB0aGUgbm9kZSBpbiB0aGUgbWVzaC4NCg0KQnV0IGFm dGVyIGpvaW5pbmcsIGlmIGN1cnJlbnQgUEFOIGRvZXMgbm90IHNlcnZlIHdlbGwsIHRoZSBub2Rl IHNob3VsZCBiZSBhYmxlIG1pZ3JhdGUgdG8gb3RoZXIgbWVzaCB1c2luZyB0aGUgc2FtZSBtZXRy aWMgYXMgam9pbiBzZWxlY3Rpb24sDQoNClRodXMsIHRoZSBtZXRyaWMgaXMgaW1wb3J0YW50IGZv ciBib3RoIGJlZm9yZSBlbnJvbGxtZW50IGFuZCBhZnRlci4NCg0KSWYgcG9zc2libGUsIEkgd291 bGQgbG92ZSB0byBjb250cmlidXRlIG9uIHRoaXMgd29yay4NCg0KVGhhbmsgeW91Lg0KDQpCZXN0 IHJlZ2FyZHMsDQpDaGFybGllDQoNCiANCg0K77u/5ZyoIDIwMTgvMi81IOS4i+WNiDQ6MjLvvIzi gJxSb2xsIOS7o+ihqCBwZXRlciB2YW4gZGVyIFN0b2vigJ08cm9sbC1ib3VuY2VzQGlldGYub3Jn IOS7o+ihqCBzdG9rY29uc0B4czRhbGwubmw+IOWGmeWFpToNCg0KICAgIEhpIENoYXJsaWUsDQog ICAgDQogICAgaXMgaXMgYW4gaW50ZXJlc3Rpbmcgc3ViamVjdCB0aGF0IG5lZWRzIG1vcmUgcmVm bGVjdGlvbi4NCiAgICBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hlbiB0aGUgam9pbiBzZWxlY3Rp b24gdGFrZXMgcGxhY2U7IElzIHRoaXMgDQogICAgYmVmb3JlIG9yIGFmdGVyIGVucm9sbG1lbnQg b2YgdGhlIG5vZGUgaW4gdGhlIG1lc2g/DQogICAgRGVwZW5kZW50IG9uIHRoYXQgY2hvaWNlLCBk aWZmZXJlbnQgdGVjaG5pcXVlcyBhcmUgY2FsbGVkIGZvciwgaW4gbXkgDQogICAgdmlldy4NCiAg ICANCiAgICBJIGxpa2UgdG8gZHJhdyB5b3VyIGF0dGVudGlvbiB0byB0aGUgUk9MTCBtZWV0aW5n IGluIExvbmRvbiB0aGF0IHdpbGwgDQogICAgZGlzY3VzcyB0aGUgY29vcmRpbmF0aW9uIG9mIHRo ZSBkaWZmZXJlbnQgcGFyZW50IHNlbGVjdGlvbiBhbmQgcmFua2luZyANCiAgICBhbGdvcml0aG1z IHRoYXQgYXJlIGN1cnJlbnRseSBwcm9wb3NlZC4NCiAgICANCiAgICBJdCB3b3VsZCBiZSBnb29k IGlmIHdlIGNvdWxkIGdpdmUgeW91ciBzdWJqZWN0IGEgcGxhY2UgaW4gdGhlIGN1cnJlbnRseSAN CiAgICBvbmdvaW5nIGFuZCBwcm9wb3NlZCBST0xMIHdvcmsuDQogICAgDQogICAgQ2hlZXJpbywN CiAgICANCiAgICBQZXRlcg0KICAgIA0KICAgIENoYXJsaWUgQ2hlbiAoamlhbnpjaGUpIHNjaHJl ZWYgb3AgMjAxOC0wMi0wMyAwNDoyMzoNCiAgICA+IEhpIE1pY2hhZWwsDQogICAgPiANCiAgICA+ IEkgYW0gQ2hhcmxpZSBmcm9tIENpc2NvLiBPdXIgZ3JvdXAgaXMgZG9pbmcgbWVzaCBwcm9kdWN0 cyBmb3IgZ3JpZC4NCiAgICA+IFBBTiBtaWdyYXRpb24gaXMgb25lIG9mIHRoZSBtb3N0IGltcG9y dGFudCBmZWF0dXJlcyBpbiBvdXIgbWVzaA0KICAgID4gc29sdXRpb24sIHdoaWNoIHdlIHdvdWxk IGxpa2UgdG8ga2VlcCByZWZpbmluZy4NCiAgICA+IA0KICAgID4gV2UgYXJlIGludGVyZXN0ZWQg aW4geW91ciBwcm9wb3NhbCBhYm91dCBqb2luIHByZWZlcmVuY2UgYW5kIHdhbnQgdG8NCiAgICA+ IGZvbGxvdyBpdCB1cCBpbiBvdXIgZnV0dXJlIHNvbHV0aW9uLg0KICAgID4gDQogICAgPiBXZSB0 aGluayB0aGVyZSBhcmUgdHdvIGZhY3RvcnMgdGhhdCBtYXkgbmVlZCB0byBiZSBjb25zaWRlcmVk IGluIHRoZQ0KICAgID4gY2FsY3VsYXRpb24gZm9yIGpvaW4gcHJlZmVyZW5jZS4NCiAgICA+IA0K ICAgID4gRmlyc3QsIERBRyBzZWxlY3Rpb24gYWZmZWN0cyAoc29tZXRpbWVzIGRlY2lkZXMpIHBh cmVudCBzZWxlY3Rpb24uIFdlDQogICAgPiBmb3VuZCB0aGF0IHNvbWUgbm9kZXMgbWF5IHNlbGVj dCBhIERBRyB3aXRoIGxlc3Mgbm9kZXMgYnV0IGFsc28gYQ0KICAgID4gcGFyZW50IHdpdGggdG9v IG1hbnkgY2hpbGRyZW4uIEl0IHRha2VzIGEgY2VydGFpbiBvZiB0aW1lIGZvciB0aGUgbm9kZQ0K ICAgID4gdG8gcmVzZWxlY3QgYSBiZXR0ZXIgcGFyZW50Lg0KICAgID4gDQogICAgPiBUaHVzLCBp ZiBqb2luIHByZWZlcmVuY2UgZ2l2ZXMgc29tZSBpbmRpY2F0aW9uIGxpa2UgcmFuayBhbmQgY2hp bGRyZW4NCiAgICA+IG51bWJlciwgYSBub2RlIHdvdWxkIG1ha2UgYSByaWdodCBkZWNpc2lvbiBh dCB0aGUgYmVnaW5uaW5nLg0KICAgID4gDQogICAgPiBTZWNvbmQsIGNhcGFjaXR5IGxpbWl0IGlz IGFub3RoZXIgc2VtYW50aWNzIHRoYXQgam9pbiBwcmVmZXJlbmNlIG1heQ0KICAgID4gbmVlZCB0 byBjYXJyeSwgY29uc2lkZXJpbmcgYWdncmVnYXRlZCBiYW5kd2lkdGggYW5kIG1lbW9yeSBzaXpl IG9uIHRoZQ0KICAgID4gcm9vdCBub2RlLiBFc3BlY2lhbGx5LCB3aGVuIHJvb3Qgbm9kZXMgd2l0 aCBkaWZmZXJlbnQgY2FwYWNpdHkgYXJlDQogICAgPiBkZXBsb3llZCwgbWVzaCBub2RlcyBoYXZl IG5vIGNsdWUgdG8NCiAgICA+IA0KICAgID4gZGVjaWRlIHdoZXRoZXIgdG8gam9pbiBhIERBRyB3 aXRoIDYwLW5vZGVzIGNhcGFjaXR5IGFuZCA1MCBub2Rlcw0KICAgID4gam9pbmVkIG9yIGEgREFH IHdpdGggMTAwMC1ub2RlcyBjYXBhY2l0eSBhbmQgYWxzbyA1MCBub2RlcyBqb2luZWQuIElmDQog ICAgPiB0aGUgbGltaXQgb2Ygc3VwcG9ydGVkIG5vZGVzIG9yIGN1cnJlbnQgdXRpbGl6YXRpb24g aXMgY2FycmllZCwgYSBtZXNoDQogICAgPiBub2RlIGNhbiBjb21wYXJlIHR3byBEQUdzIGluIGEg cmVhc29uYWJsZSB3YXkuDQogICAgPiANCiAgICA+IEFib3ZlIGFyZSBvdXIgcHJlbWF0dXJlIHRo b3VnaHRzLiBXZSBhcmUgbG9vayBmb3J3YXJkIHRvIHRoZSBuYXJyb3dpbmcNCiAgICA+IGRvd24g b2Ygam9pbiBwcmVmZXJlbmNlIGNhbGN1bGF0aW9uLg0KICAgID4gDQogICAgPiBUaGFuayB5b3Uu DQogICAgPiANCiAgICA+IEJlc3QgcmVnYXJkcywNCiAgICA+IA0KICAgID4gQ2hhcmxpZQ0KICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ IFJvbGwgbWFpbGluZyBsaXN0DQogICAgPiBSb2xsQGlldGYub3JnDQogICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFJvbGwgbWFpbGluZyBsaXN0 DQogICAgUm9sbEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KICAgIA0KDQo= From nobody Sun Feb 11 20:02:27 2018 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 907E3120721 for ; Sun, 11 Feb 2018 20:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ybaR6tV5jqNC for ; Sun, 11 Feb 2018 20:02:22 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9511205F0 for ; Sun, 11 Feb 2018 20:02:22 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id v71so7351632wmv.2 for ; Sun, 11 Feb 2018 20:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QpRB+k3oau759pagU+W4OCnOFXiPZKVJcw9zURYmuNA=; b=O8szyo6eNQcJMq/Z6BO8MLgrxeKYsEoIoE0ZrVGTtoq+2+Nf0oF8hbRbp7R14Qds51 J/QB3NCaavnI/CeeX1W7L+5z2dHbefRByvkknqlWA0ZMq7dWVXRXL6jtNAXl6bMmhM65 BHDJC8DM0OZUTIj2beZbS5S4PaSYHcO483XEA67poKdjSDcsi+RvaShmqXgs9eoX4Fqu 0voPbBZC3KyzUnlPoLcKHlukgx1IA8MIqG32AECWPazMczKdjshsXTlv1I3mBa54pYJB s1kNyzbdmzheKHAE5fiiJj2a6XuouuZSjtztl7W/VnhPg2lbTUpdz2o/xxfrvDLfIL/1 OhPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QpRB+k3oau759pagU+W4OCnOFXiPZKVJcw9zURYmuNA=; b=Zl5wvI4glA52+7kX7JEYQa8LvTLaMav7ZuqnNYPdsmwvypDUDRVNwcX4hzLKcJveji o/sQ1mAXlRPdzdi7oTdmKpzaAjOwVLj+77XAFbsm0GXhLXwm65+nFqJXlFMjb9IlZo8X Phnym5yXTqzYojwB9ic+PhuwDjr29HAC4OREs0Ut3edGBd1850DI7SEdNSnQxIGPdrXp blivayCSgl0YIrCxQQG9d2oSnNCBVquhJ0YMmo8zPxCKlv4TpunMVOxrHPYhZuX51GB4 I/qBtb+waQO1ckXwF8fiE3WbR1Bjj1ltZk1wrBQqzBFZUuwB4/lIuYYlciW9KuJ/Zxve p6Jw== X-Gm-Message-State: APf1xPAdLwdYujJqSCLpqwSNHen+jzK7VlZdvNp4EBLJ8S/lfE+ZOTeB ViS+SfYXlwDVqdQjy/E0kt6QMGwQ7U6iGpqfH3ZUeg== X-Google-Smtp-Source: AH8x226/iRj6mW7iFsCK8xhuMOPpTo5WZIfgae7dQ9WzzMQR17V7xdgWEY/lL2k91SfWmvgjFhOe6UQLGwtrhzPwfEs= X-Received: by 10.80.212.2 with SMTP id t2mr14196568edh.54.1518408140495; Sun, 11 Feb 2018 20:02:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.241.91 with HTTP; Sun, 11 Feb 2018 20:02:19 -0800 (PST) In-Reply-To: <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> From: Rahul Jadhav Date: Mon, 12 Feb 2018 09:32:19 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f40304388e10d69db10564fbf1ae" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 04:02:25 -0000 --f40304388e10d69db10564fbf1ae Content-Type: text/plain; charset="UTF-8" Hello ROLL, Last week we had uploaded an ID " https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-observations/" inline to what was promised in IETF100. (Strange the new ID notification was not sent out to ROLL ML (?),, but the ID is actually uploaded!). The draft is informational and describes issues related to existing handling in RPL which either seems incomplete, ambiguous and may need attention. It is possible that some of the issues already have some existing solution which we would like to understand. Please note that all the issues mentioned in the draft are related to existing 6550 handling. Also many of those issues are pertaining to storing MOP and we wanted to put out our understanding out there so as to get any feedback from other implementers. Thanks, Rahul On 8 February 2018 at 19:10, Pascal Thubert (pthubert) wrote: > Hello Peter: > > I encourage the WG to consider your list carefully and respond. > > My personal priorities would be: > > 1) Item 4. This deals with actual field problems, and is a preerq for the > Join Process that 6TiSCH is working on. Michael has a draft and I'm willing > to contribute together with Charlie from Cisco. > 2) item 2+5, seem to be the same to me. This is a rather easy work once > rfc6775-update is passed and I'm willing to start/contribute > > Take care, > > Pascal > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok > Sent: lundi 9 octobre 2017 09:47 > To: Roll > Subject: [Roll] Topics and drafts within Roll charter > > Hi Roll, > > In a discussion with Rahul and Pascal, it transpires that there are still > many topics to address that fit within our charter. The proliferation of > topics worries us a bit. We have only a limited number of active authors > and some topics also seem to be competing. The result of this situation > might be that we have an overflowing work agenda. > Therefore, we need to find additional people to work on those topics; or > reduce the number of topics. > It is our suggestion that we discuss these topics, find dedicated authors, > and prioritize them after some debate on the M-L. > Also we should like to remove the competitive subjects by joining them > into one draft. > > Your comments please. > > Ines + Peter > > ------------------------ List of topics > ------------------------------------------ > > 1 Route invalidation as a standalone topics The topic is mentioned in > several drafts, but we need to come to one general approach. > > 2.A draft that allows a ND only device to connect, be reachable and move > in a RPL network. > > 3. Not all implementers are aware of the design issues of storing mode of > RPL vs non-storing. Both of the modes have issues with their design. > Some > issues are getting sorted out by drafts such as dao-projection and no-path > DAO optimization. But still considerable design issues need to be handled. > To name few: > a. handling parent switching optimally in storing MOP. Currently with > Storing MOP it would lead to DIO/DAO storm in the sub-path from the child > node who switches the parent. This is handled well in NS MOP (Non-storing > MOP). > b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is > trivial, but in most cases it is not (considering dependence on several > state variables such as DTSN across reboots)! Also for practical point of > view, need to consider that writing to flash/NV-memory is not a good option > in embedded devices and should be avoided as far as possible. > c. Problems of current DAO-ACK in storing MOP. There was a discussion on > ML long time back, but there is no draft in the space. > d. problem of bulging IPv6 headers in NS MOP. Most part of this will be > taken care of by SRH compression and dao-projection. > > 4. Confusion between DAG selection (for joining and jumping) vs. parent > selection (for re-parenting within a DODAG). 6TiSCH has isolated the need > for a join preference which is different from the Rank used in parent > selection. The resulting Rank may be used in the join preference, but not > only. The size of the DODAG, the number of children of that parent, etc... > may influence. There is basically the need for a new sort of objective > function, this time in order to select a DODAG to join. > > 5. Integration with 6LoWPAN. We need to write that draft that standardizes > the procedures suggested in the 6TiSCH architecture and shows a non RPL > aware joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP > DAO, we now have all the tools to do it. Unless we consider that the > reference is the 6TiSCH architecture in which case we complete the design > there. > > 6. Exposing (some of) the structure of the Mesh to the root to enable the > DAO projection for transversal routes and in storing mode in general. > > 7. Using bitmaps for multicast and unicast routing, used in > 7a routing tables, or 7b in header for source routing > > 8. Guidance to implementers who are relatively new to RPL are not aware of > many design considerations and there should be a doc which talks about it. > Similar work is started in > https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but > it does not list all the issues imo. > > 9. What to do with expired YANG model drafts > > 10. What else do you think that we should consider? > > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --f40304388e10d69db10564fbf1ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello ROLL,=C2=A0

Last week we had uplo= aded an ID "https://datatracker.ietf.org/doc/draft-rahul-roll-rpl= -observations/" inline to what was promised in IETF100. (Strange t= he new ID notification was not sent out to ROLL ML (?),, but the ID is actu= ally uploaded!).
The draft is informational and describes issues = related to existing handling in RPL which either seems incomplete, ambiguou= s and may need attention. It is possible that some of the issues already ha= ve some existing solution which we would like to understand.
Plea= se note that all the issues mentioned in the draft are related to existing = 6550 handling. Also many of those issues are pertaining to storing MOP and = we wanted to put out our understanding out there so as to get any feedback = from other implementers.

Thanks,
Rahul= =C2=A0

On 8 February 2018 at 19:10, Pascal Thubert (pthubert) &= lt;pthubert@cisco.c= om> wrote:
Hello Peter:

I encourage the WG to consider your list carefully and respond.

My personal priorities would be:

1) Item 4. This deals with actual field problems, and is a preerq for the J= oin Process that 6TiSCH is working on. Michael has a draft and I'm will= ing to contribute together with Charlie from Cisco.
2) item 2+5, seem to be the same to me. This is a rather easy work once rfc= 6775-update is passed and I'm willing to start/contribute

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:roll-bounces@ie= tf.org] On Behalf Of peter van der Stok
Sent: lundi 9 octobre 2017 09:47
To: Roll <roll@ietf.org>
Subject: [Roll] Topics and drafts within Roll charter

Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are still m= any topics to address that fit within our charter. The proliferation of top= ics worries us a bit. We have only a limited number of active authors and s= ome topics also seem to be competing. The result of this situation might be= that we have an overflowing work agenda.
Therefore, we need to find additional people to work on those topics; or re= duce the number of topics.
It is our suggestion that we discuss these topics, find dedicated authors, = and prioritize them=C2=A0 after some debate on the M-L.
Also we should like to remove the competitive subjects by joining them into= one draft.

Your comments please.

Ines + Peter

------------------------ List of topics
------------------------------------------

1 Route invalidation as a standalone topics The topic is mentioned in sever= al drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be reachable and move in= a RPL network.

3. Not all implementers are aware of the design issues of storing mode of R= PL vs non-storing. Both of the modes have issues with their design.
Some
issues are getting sorted out by drafts such as dao-projection and no-path = DAO optimization. But still considerable design issues need to be handled. = To name few:
a. handling parent switching optimally in storing MOP. Currently with Stori= ng MOP it would lead to DIO/DAO storm in the sub-path from the child node w= ho switches the parent. This is handled well in NS MOP (Non-storing MOP). b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is t= rivial, but in most cases it is not (considering dependence on several stat= e variables such as DTSN across reboots)! Also for practical point of view,= need to consider that writing to flash/NV-memory is not a good option in e= mbedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a discussion on ML= long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will be tak= en care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs. parent sel= ection (for re-parenting within a DODAG). 6TiSCH has isolated the need for = a join preference which is different from the Rank used in parent selection= . The resulting Rank may be used in the join preference, but not only. The = size of the DODAG, the number of children of that parent, etc... may influe= nce. There is basically the need for a new sort of objective function, this= time in order to select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that standardizes = the procedures suggested in the 6TiSCH architecture and shows a non RPL awa= re joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP DA= O, we now have all the tools to do it. Unless we consider that the referenc= e is the 6TiSCH architecture in which case we complete the design there.
6. Exposing (some of) the structure of the Mesh to the root to enable the D= AO projection for transversal routes and in storing mode in general.

7. Using bitmaps for multicast and unicast routing, used in
=C2=A0 7a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to RPL are not aware of = many design considerations and there should be a doc which talks about it. = Similar work is started in
https://tools.ietf.org/html/dra= ft-clausen-lln-rpl-experiences-09 ... but it does not list all the= issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?



--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vandersto= k.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

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

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

--f40304388e10d69db10564fbf1ae-- From nobody Mon Feb 12 00:04:46 2018 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 9F6FD120725 for ; Mon, 12 Feb 2018 00:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT75x45iO-KG for ; Mon, 12 Feb 2018 00:04:42 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38291201F8 for ; Mon, 12 Feb 2018 00:04:41 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud9.xs4all.net with ESMTPA id l96MeDdgsoWCOl96MeFPaD; Mon, 12 Feb 2018 09:04:39 +0100 Received: from AMontpellier-654-1-182-16.w92-145.abo.wanadoo.fr ([92.145.161.16]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Feb 2018 09:04:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Feb 2018 09:04:38 +0100 From: peter van der Stok To: Abdussalam Baryun Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks , Ines Robles Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> Message-ID: <2758859717c33d2cb4521529940109b0@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJSVdnhaK7JAsQ9hkLCL6VHwuJzSPlHkmYWWherrvlrgczH7UO49c3/Ck1nKLRm7AwmP2rkCCUjGALlU/NWVTtnDjy6NQB257DZ/0056/BI3c9dhhIRq LglXkdAs/rTXRQgxuX6jZ19vlzKSeeJmTlgXNV5d2eHUAoM5/PuZxhc3UyrlpSAXGaQ3sxw7zgODTp94NZPwjIRnz5pMNUg+KZ3F4wOidWDwi+HEqbGDdEPa NQsyeEJxLY5R+Bkvsawf8wBEasVC+47b5Ouyywuai2ysXQ+4vPQpL3hNuMF8uYaVQz7yV5aryxZfFlJa2WhhbouDjCJ/Py1TbrVBHYOXx5RNY99Ou+inZI/c mS16vNA/ Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 08:04:46 -0000 Hi Abdul, Indeed, not all authors reply as quickly to reviews as one should wish. There are several reasons for this, such as extra work load by employer, disappearing interest, etc.. As a WG we should be aware that our work is a composition of contributions by individual authors. This being so, dependent on importance of topic, time spent by the authors, responsiveness by WG, and others, drafts will proceed in their own tempo (or leisure). It is a bad idea to stop all WG progress on all topics, because some drafts have a very slow progress. Drafts with little activity will finally disappear, while the WG as such needs to make progress. There are two concerns that I have at the moment and that I want to discuss during ietf101: - Making sure that all (current and future) drafts which discuss parent selection, ranking, or dodag selection, clarify the chosen metric and that the different metrics can co-exist or exclude each other during RPL operation. - Making sure that there are enough authors and reviewers to advance this subject I hope this clarifies the wish for a discussion during ietf101. Peter Abdussalam Baryun schreef op 2018-02-10 10:21: > Hi WG, > > I disagree to discuss new issues before discussing our adopted drafts, > especially WGLC ones, > > I suggest that our editors reply to discussions in our list, related > to adopted drafts before the ietf meeting, > > I hope that this WG managers or Chairs, and the IETF chair follow up > to solve this important issue, the issue of no replies from ietf > lists. > > AB > > On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok > wrote: > >> Hi Roll, >> >> In a discussion with Rahul and Pascal, it transpires that there are >> still many topics to address that fit within our charter. The >> proliferation of topics worries us a bit. We have only a limited >> number of active authors and some topics also seem to be competing. >> The result of this situation might be that we have an overflowing >> work agenda. Therefore, we need to find additional people to work on >> those topics; or reduce the number of topics. >> It is our suggestion that we discuss these topics, find dedicated >> authors, and prioritize them after some debate on the M-L. >> Also we should like to remove the competitive subjects by joining >> them into one draft. >> >> Your comments please. >> >> Ines + Peter >> >> ------------------------ List of topics >> ------------------------------------------ >> >> 1 Route invalidation as a standalone topics The topic is mentioned >> in several drafts, but we need to come to one general approach. >> >> 2.A draft that allows a ND only device to connect, be >> reachable and move in a RPL network. >> >> 3. Not all implementers are aware of the design issues of storing >> mode of >> RPL vs non-storing. Both of the modes have issues with their design. >> Some >> issues are getting sorted out by drafts such as dao-projection and >> no-path >> DAO optimization. But still considerable design issues need to be >> handled. To name few: >> a. handling parent switching optimally in storing MOP. Currently >> with >> Storing MOP it would lead to DIO/DAO storm in the sub-path from the >> child >> node who switches the parent. This is handled well in NS MOP >> (Non-storing >> MOP). >> b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases >> it is >> trivial, but in most cases it is not (considering dependence on >> several >> state variables such as DTSN across reboots)! Also for practical >> point of >> view, need to consider that writing to flash/NV-memory is not a good >> option in >> embedded devices and should be avoided as far as possible. >> c. Problems of current DAO-ACK in storing MOP. There was a >> discussion on >> ML long time back, but there is no draft in the space. >> d. problem of bulging IPv6 headers in NS MOP. Most part of this will >> be >> taken care of by SRH compression and dao-projection. >> >> 4. Confusion between DAG selection (for joining and jumping) vs. >> parent selection (for re-parenting within a DODAG). 6TiSCH has >> isolated the need for a join preference which is different from the >> Rank used in parent selection. The resulting Rank may be used in the >> join preference, but not only. The size of the DODAG, the number of >> children of that parent, etc... may influence. There is basically >> the need for a new sort of objective function, this time in order to >> select a DODAG to join. >> >> 5. Integration with 6LoWPAN. We need to write that draft that >> standardizes the procedures suggested in the 6TiSCH architecture and >> shows a non RPL aware joining a DODAG and moving inside. With the >> new 6LoWPAN ND and the NP DAO, we now have all the tools to do it. >> Unless we consider that the reference is the 6TiSCH architecture in >> which case we complete the design there. >> >> 6. Exposing (some of) the structure of the Mesh to the root to >> enable the DAO projection for transversal routes and in storing mode >> in general. >> >> 7. Using bitmaps for multicast and unicast routing, used in >> 7a routing tables, or 7b in header for source routing >> >> 8. Guidance to implementers who are relatively new to >> RPL are not aware of many design considerations and there should be >> a doc which talks about it. Similar work is started in >> https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 [1] >> ... but >> it does not list all the issues imo. >> >> 9. What to do with expired YANG model drafts >> >> 10. What else do you think that we should consider? >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org [2] >> tel NL: +31(0)492474673 [3] F: +33(0)966015248 [4] >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll [5] > > > > Links: > ------ > [1] https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 > [2] http://www.vanderstok.org > [3] tel:%2B31%280%29492474673 > [4] tel:%2B33%280%29966015248 > [5] https://www.ietf.org/mailman/listinfo/roll From nobody Mon Feb 12 00:07:31 2018 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 E8ACC120725 for ; Mon, 12 Feb 2018 00:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N59neYwyHoYB for ; Mon, 12 Feb 2018 00:07:28 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5621201F8 for ; Mon, 12 Feb 2018 00:07:27 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud9.xs4all.net with ESMTPA id l994eDf96oWCOl994eFQOQ; Mon, 12 Feb 2018 09:07:26 +0100 Received: from AMontpellier-654-1-182-16.w92-145.abo.wanadoo.fr ([92.145.161.16]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Feb 2018 09:07:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Feb 2018 09:07:26 +0100 From: peter van der Stok To: Rahul Jadhav Cc: Routing Over Low power and Lossy networks , consultancy@vanderstok.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> Message-ID: <6c139fde44d861a75ee084a9d75a0e1a@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfHQMLBJWWuOX8Bv6qbOssjrc25daYrxI/iLVctcQLr4xkCCTDqNNFpxTNnYii9/XFzbUXDCd6V9JVUTNoWuovPMCiD9vvvSLbWB6opQEgxqNLyqsdPFo arTyji7fgPbc33hU9dGVlDgabHlhJadomyi9/WYaLJtOfNg6bybaRyQHia3JKfrt6h0yvmddTqoCk55LSCZg9jo8xMJ5rV2lNY31nFeiH/R8Ios4OXSXDKn/ 4/wVFh5tIez0EFYKiLZJAGUofsurf0A8rNPCq87KlYCo4fJhemO24AfQ7mo1m9c90DS6xLx1hoH/FWf4E72F1g== Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 08:07:30 -0000 Hi Rahul, > Last week we had uploaded an ID > "https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-observations/" > inline to what was promised in IETF100. (Strange the new ID > notification was not sent out to ROLL ML (?),, but the ID is actually > uploaded!). Not strange, For individual drafts, you may send out the notification to the whole WG. For WG drafts(ietf- in title) notification is distributed automatically to the WG. Peter From nobody Mon Feb 12 00:23:07 2018 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 AFAFE120725 for ; Mon, 12 Feb 2018 00:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FKProaMIKvR7 for ; Mon, 12 Feb 2018 00:23:05 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF161201F8 for ; Mon, 12 Feb 2018 00:23:05 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id b21so8184405wme.4 for ; Mon, 12 Feb 2018 00:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NBlBwBEDYxcb4zmKJgPBoY2EiqsTjUUUNJp2ORfBflQ=; b=Cy+gHWKxnFgzRinhdS3qAeXDKZ9dJ3Ve7Y1cyA4SVXzn3LS0bfjd2af71BoxRdCPFS MJQTNaNKEBWuDg19MBxKnFEmQ8PlSQ4SvnmxGGjgvcCatYq68eDSu+pfKvAmsm643KrH VrNADRFId6AX6wm2xQMKK0qcb6EwaZ42KympdelEVfojQDhvV+Tf3DrUEomgccTtLtFB KK95QZQc/YonNRv/4YweylWTmWnanckQkz9KYpNCNhlkVShSlOmtBmFUCMPUdvK/wU28 BhnAv7RVLLQ+BpB+oOOO7+O00hguVv/LgSJjJl1xWZ15Se538JgDF29N6buhk2hmBs7i IsSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NBlBwBEDYxcb4zmKJgPBoY2EiqsTjUUUNJp2ORfBflQ=; b=V72g+FO1R/XRfHnu3dexYDHgwgT/BaXJwk5vQc5gRTHwamn7JmuuR1qam9+mUA52Hi L7XU2MK/obxK0NKH/XEcEk/SLK+4kIDx0Qj47MG1UAMNa8N4YPqKEen+4j4k8AY1zs+V na5BaEiTOlARiqz5DRAQ/KZVnRtxFnWA1rCbHpDl56R1V63c1AfvkO8xWMgNyvhxi9SG oMraqt6cNWMg/NkYo2Im31XTyEV95Q1DkhIsyYgtxHTvxOB3qI34muWrb8WavEbnUgzr H2ve+R4tJaGVOgTo4cq4QzWL/SYWcfeqA3ks3cz5sIoYxn46TOTeZNFYZliW+OErf9cX N/CQ== X-Gm-Message-State: APf1xPA0zB2xQxPnVmRzG7hZwVjX7+hNDJJtIfU7k5iI8umxr9ys5L4M uWj0dt/q6bY+nijELIiHeoma7yUIVS10DPnoj3Q= X-Google-Smtp-Source: AH8x227dFJmbbm4WMZIo0W2c3vK1tEeq1P0Dt/0ScdE2BCAgaMu/FARFogwYzKve4MSNA1Lv9MgthZfQ/A8Xt7MB1Pc= X-Received: by 10.80.134.44 with SMTP id o41mr14877226edo.243.1518423783462; Mon, 12 Feb 2018 00:23:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.205.77 with HTTP; Mon, 12 Feb 2018 00:23:02 -0800 (PST) In-Reply-To: <6c139fde44d861a75ee084a9d75a0e1a@xs4all.nl> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> <6c139fde44d861a75ee084a9d75a0e1a@xs4all.nl> From: Rahul Jadhav Date: Mon, 12 Feb 2018 13:53:02 +0530 Message-ID: To: "consultancy@vanderstok.org" Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403045c2c123b5a9e0564ff96f5" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 08:23:06 -0000 --f403045c2c123b5a9e0564ff96f5 Content-Type: text/plain; charset="UTF-8" > > > Not strange, > For individual drafts, you may send out the notification to the whole WG. > For WG drafts(ietf- in title) notification is distributed automatically to > the WG. ohk! Thanks for clarifying. --f403045c2c123b5a9e0564ff96f5 Content-Type: text/html; charset="UTF-8"

Not strange,
For individual drafts, you may send out the notification to the whole WG.
For WG drafts(ietf- in title) notification is distributed automatically to the WG.

ohk! Thanks for clarifying.
--f403045c2c123b5a9e0564ff96f5-- From nobody Tue Feb 13 00:14:29 2018 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B439512E891; Tue, 13 Feb 2018 00:14:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Van der Stok To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: roll-chairs@ietf.org, iesg-secretary@ietf.org, roll@ietf.org, Peter Van der Stok , consultancy@vanderstok.org Message-ID: <151850966773.22238.10883359557021875347.idtracker@ietfa.amsl.com> Date: Tue, 13 Feb 2018 00:14:27 -0800 Archived-At: Subject: [Roll] Publication has been requested for draft-ietf-roll-useofrplinfo-21 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 08:14:27 -0000 Peter Van der Stok has requested publication of draft-ietf-roll-useofrplinfo-21 as Proposed Standard on behalf of the ROLL working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ From nobody Tue Feb 13 05:49:37 2018 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 6925F12EA42 for ; Tue, 13 Feb 2018 05:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2AsvnjcEQGZ0 for ; Tue, 13 Feb 2018 05:49:33 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AC912E8B0 for ; Tue, 13 Feb 2018 05:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2184; q=dns/txt; s=iport; t=1518529773; x=1519739373; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cyo7aIL1gytc46y6kKxPbHWaIVZth7TG2S2+Ck4fvbQ=; b=U2VAW5tOJN4GV6E7YXUYgHMjst1UPI3nej/Htio5jUqz9JT2sl6Czocr n2/Z4o5KWfjD79ca1CdSEuxcVCDi+IGV5mn/goGU3Nus23iDyScHG/9v3 BsRZZcZyZDscW0RTYJwUDap2bi+11SU85+yg/Id5nWCBli4ONDtT18BSP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAADA64Ja/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbiiSOJYICgReWQRWCAwolhRYCGoJKVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBBCMRQw4EAgEIEQQBAQMCIwMCAgIwFAEGAQEFAwIEEwiKLRCwN?= =?us-ascii?q?YIniH6CEQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4NyghWBV4Fogy6DLwEBAgE?= =?us-ascii?q?BgTWDT4JlBZJNh1mKCAkCiB6NW4IoZ4VDi3uLFIJuiWkCERkBgTsBHzmBUHAVG?= =?us-ascii?q?SSCRgmEbngBinKBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,507,1511827200"; d="scan'208";a="70200365" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 13:49:32 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1DDnW7t032025 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Feb 2018 13:49:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 07:49:31 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 13 Feb 2018 07:49:32 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt Thread-Index: AQHTpNDHT/qnjvCFfEOUEt1W2yRKEKOiWHAw Date: Tue, 13 Feb 2018 13:49:15 +0000 Deferred-Delivery: Tue, 13 Feb 2018 13:48:55 +0000 Message-ID: <4a15b40b98974761965b7d040bebd86b@XCH-RCD-001.cisco.com> References: <151852947104.13012.17003340794935098934.idtracker@ietfa.amsl.com> In-Reply-To: <151852947104.13012.17003340794935098934.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 13:49:35 -0000 RGVhciBhbGw6DQoNClRoaXMgaXMgYWJvdXQgb25lIG9mIHRoZSBpdGVtcyBpbiB0aGUgQ2hhaXJz JyB0b2RvIGxpc3QsIHN1cHBvcnRpbmcgbm9uLVJQTCBhd2FyZSBsZWF2ZXMuDQoNClRoaXMgc3Vw cG9ydCBpcyBtYWRlIHBvc3NpYmxlIGJ5IHRoZSB1cGRhdGUgdG8gUkZDIDY3NzUgdGhhdCBpcyBu b3cgdW5kZXIgSVNFRyByZXZpZXcuDQoNCkNvbW1lbnRzIHdlbGNvbWUhDQoNClBhc2NhbA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogbWFyZGkgMTMgZsOp dnJpZXIgMjAxOCAxNDo0NQ0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0 QGNpc2NvLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt dGh1YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDAudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1s ZWF2ZXMNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlSUEwtQklFUg0KRG9jdW1lbnQgZGF0ZToJMjAx OC0wMi0xMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTANClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1 YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZl cy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1 YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2 ZXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFJGQyA2 NTUwIGFuZCBSRkMgNjc3NSB1bmljYXN0IHJvdXRpbmcNCiAgIHNlcnZpY2UgaW4gYSBSUEwgZG9t YWluIHRvIDZMb1dQQU4gTkQgbm9kZXMgdGhhdCBkbyBub3QgcGFydGljaXBhdGUNCiAgIHRvIHRo ZSByb3V0aW5nIHByb3RvY29sLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Feb 13 11:14:05 2018 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 5EE76127735 for ; Tue, 13 Feb 2018 11:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jRVyMLuS2BA for ; Tue, 13 Feb 2018 11:14:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A41A126BF7 for ; Tue, 13 Feb 2018 11:14:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 782E520090 for ; Tue, 13 Feb 2018 14:20:56 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6240980BB3 for ; Tue, 13 Feb 2018 14:14:01 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <4a15b40b98974761965b7d040bebd86b@XCH-RCD-001.cisco.com> References: <151852947104.13012.17003340794935098934.idtracker@ietfa.amsl.com> <4a15b40b98974761965b7d040bebd86b@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 19:14:04 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > This is about one of the items in the Chairs' todo list, supporting > non-RPL aware leaves. > This support is made possible by the update to RFC 6775 that is now > under ISEG review. Also useofrollinfo makes explicit mention of them... thanks for your document... I will read it at length later. I noticed the title was "RPL-BIER", but I couldn't find further reference to BIER, so I'm thinking it's a copy-paste error from another document. I think that useofrplinfo should be referenced... > https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/ > Htmlized: > https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-thubert-roll-unaware-leaves-00 > Abstract: This specification updates RFC 6550 and RFC 6775 unicast > routing service in a RPL domain to 6LoWPAN ND nodes that do not > participate to the routing protocol. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqDOPkACgkQgItw+93Q 3WWYmgf9HLolOYlqvjx8xmd7XQAyvXgXlmyqodWc/f4FYcNvBLzOr+AqZ2YKxuYl Z4WqNeqn2DjL+Ki8cfk/g4kOOzuXLf6BhyKiqWhDmWwVob+M/Vi940EmG9O8NTOS Xj/NsICulKCWsjnZo8iEkebXJWFL8ABitbamx3BRyS+2bbH2ZYaF7L+kiuHBhihE TZb8pNzxZ1f5r48CD3GkdNj5UnTSenENfbLDtouQ+kQra3Bew3Br70xDyzFMTp3/ P3l2P1CQggGyguT8pPSJD2u9EFYYNJJo0ztjvbE5zDl3Ok080Mv+5NH+xYjgPcvk IDB+ZE4eWE0vVzikF7lHQekP/il4Mw== =budE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 13 11:19:19 2018 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 1BD1412D88D for ; Tue, 13 Feb 2018 11:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 iKTC0KiucIiC for ; Tue, 13 Feb 2018 11:19:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AD5127735 for ; Tue, 13 Feb 2018 11:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1992; q=dns/txt; s=iport; t=1518549556; x=1519759156; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CB6k6IMQpWJObURyin6g806ua0aE20FbR27+PjXTHVI=; b=TDjSIlQNu1SvxeM+LtAcxZybv3zFBHVpyqeP2UmbxMuk+iity+/UhM0x J3PTizKZhQg1/tFEUb0JzLoF1Xnu5YxuPj+Osh5iihYAcx5PmQUUjHhiM xW8g3m0fU/G8451cd1knnjAnydThQc2/NFffM7+cnOag/rwjRCUtV8M++ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQB1OYNa/4sNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNSZnAog2WKJI4mggKBF5ZBghgKGA2BXIM6AhqCTlQYAQI?= =?us-ascii?q?BAQEBAQECayiFIwEBAQMBAQEhEToJBwsCAQgYAgImAgICJQsVEAIEE4otCBC?= =?us-ascii?q?wIYInhQGDe4IRAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4NyghWBV4FoKYM?= =?us-ascii?q?Fgy8BAQIBAYUEMYI0BaQuCQKIHo1kgh+KQ4diixSCbolpAhEZAYE7AR85gVB?= =?us-ascii?q?wFRkkKgGCG4MKgW14jjwBAQE?= X-IronPort-AV: E=Sophos;i="5.46,508,1511827200"; d="scan'208";a="348615770" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 19:19:15 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w1DJJFep022908 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Feb 2018 19:19:15 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 13:19:14 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 13 Feb 2018 13:19:14 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt Thread-Index: AQHTpNDHT/qnjvCFfEOUEt1W2yRKEKOiWHAwgADAH4D//5zhKg== Date: Tue, 13 Feb 2018 19:19:14 +0000 Message-ID: <4FABFC6C-608A-43AB-9B47-2CA0664E52E1@cisco.com> References: <151852947104.13012.17003340794935098934.idtracker@ietfa.amsl.com> <4a15b40b98974761965b7d040bebd86b@XCH-RCD-001.cisco.com>, <17139.1518549241@obiwan.sandelman.ca> In-Reply-To: <17139.1518549241@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 19:19:18 -0000 VGhhbmtzIE1pY2hhZWwgSeKAmWxsIGZpeCB0aGlzIGluIDAxIHNvb24hDQoNCg0KUmVnYXJkcywN Cg0KUGFzY2FsDQoNCj4gTGUgMTMgZsOpdnIuIDIwMTggw6AgMjA6MTQsIE1pY2hhZWwgUmljaGFy ZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiBhIMOpY3JpdCA6DQo+IA0KPiANCj4gUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4+IFRoaXMg aXMgYWJvdXQgb25lIG9mIHRoZSBpdGVtcyBpbiB0aGUgQ2hhaXJzJyB0b2RvIGxpc3QsIHN1cHBv cnRpbmcNCj4+IG5vbi1SUEwgYXdhcmUgbGVhdmVzLg0KPiANCj4+IFRoaXMgc3VwcG9ydCBpcyBt YWRlIHBvc3NpYmxlIGJ5IHRoZSB1cGRhdGUgdG8gUkZDIDY3NzUgdGhhdCBpcyBub3cNCj4+IHVu ZGVyIElTRUcgcmV2aWV3Lg0KPiANCj4gQWxzbyB1c2VvZnJvbGxpbmZvIG1ha2VzIGV4cGxpY2l0 IG1lbnRpb24gb2YgdGhlbS4uLg0KPiB0aGFua3MgZm9yIHlvdXIgZG9jdW1lbnQuLi4gSSB3aWxs IHJlYWQgaXQgYXQgbGVuZ3RoIGxhdGVyLg0KPiANCj4gSSBub3RpY2VkIHRoZSB0aXRsZSB3YXMg IlJQTC1CSUVSIiwgYnV0IEkgY291bGRuJ3QgZmluZCBmdXJ0aGVyIHJlZmVyZW5jZSB0bw0KPiBC SUVSLCBzbyBJJ20gdGhpbmtpbmcgaXQncyBhIGNvcHktcGFzdGUgZXJyb3IgZnJvbSBhbm90aGVy IGRvY3VtZW50Lg0KPiANCj4gSSB0aGluayB0aGF0IHVzZW9mcnBsaW5mbyBzaG91bGQgYmUgcmVm ZXJlbmNlZC4uLg0KPiANCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy8NCj4+IEh0bWxpemVkOg0KPj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMA0K Pj4gSHRtbGl6ZWQ6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMA0KPiANCj4gDQo+PiBBYnN0cmFjdDog VGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgUkZDIDY1NTAgYW5kIFJGQyA2Nzc1IHVuaWNhc3QN Cj4+IHJvdXRpbmcgc2VydmljZSBpbiBhIFJQTCBkb21haW4gdG8gNkxvV1BBTiBORCBub2RlcyB0 aGF0IGRvIG5vdA0KPj4gcGFydGljaXBhdGUgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQo+IA0K PiANCj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBT YW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiAN Cj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Tue Feb 13 20:37:24 2018 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 1D64C1242F7 for ; Tue, 13 Feb 2018 20:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Yc_Njzn2QOMF for ; Tue, 13 Feb 2018 20:37:20 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7321200E5 for ; Tue, 13 Feb 2018 20:37:19 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id q12so19309969otg.10 for ; Tue, 13 Feb 2018 20:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=30vJckg3ar8cNjk/C8qOwuZjc1Jls4Qb2g4pfOgU2ug=; b=GFMP+peB24Py+GHAfvmIUSbYAO3ro4UfEK/XUA/3G3Vkd4MFq0CjL0TQkb/v3JtuTO kmTsWFRVzxxzZua9PRuTx1cocKc+CJtd59baXLWNXnrORgEnPLAg20boAukb+oEGQ3/W 967S74EPmdW8Z8mIiABkr0QvpAafufvP+0XA8VE98W7+9LOab4JgPxmU/C+4HP4pZCga W8jIctYCWvXt7vSjNIlWIplOIsk1bm7jFwzYUqCElMTwyOZH7Gmslm09jtVl7Ica3x7N 6KUknPRSFdkdi0cw59VvfaYV2aka4+nqxJwafHOmck57j7dnh88y51PA2YeRafZDvSJ6 +wXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=30vJckg3ar8cNjk/C8qOwuZjc1Jls4Qb2g4pfOgU2ug=; b=kNK8gamMNqgtBkFcJ5APU4+9PaEuWihupM/ryCeSX+JrczRD5/N/xahnJIykjvRiFS x9ApOB10B5fjZHNkSvWPV737MwnXcmUnCa1iJaJARuca3iVMe+Jhtc0I2UmuwuWehMdf byZSh+U+I7g8er9nBw/KnYm0slHf48VmRACUa6IpumRpuMIFfYboOfqi/e+DxZvOV0ES SPCwLDWxcpJEhvyj7jcysK3F8uCtqseUFBcCj4+WW0zyc+eHDw8tLfBvNeN4NBQVdFTH KGA1rjmgaGygSSpdhzoAdP0jJOgKunLY+SLwRs/4JsPAIIDXEnzFIlpzvYOOQCTsWtyM lEQQ== X-Gm-Message-State: APf1xPB8uzeH3foB3rUDvcEohpye4JV/ZEwP0rBr9ukk57QoPDBsfpvu +nuTB0Z14hZ4e02P8A6tEWHWA0klye8MbasYuuA= X-Google-Smtp-Source: AH8x22773PoE9c6UbefZtsmBBR+9G/yOQPKoXM6R08Y/902VAJMVMssH0lslqBfXaUmnN4M3PA90Gao6jy9L6Z+0pX4= X-Received: by 10.157.88.45 with SMTP id r45mr2385770oth.111.1518583039061; Tue, 13 Feb 2018 20:37:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 20:37:18 -0800 (PST) In-Reply-To: References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 06:37:18 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403043553249af434056524aac1" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 04:37:23 -0000 --f403043553249af434056524aac1 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 12, 2018 at 6:02 AM, Rahul Jadhav wrote: > Hello ROLL, > > Last week we had uploaded an ID "https://datatracker.ietf.org/ > doc/draft-rahul-roll-rpl-observations/" inline to what was promised in > IETF100. (Strange the new ID notification was not sent out to ROLL ML (?),, > but the ID is actually uploaded!). > Yes I think it is strange that it was not sent to this important list I suggest that this needs to be solved by IESG or the AD responsible or the WG chairs, so this does not happen again in future, The draft is informational > The draft is not informational please check it again, > and describes issues related to existing handling in RPL which either > seems incomplete, ambiguous and may need attention. It is possible that > some of the issues already have some existing solution which we would like > to understand. > Please note that all the issues mentioned in the draft are related to > existing 6550 handling. Also many of those issues are pertaining to storing > MOP and we wanted to put out our understanding out there so as to get any > feedback from other implementers. > I am still waiting fo feedback related to an adapted draft and which is in LC, related to issues, > > Thanks, > Rahul > > On 8 February 2018 at 19:10, Pascal Thubert (pthubert) > wrote: > >> Hello Peter: >> >> I encourage the WG to consider your list carefully and respond. >> >> My personal priorities would be: >> >> 1) Item 4. This deals with actual field problems, and is a preerq for the >> Join Process that 6TiSCH is working on. Michael has a draft and I'm willing >> to contribute together with Charlie from Cisco. >> 2) item 2+5, seem to be the same to me. This is a rather easy work once >> rfc6775-update is passed and I'm willing to start/contribute >> >> Take care, >> >> Pascal >> >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok >> Sent: lundi 9 octobre 2017 09:47 >> To: Roll >> Subject: [Roll] Topics and drafts within Roll charter >> >> Hi Roll, >> >> In a discussion with Rahul and Pascal, it transpires that there are still >> many topics to address that fit within our charter. The proliferation of >> topics worries us a bit. We have only a limited number of active authors >> and some topics also seem to be competing. The result of this situation >> might be that we have an overflowing work agenda. >> Therefore, we need to find additional people to work on those topics; or >> reduce the number of topics. >> It is our suggestion that we discuss these topics, find dedicated >> authors, and prioritize them after some debate on the M-L. >> Also we should like to remove the competitive subjects by joining them >> into one draft. >> >> Your comments please. >> >> Ines + Peter >> >> ------------------------ List of topics >> ------------------------------------------ >> >> 1 Route invalidation as a standalone topics The topic is mentioned in >> several drafts, but we need to come to one general approach. >> >> 2.A draft that allows a ND only device to connect, be reachable and move >> in a RPL network. >> >> 3. Not all implementers are aware of the design issues of storing mode of >> RPL vs non-storing. Both of the modes have issues with their design. >> Some >> issues are getting sorted out by drafts such as dao-projection and >> no-path DAO optimization. But still considerable design issues need to be >> handled. To name few: >> a. handling parent switching optimally in storing MOP. Currently with >> Storing MOP it would lead to DIO/DAO storm in the sub-path from the child >> node who switches the parent. This is handled well in NS MOP (Non-storing >> MOP). >> b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is >> trivial, but in most cases it is not (considering dependence on several >> state variables such as DTSN across reboots)! Also for practical point of >> view, need to consider that writing to flash/NV-memory is not a good option >> in embedded devices and should be avoided as far as possible. >> c. Problems of current DAO-ACK in storing MOP. There was a discussion on >> ML long time back, but there is no draft in the space. >> d. problem of bulging IPv6 headers in NS MOP. Most part of this will be >> taken care of by SRH compression and dao-projection. >> >> 4. Confusion between DAG selection (for joining and jumping) vs. parent >> selection (for re-parenting within a DODAG). 6TiSCH has isolated the need >> for a join preference which is different from the Rank used in parent >> selection. The resulting Rank may be used in the join preference, but not >> only. The size of the DODAG, the number of children of that parent, etc... >> may influence. There is basically the need for a new sort of objective >> function, this time in order to select a DODAG to join. >> >> 5. Integration with 6LoWPAN. We need to write that draft that >> standardizes the procedures suggested in the 6TiSCH architecture and shows >> a non RPL aware joining a DODAG and moving inside. With the new 6LoWPAN ND >> and the NP DAO, we now have all the tools to do it. Unless we consider that >> the reference is the 6TiSCH architecture in which case we complete the >> design there. >> >> 6. Exposing (some of) the structure of the Mesh to the root to enable the >> DAO projection for transversal routes and in storing mode in general. >> >> 7. Using bitmaps for multicast and unicast routing, used in >> 7a routing tables, or 7b in header for source routing >> >> 8. Guidance to implementers who are relatively new to RPL are not aware >> of many design considerations and there should be a doc which talks about >> it. Similar work is started in >> https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but >> it does not list all the issues imo. >> >> 9. What to do with expired YANG model drafts >> >> 10. What else do you think that we should consider? >> >> >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 <+31%20492%20474%20673> F: +33(0)966015248 >> <+33%209%2066%2001%2052%2048> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --f403043553249af434056524aac1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 12, 2018 at 6:02 AM, Rahul Jadhav <rahul.ietf@gmail.com= > wrote:
Hello ROLL,=C2= =A0

Last week we had uploaded an ID "https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-ob= servations/" inline to what was promised in IETF100. (Strange the = new ID notification was not sent out to ROLL ML (?),, but the ID is actuall= y uploaded!).

Yes I think it is= strange that it was not sent to this important list=C2=A0

I suggest that this needs to be solved by IESG or the AD responsib= le or the WG chairs, so this does not happen again in future,
The draft is informational

The draft is not informational p= lease check it again,
=C2=A0
and describes issues related to existing handling in RPL which eith= er seems incomplete, ambiguous and may need attention. It is possible that = some of the issues already have some existing solution which we would like = to understand.
Please note that all the issues mentioned in the d= raft are related to existing 6550 handling. Also many of those issues are p= ertaining to storing MOP and we wanted to put out our understanding out the= re so as to get any feedback from other implementers.

I am still waiting fo feedback related to an adapted= draft and which is in LC,=C2=A0related to issues,

=C2=A0

Thanks,<= /div>
Rahul=C2=A0

On 8 February 2018 = at 19:10, Pascal Thubert (pthubert) <pthubert@cisco.com> wr= ote:
Hello Peter:

I encourage the WG to consider your list carefully and respond.

My personal priorities would be:

1) Item 4. This deals with actual field problems, and is a preerq for the J= oin Process that 6TiSCH is working on. Michael has a draft and I'm will= ing to contribute together with Charlie from Cisco.
2) item 2+5, seem to be the same to me. This is a rather easy work once rfc= 6775-update is passed and I'm willing to start/contribute

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: lundi 9 octobre 2017 09:47
To: Roll <roll@ietf.o= rg>
Subject: [Roll] Topics and drafts within Roll charter

Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are still m= any topics to address that fit within our charter. The proliferation of top= ics worries us a bit. We have only a limited number of active authors and s= ome topics also seem to be competing. The result of this situation might be= that we have an overflowing work agenda.
Therefore, we need to find additional people to work on those topics; or re= duce the number of topics.
It is our suggestion that we discuss these topics, find dedicated authors, = and prioritize them=C2=A0 after some debate on the M-L.
Also we should like to remove the competitive subjects by joining them into= one draft.

Your comments please.

Ines + Peter

------------------------ List of topics
------------------------------------------

1 Route invalidation as a standalone topics The topic is mentioned in sever= al drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be reachable and move in= a RPL network.

3. Not all implementers are aware of the design issues of storing mode of R= PL vs non-storing. Both of the modes have issues with their design.
Some
issues are getting sorted out by drafts such as dao-projection and no-path = DAO optimization. But still considerable design issues need to be handled. = To name few:
a. handling parent switching optimally in storing MOP. Currently with Stori= ng MOP it would lead to DIO/DAO storm in the sub-path from the child node w= ho switches the parent. This is handled well in NS MOP (Non-storing MOP). b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it is t= rivial, but in most cases it is not (considering dependence on several stat= e variables such as DTSN across reboots)! Also for practical point of view,= need to consider that writing to flash/NV-memory is not a good option in e= mbedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a discussion on ML= long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will be tak= en care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs. parent sel= ection (for re-parenting within a DODAG). 6TiSCH has isolated the need for = a join preference which is different from the Rank used in parent selection= . The resulting Rank may be used in the join preference, but not only. The = size of the DODAG, the number of children of that parent, etc... may influe= nce. There is basically the need for a new sort of objective function, this= time in order to select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that standardizes = the procedures suggested in the 6TiSCH architecture and shows a non RPL awa= re joining a DODAG and moving inside. With the new 6LoWPAN ND and the NP DA= O, we now have all the tools to do it. Unless we consider that the referenc= e is the 6TiSCH architecture in which case we complete the design there.
6. Exposing (some of) the structure of the Mesh to the root to enable the D= AO projection for transversal routes and in storing mode in general.

7. Using bitmaps for multicast and unicast routing, used in
=C2=A0 7a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to RPL are not aware of = many design considerations and there should be a doc which talks about it. = Similar work is started in
https://tools.ietf.org/html/dra= ft-clausen-lln-rpl-experiences-09 ... but it does not list all the= issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?



--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)96601= 5248

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

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


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


--f403043553249af434056524aac1-- From nobody Tue Feb 13 20:48:38 2018 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 3762612D7FB for ; Tue, 13 Feb 2018 20:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nTg4csWo8CFH for ; Tue, 13 Feb 2018 20:48:35 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900681200E5 for ; Tue, 13 Feb 2018 20:48:35 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id k87so2295132wmi.0 for ; Tue, 13 Feb 2018 20:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vu76sHEI5RKxLI9TB15UaJPg9U+TGGs5+b5XNCAibaQ=; b=pJJ4gEgVDa7netrbQcyYTSInDTQVM/AMHKfHJ4d3X/qwMwXpNBybtVkNr9RL3NtuwN HmNWULW9b0ICL6gPJv/+idUQEQB9rTRNsSns+AWsFmlAGL+b2+RmIF5clZsS4HBZTkTZ x1fnfJv3BD/7blIbhdq9AzCnGfhf1qJQGGhr+k6p/n33gsRQaUSpcsBcW4g5egePhvn7 BisEBZKVMhFRmBr3UL566IJcMCaXoAMv/OiBKRyFigXVoPsvIYaYrIGkdVphirInpdvx M6RTd+GSwMHT6ubOQMBwu5BYUkCUvXhWpsk8AKll4H5RKr/U2e8/A1/UyRDXrW1hLgb8 3QxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vu76sHEI5RKxLI9TB15UaJPg9U+TGGs5+b5XNCAibaQ=; b=s9puje6SM1Ou9LVMeBDH3c8dci4FKsmpzueNAimv+2F6fkpCBk0+Sx8mFfjP4R28+t koTXeVe9+vRuMBlkvW+QC+xUAmp6rbp3h7zgefaalbAbdwIMa8hj2jQ9m1nDa2RBzenw D6Vjwy+H5yAdg5sEG555KtUV998sb+VSUKHZYEleVi939dpOsw/kbuaU4RjfUP7Mfagy +r3a7v19QI6kBddD8w/a3LYbDZSlXTAJK0Lb1yNM06lGo4VOt/9CbCsYize1Mr/vxWoy Lquz/pyUmxSmUiD53qKWzigtPsr86T097FEUcHWaKmUP/pSI+wB5U2KvTwShD9VGCAjP l3Sg== X-Gm-Message-State: APf1xPAp56dq7kaXjUBfuHKXLDa5NbEUDubJb5qzhxOX0kduHtFMGkd0 tA2h2+R4XQeSroHi7YSwcB7QAV/sBe4aDVNafvs= X-Google-Smtp-Source: AH8x225v04D+ic41T8MMlyo7iyp4XckiJmqScId6cvSe58yZLC41beA9XdrX6hbMIAhaWlB+aXA6mdnJAuy0k5ICkl4= X-Received: by 10.80.174.221 with SMTP id f29mr5041358edd.54.1518583713954; Tue, 13 Feb 2018 20:48:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.205.77 with HTTP; Tue, 13 Feb 2018 20:48:33 -0800 (PST) In-Reply-To: References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <0b55d6459bfc4e44a23a606e34eb0086@XCH-RCD-001.cisco.com> From: Rahul Jadhav Date: Wed, 14 Feb 2018 10:18:33 +0530 Message-ID: To: Abdussalam Baryun Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403045c2792d5008e056524d25d" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 04:48:37 -0000 --f403045c2792d5008e056524d25d Content-Type: text/plain; charset="UTF-8" > The draft is informational >> > > The draft is not informational please check it again, > Oh Yes, I ll fix this in 01 ver. Thanks --f403045c2792d5008e056524d25d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



The draft is informational

The draft is not informational please check it again,

Oh Yes, I ll fix this in 01 ver. = Thanks=C2=A0


--f403045c2792d5008e056524d25d-- From nobody Tue Feb 13 20:59:39 2018 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 0D05512DA0C for ; Tue, 13 Feb 2018 20:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gVlyJwP-Ql4A for ; Tue, 13 Feb 2018 20:59:32 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29331242F7 for ; Tue, 13 Feb 2018 20:59:32 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id w38so1294380ota.8 for ; Tue, 13 Feb 2018 20:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bs3GWxHM9fjtosR9cMJImXqlN0wnMaxunmXJJPe7roc=; b=rpQ0wEA+jLbrGDqqZ9U/Zy1nJgDWZPejqj4CqzNK+9hED9RY1D/jzEc6CgqSEyv60a 3DYOw00N9LeLXdG/+TYudtAVrvwmNHgB/fBM/lIFG+JvVR70dHYYNJd2nYICQmuhloNd M8VJoINML8BbKw/xOTEqlnVvNQ/wdpX+r8A0M9174RYvm597tZk8nXQPCnxpA3DGFQY5 HQmdqifUKSvOTS7Ie7KXUOD0EBOwTdZWbYFk9xpVkkAAwkAxzrk2JLI2iuJNnUab5PCH 1IJapgqyRo9hIVlDWiB52oVQmLXWqHB0jb4vIpbPbgsbAxZ6o+He1R7kJjFDZJE/+VMY mnCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bs3GWxHM9fjtosR9cMJImXqlN0wnMaxunmXJJPe7roc=; b=OBfMV0mHETtMy+bs7WfKuLwzIw6+OryZEqq+KojhSPwZVmcOZoptLc2ZnmFKyx3Pwr 1AxuBGK/OFQuqKm5agIHhl6M9bcx80SKKnvOUaAl8SuodCQyjL2WC3GGeCW46F07Qwwh 3HALTCAXaQZeSOGYzbJUDNcgoKB7mOUUuRFkPKt55IPneBjAOeFiAivuRe2nT9dOQLGE 5bqDLCI97CZPYWuMVTExg3aE7woQ42ot0Rna80SEe6IJSl4DINEDbC3g2LSQvbOs+L1t w9pw/cXnL7E46n4Olna9ZNHbIl6nihNzfpZ6SL9+nxA+avgfzUtSelZsdNy9jqTbSzHr ejHg== X-Gm-Message-State: APf1xPBVpHL2k4NazwNCK3q8k+XRo2CHzwNgEdhmd4dIB+tqFI5DqPdr 60N/bm0e/IAn8d5shpldZl+DPKm1lOakeveC3PU= X-Google-Smtp-Source: AH8x226O595L7y4IFRzdvBpetRSpQiMPKG4SLVud0graWtzO6LhgakTVgl7Y6DZDZE1UCYACKsX8jd0rgnvFhx9IkaY= X-Received: by 10.157.24.28 with SMTP id b28mr2612130ote.356.1518584371948; Tue, 13 Feb 2018 20:59:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 20:59:31 -0800 (PST) In-Reply-To: <2758859717c33d2cb4521529940109b0@xs4all.nl> References: <76c7ca90006983de7a781bc8abad534c@xs4all.nl> <2758859717c33d2cb4521529940109b0@xs4all.nl> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 06:59:31 +0200 Message-ID: To: consultancy@vanderstok.org Cc: Routing Over Low power and Lossy networks , Ines Robles Content-Type: multipart/alternative; boundary="001a113dc9840d2e6c056524faf5" Archived-At: Subject: Re: [Roll] Topics and drafts within Roll charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 04:59:36 -0000 --001a113dc9840d2e6c056524faf5 Content-Type: text/plain; charset="UTF-8" Hi Peter and Ines, I thank you for your respond, and I think that WG chair guidance/discussions are always important for any WG list, not only for IETF lists. My comments below, On Mon, Feb 12, 2018 at 10:04 AM, peter van der Stok wrote: > Hi Abdul, > > Indeed, not all authors reply as quickly to reviews as one should wish. > I know that, but not a month, I think a month is a very very long time, what do you think? However, I think that the WG chair/AD should follow up with items that are related to WG LC drafts. > There are several reasons for this, such as extra work load by employer, > disappearing interest, etc.. > As a WG we should be aware that our work is a composition of contributions > by individual authors. > I don't think that is a good excuse for IETF business, because we have managers in IETF, amanager should follow up and push the work or find who can help. No one asked me to help or no author asked the WG participants that they need help. If authors don't ask for help, they MUST not hold our draft or the draft we adopted. The IESG MUST solve this issue, and SHOULD find a better way to make WG lists respond to serious people/participats. > > This being so, dependent on importance of topic, time spent by the > authors, responsiveness by WG, and others, drafts will proceed in their own > tempo (or leisure). > > It is a bad idea to stop all WG progress on all topics, because some > drafts have a very slow progress. > I never like to stop any thing, but we need to agree/discuss on priorities, any IETF WG should discuss all issues, but some WGs discuss off lines or in the face to face meeting. While I don't do meeting, I am concerned by WG list or our ROLL list. > Drafts with little activity will finally disappear, while the WG as such > needs to make progress. > I know, but the WG chair should comment on the list for such issue when appears. Please note that in this comment I am not against any, but just discussing for best practice, > > There are two concerns that I have at the moment and that I want to > discuss during ietf101: > - Making sure that all (current and future) drafts which discuss parent > selection, ranking, or dodag selection, clarify the chosen metric and that > the different metrics can co-exist or exclude each other during RPL > operation. > - Making sure that there are enough authors and reviewers to advance this > subject > > I hope this clarifies the wish for a discussion during ietf101. > Yes, hope you/authors contact me if there is any draft needs co-authoring/assistant, while some authors are bussy as you mentioned. So we need to make things faster/acurate by sharing load. AB Africa Region (above using SHOLD or MUST is not shouting, just like to use more clear wording) Peter > > Abdussalam Baryun schreef op 2018-02-10 10:21: > >> Hi WG, >> >> I disagree to discuss new issues before discussing our adopted drafts, >> especially WGLC ones, >> >> I suggest that our editors reply to discussions in our list, related >> to adopted drafts before the ietf meeting, >> >> I hope that this WG managers or Chairs, and the IETF chair follow up >> to solve this important issue, the issue of no replies from ietf >> lists. >> >> AB >> >> On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok >> wrote: >> >> Hi Roll, >>> >>> In a discussion with Rahul and Pascal, it transpires that there are >>> still many topics to address that fit within our charter. The >>> proliferation of topics worries us a bit. We have only a limited >>> number of active authors and some topics also seem to be competing. >>> The result of this situation might be that we have an overflowing >>> work agenda. Therefore, we need to find additional people to work on >>> those topics; or reduce the number of topics. >>> It is our suggestion that we discuss these topics, find dedicated >>> authors, and prioritize them after some debate on the M-L. >>> Also we should like to remove the competitive subjects by joining >>> them into one draft. >>> >>> Your comments please. >>> >>> Ines + Peter >>> >>> ------------------------ List of topics >>> ------------------------------------------ >>> >>> 1 Route invalidation as a standalone topics The topic is mentioned >>> in several drafts, but we need to come to one general approach. >>> >>> 2.A draft that allows a ND only device to connect, be >>> reachable and move in a RPL network. >>> >>> 3. Not all implementers are aware of the design issues of storing >>> mode of >>> RPL vs non-storing. Both of the modes have issues with their design. >>> Some >>> issues are getting sorted out by drafts such as dao-projection and >>> no-path >>> DAO optimization. But still considerable design issues need to be >>> handled. To name few: >>> a. handling parent switching optimally in storing MOP. Currently >>> with >>> Storing MOP it would lead to DIO/DAO storm in the sub-path from the >>> child >>> node who switches the parent. This is handled well in NS MOP >>> (Non-storing >>> MOP). >>> b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases >>> it is >>> trivial, but in most cases it is not (considering dependence on >>> several >>> state variables such as DTSN across reboots)! Also for practical >>> point of >>> view, need to consider that writing to flash/NV-memory is not a good >>> option in >>> embedded devices and should be avoided as far as possible. >>> c. Problems of current DAO-ACK in storing MOP. There was a >>> discussion on >>> ML long time back, but there is no draft in the space. >>> d. problem of bulging IPv6 headers in NS MOP. Most part of this will >>> be >>> taken care of by SRH compression and dao-projection. >>> >>> 4. Confusion between DAG selection (for joining and jumping) vs. >>> parent selection (for re-parenting within a DODAG). 6TiSCH has >>> isolated the need for a join preference which is different from the >>> Rank used in parent selection. The resulting Rank may be used in the >>> join preference, but not only. The size of the DODAG, the number of >>> children of that parent, etc... may influence. There is basically >>> the need for a new sort of objective function, this time in order to >>> select a DODAG to join. >>> >>> 5. Integration with 6LoWPAN. We need to write that draft that >>> standardizes the procedures suggested in the 6TiSCH architecture and >>> shows a non RPL aware joining a DODAG and moving inside. With the >>> new 6LoWPAN ND and the NP DAO, we now have all the tools to do it. >>> Unless we consider that the reference is the 6TiSCH architecture in >>> which case we complete the design there. >>> >>> 6. Exposing (some of) the structure of the Mesh to the root to >>> enable the DAO projection for transversal routes and in storing mode >>> in general. >>> >>> 7. Using bitmaps for multicast and unicast routing, used in >>> 7a routing tables, or 7b in header for source routing >>> >>> 8. Guidance to implementers who are relatively new to >>> RPL are not aware of many design considerations and there should be >>> a doc which talks about it. Similar work is started in >>> https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 [1] >>> ... but >>> it does not list all the issues imo. >>> >>> 9. What to do with expired YANG model drafts >>> >>> 10. What else do you think that we should consider? >>> >>> -- >>> Peter van der Stok >>> vanderstok consultancy >>> mailto: consultancy@vanderstok.org >>> www: www.vanderstok.org [2] >>> tel NL: +31(0)492474673 [3] F: +33(0)966015248 [4] >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll [5] >>> >> >> >> >> Links: >> ------ >> [1] https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 >> [2] http://www.vanderstok.org >> [3] tel:%2B31%280%29492474673 >> [4] tel:%2B33%280%29966015248 >> [5] https://www.ietf.org/mailman/listinfo/roll >> > --001a113dc9840d2e6c056524faf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Peter and Ines,

I thank you fo= r your respond, and I think that WG chair guidance/discussions=C2=A0are alw= ays important for any WG list, not only for IETF lists. My comments below,<= /div>


On Mon, Feb 12, 2018 at 10:04 AM, peter van = der Stok <stokcons@xs4all.nl> wrote:
= Hi Abdul,

Indeed, not all authors reply as quickly to reviews as one should wish.
=

I know that, but not a month, I think a mo= nth is a very very long time, what do you think? However, I think that the = WG chair/AD should follow up with items that are related to WG LC drafts.
=C2=A0
There are several reasons for this, such as extra work load by employer, di= sappearing interest, etc..
As a WG we should be aware that our work is a composition of contributions = by individual authors.

I don't thin= k that is a good excuse for IETF business, because we have managers in IETF= , amanager should follow up and push the work or find who can help. No one = asked me to help or no author asked the WG participants that they need help= . If authors don't ask for help, they MUST not hold our draft or the dr= aft we adopted. The IESG MUST solve this issue, and SHOULD find a better wa= y to make WG lists respond to serious people/participats.

=C2=A0

This being so, dependent on importance of topic, time spent by the authors,= responsiveness by WG, and others, drafts will proceed in their own tempo (= or leisure).

It is a bad idea to stop all WG progress on all topics, because some drafts= have a very slow progress.

I never lik= e to stop any thing, but we need to agree/discuss on priorities, any IETF W= G should discuss all issues, but some WGs discuss off lines or in the face = to face meeting. While I don't do meeting, I am concerned by WG list or= our ROLL list.

=C2=A0
Drafts with little activity will finally disappear, while the WG as such ne= eds to make progress.

I know, but the W= G chair should comment on the list for such issue when appears. Please note= that in this comment I am not against any, but just discussing for best pr= actice,
=C2=A0

There are two concerns that I have at the moment and that I want to discuss= during ietf101:
- Making sure that all (current and future) drafts which discuss parent sel= ection, ranking, or dodag selection, clarify the chosen metric and that the= different metrics can co-exist or exclude each other during RPL operation.=
- Making sure that there are enough authors and reviewers to advance this s= ubject

I hope this clarifies the wish for a discussion during ietf101.

Yes,=C2=A0hope you/authors contact me if there is = any draft needs co-authoring/assistant,=C2=A0while some authors are bussy a= s you mentioned. So we need to make things faster/acurate by sharing load.= =C2=A0

AB=C2=A0

Africa Re= gion

(above using SHOLD or MUST is not shouting, j= ust like to use more clear wording)


Peter

Abdussalam Baryun schreef op 2018-02-10 10:21:
Hi WG,

I disagree to discuss new issues before discussing our adopted drafts,
especially WGLC ones,

I suggest that our editors reply to discussions in our list, related
to adopted drafts before the ietf meeting,

I hope that this WG managers or Chairs, and the IETF chair follow up
to solve this important issue, the issue of no replies from ietf
lists.

AB

On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok
<stokcons@xs4all= .nl> wrote:

Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are
still many topics to address that fit within our charter. The
proliferation of topics worries us a bit. We have only a limited
number of active authors and some topics also seem to be competing.
The result of this situation might be that we have an overflowing
work agenda. Therefore, we need to find additional people to work on
those topics; or reduce the number of topics.
It is our suggestion that we discuss these topics, find dedicated
authors, and prioritize them=C2=A0 after some debate on the M-L.
Also we should like to remove the competitive subjects by joining
them into one draft.

Your comments please.

Ines + Peter

------------------------ List of topics
------------------------------------------

1 Route invalidation as a standalone topics The topic is mentioned
in several drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be
reachable and move in a RPL network.

3. Not all implementers are aware of the design issues of storing
mode of
RPL vs non-storing. Both of the modes have issues with their design.
Some
issues are getting sorted out by drafts such as dao-projection and
no-path
DAO optimization. But still considerable design issues need to be
handled. To name few:
a. handling parent switching optimally in storing MOP. Currently
with
Storing MOP it would lead to DIO/DAO storm in the sub-path from the
child
node who switches the parent. This is handled well in NS MOP
(Non-storing
MOP).
b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases
it is
trivial, but in most cases it is not (considering dependence on
several
state variables such as DTSN across reboots)! Also for practical
point of
view, need to consider that writing to flash/NV-memory is not a good
option in
embedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a
discussion on
ML long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will
be
taken care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs.
parent selection (for re-parenting within a DODAG). 6TiSCH has
isolated the need for a join preference which is different from the
Rank used in parent selection. The resulting Rank may be used in the
join preference, but not only. The size of the DODAG, the number of
children of that parent, etc... may influence. There is basically
the need for a new sort of objective function, this time in order to
select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that
standardizes the procedures suggested in the 6TiSCH architecture and
shows a non RPL aware joining a DODAG and moving inside. With the
new 6LoWPAN ND and the NP DAO, we now have all the tools to do it.
Unless we consider that the reference is the 6TiSCH architecture in
which case we complete the design there.

6. Exposing (some of) the structure of the Mesh to the root to
enable the DAO projection for transversal routes and in storing mode
in general.

7. Using bitmaps for multicast and unicast routing, used in
7a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to
RPL are not aware of many design considerations and there should be
a doc which talks about it. Similar work is started in
https://tools.ietf.org/h= tml/draft-clausen-lln-rpl-experiences-09 [1]
... but
it does not list all the issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?

--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
 www: www.vanderstok.org [2]
tel NL: +31(0)492474673 [3]=C2=A0 =C2=A0 =C2=A0F: +33(0)9660152= 48 [4]

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll= [5]



Links:
------
[1] https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09
[2] http://www.vanderstok.org
[3] tel:%2B31%280%29492474673
[4] tel:%2B33%280%29966015248
[5] https://www.ietf.org/mailman/listinfo/roll

--001a113dc9840d2e6c056524faf5-- From nobody Wed Feb 14 01:01:29 2018 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 622E8126C83 for ; Wed, 14 Feb 2018 01:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wG5YMIme6XM3 for ; Wed, 14 Feb 2018 01:01:24 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D41126B6D for ; Wed, 14 Feb 2018 01:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2378; q=dns/txt; s=iport; t=1518598884; x=1519808484; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tAjA1qUhNd92vY8D6mV43zpTP8A2oKaWCVOsQkl6X0c=; b=Td2NG30jyNEVPf4M1V8FwqvZX56gWt0Mrt+HIth4KA58BhAaYm7zdrDt rARMsctel3gcTLsy2w3MJ5BssTf6J99UqPTUTzP/e1//0nq+dx8xt7YbT ADuNol1PXJsoMSf0euoYSzeEeWOQ8CXcsrr9g9aS0DCBDbzcNU0FzVWja 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQCI+YNa/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbiiSOJoICgReWQYIYChgLgV6DOgIaglNUGAECAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEBAgEBASEROgkHBwQCAQgRBAEBAQICJgICAiULFQgIAgQTC?= =?us-ascii?q?IolCBCwLIIniQCCEwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+DcoIVgVeBaIM?= =?us-ascii?q?ugy8BAQIBAYFRgzOCZQWkLgkCiB6NW4IoikOHYosUgm6JaQIRGQGBOwEfOYFQc?= =?us-ascii?q?BUZJIJGgwqBbXiMU4EZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,511,1511827200"; d="scan'208";a="70064869" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 09:01:23 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w1E91MxA002720 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Feb 2018 09:01:23 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 03:00:45 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 03:00:45 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt Thread-Index: AQHTpNDHT/qnjvCFfEOUEt1W2yRKEKOiWHAwgADAH4D//5zhKoAA5O/A Date: Wed, 14 Feb 2018 09:00:18 +0000 Deferred-Delivery: Wed, 14 Feb 2018 08:59:47 +0000 Message-ID: <83eb5c778ccd4abb88a2cb5d9834148b@XCH-RCD-001.cisco.com> References: <151852947104.13012.17003340794935098934.idtracker@ietfa.amsl.com> <4a15b40b98974761965b7d040bebd86b@XCH-RCD-001.cisco.com>, <17139.1518549241@obiwan.sandelman.ca> <4FABFC6C-608A-43AB-9B47-2CA0664E52E1@cisco.com> In-Reply-To: <4FABFC6C-608A-43AB-9B47-2CA0664E52E1@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-unaware-leaves-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 09:01:27 -0000 RG9uZSA6KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSANClNlbnQ6IG1hcmRpIDEzIGbDqXZyaWVyIDIwMTggMjA6MTkNClRvOiBS b3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbUm9sbF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtdGh1YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAwLnR4dA0KDQpUaGFua3MgTWljaGFlbCBJ 4oCZbGwgZml4IHRoaXMgaW4gMDEgc29vbiENCg0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0KPiBM ZSAxMyBmw6l2ci4gMjAxOCDDoCAyMDoxNCwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBz YW5kZWxtYW4uY2E+IGEgw6ljcml0IDoNCj4gDQo+IA0KPiBQYXNjYWwgVGh1YmVydCAocHRodWJl cnQpIDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3RlOg0KPj4gVGhpcyBpcyBhYm91dCBvbmUgb2Yg dGhlIGl0ZW1zIGluIHRoZSBDaGFpcnMnIHRvZG8gbGlzdCwgc3VwcG9ydGluZyANCj4+IG5vbi1S UEwgYXdhcmUgbGVhdmVzLg0KPiANCj4+IFRoaXMgc3VwcG9ydCBpcyBtYWRlIHBvc3NpYmxlIGJ5 IHRoZSB1cGRhdGUgdG8gUkZDIDY3NzUgdGhhdCBpcyBub3cgDQo+PiB1bmRlciBJU0VHIHJldmll dy4NCj4gDQo+IEFsc28gdXNlb2Zyb2xsaW5mbyBtYWtlcyBleHBsaWNpdCBtZW50aW9uIG9mIHRo ZW0uLi4NCj4gdGhhbmtzIGZvciB5b3VyIGRvY3VtZW50Li4uIEkgd2lsbCByZWFkIGl0IGF0IGxl bmd0aCBsYXRlci4NCj4gDQo+IEkgbm90aWNlZCB0aGUgdGl0bGUgd2FzICJSUEwtQklFUiIsIGJ1 dCBJIGNvdWxkbid0IGZpbmQgZnVydGhlciANCj4gcmVmZXJlbmNlIHRvIEJJRVIsIHNvIEknbSB0 aGlua2luZyBpdCdzIGEgY29weS1wYXN0ZSBlcnJvciBmcm9tIGFub3RoZXIgZG9jdW1lbnQuDQo+ IA0KPiBJIHRoaW5rIHRoYXQgdXNlb2ZycGxpbmZvIHNob3VsZCBiZSByZWZlcmVuY2VkLi4uDQo+ IA0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC1yb2xs LXVuYXdhcmUtbGVhdmVzLw0KPj4gSHRtbGl6ZWQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdGh1YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAwDQo+PiBIdG1saXplZDoN Cj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdGh1YmVydC1y b2xsLXVuYXdhcmUtbGVhdg0KPj4gZXMtMDANCj4gDQo+IA0KPj4gQWJzdHJhY3Q6IFRoaXMgc3Bl Y2lmaWNhdGlvbiB1cGRhdGVzIFJGQyA2NTUwIGFuZCBSRkMgNjc3NSB1bmljYXN0IA0KPj4gcm91 dGluZyBzZXJ2aWNlIGluIGEgUlBMIGRvbWFpbiB0byA2TG9XUEFOIE5EIG5vZGVzIHRoYXQgZG8g bm90IA0KPj4gcGFydGljaXBhdGUgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQo+IA0KPiANCj4g LS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxt YW4gU29mdHdhcmUgV29ya3MgDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Um9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Fri Feb 16 11:28:04 2018 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 63A68129515 for ; Fri, 16 Feb 2018 11:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uantwerpen.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 RQ3p-S89x9FV for ; Fri, 16 Feb 2018 11:28:00 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DCF1200C1 for ; Fri, 16 Feb 2018 11:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uantwerpen.onmicrosoft.com; s=selector1-uantwerpen-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9VRJs+Xuw93MhI6KQwfBrkxL/IsYQFqWoB1zEapwlmM=; b=sKRBkCyEAznBULNvmED1NBGE8eOH5OnXHZe2y4eyZ5pK+8HXjRNGz71Pwmn8x1SsvrFvrClzabyGjMqPEccZ4SSEJkG3ZOILf3D1CjlKdd5J+xiykFeTm8mJnVru7u6/kh5sPySI0R6gCeQX3H8epWhmz21rL2xGHl6KXdItBPg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Esteban.Municio@uantwerpen.be; Received: from taurus (188.188.80.229) by HE1PR0501MB2443.eurprd05.prod.outlook.com (2603:10a6:3:6c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 19:27:56 +0000 Message-ID: <1518809265.1358.3.camel@uantwerpen.be> From: Esteban Municio To: roll@ietf.org Date: Fri, 16 Feb 2018 20:27:45 +0100 Organization: UAntwerpen - imec Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-DWrYQOEY8C7Oq3AtTQQf" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 X-Originating-IP: [188.188.80.229] X-ClientProxiedBy: AM0PR0102CA0050.eurprd01.prod.exchangelabs.com (2603:10a6:208::27) To HE1PR0501MB2443.eurprd05.prod.outlook.com (2603:10a6:3:6c::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 10ab2a5a-2ead-43a4-cbe3-08d5757361b9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:HE1PR0501MB2443; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2443; 3:EclmB0yJ/o+6Um9oDz2O75fjR/1uO05fAN14aBl/ua1zBBDysG2mbgyXaPmNNYVHs8HcCQvhSsdK6q3V7ZpfcuT7pnxRQxXkx2xbTTSWJ2wI1+of1WaXCG9qitfTbW5dr5gc12oVA33EByy/UOhC615KfC9Y058nIhQ1lwUe+2JRqIl4ZKF5Qa8729G+0gxKngFAjP9e+ot8oCT4cNriysVkqd0MnsyYSAsJDl3L19QGttQ7XPUAmpO/2DvDMbc8; 25:8we55fC/Bcg7wYm6gfPzh062zXNK/ZdCuTUKmChuNMjRA2z0HRwfBbjHUDHfOdDm/X0+DwqSnOL9fGu9Wvi4ITYMWQC5M07oJluT/4Tv+N/B8C5m/lU+TdqOn9B/Vf4PZtd7a7GI8giXxJ+ODfAPL+9ZbkeXgQ+Tp2qshxqSC6f3/RZa5Vv5riPY33ET4u2cTdhMV5pm4Hj89yffK7DeWFGh0yBTKqM091TTh04rcOag9Hs+hRaY5IQf8s4/brJUSKVOx/9gu9AWb7BzpviHT9Tn/LErAksBCzfJQAwFyP30+rLgrjtQSCrLlimWp4IhuDRfUvqCcjK8nUMZnOZVkg==; 31:jPJt6fSJv60JXESAKT+Z/WuzTq7u9uwJIYnHViFpjzdohyUoBUI5fUQ4lfvVs89SYnalSsU44Bp3gTTfSgMN3Pdoh3XCTDA9jaQWPtbkIlqlntv3hBfj2FpHfLS9DiYSfCkHXKLGfVSHWjViEsDcxW4KTFsXriF4U1+mVBWTmKknZehVrJSjEGr5tMOh+oGhfxFGljUXkv0BBADOAgGzmKmUgQ9d2SqsJsnkbY20hYo= X-MS-TrafficTypeDiagnostic: HE1PR0501MB2443: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2443; 20:wkIC5FlX92GvzGSENngeBgSQJTYRi7pptSv9QKGjaOzlhT/N6s1CMx1di6wPkpzzT5gPdRRFeRa5YOlCuV/7XBwMwOmsuursfnjR16NExmjkpnuEUwODztMtJFDQdWnNn+BVUBG12Fqr+PcL4b0wIUbolFbeVqm+EPKm7cS4PUE=; 4:3Sswn5R12Mr9mcp0zbR7CU5jjpCxmTAIoSvJkwgOm42N+3bYtL68Jm6yUz2wf5p2O5TKxc+6tcclO5PHSwO+HG4VXEIXESHBT4bKxn+PAJNy8xi72Sbjd82lqUcakGDHZloTw10MsHcUHy6BKfDriU6Y8aGQ2Msh5IrSHuJCwCU48uWTpiBHw/IB1tw7zqOHtEnTU8TInr0Sd8mhVYYxc8stdhTNLpfPf0EboRgDF0CHt0BRmJCbCVH2H2sERRRUaPhi9gva53Xdzz3t2CGsAQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR0501MB2443; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2443; X-Forefront-PRVS: 0585417D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(39380400002)(39850400004)(53754006)(189003)(199004)(86362001)(186003)(8936002)(50226002)(84326002)(81166006)(25786009)(8676002)(66066001)(74482002)(53936002)(6116002)(81156014)(105586002)(2906002)(478600001)(6486002)(3846002)(72206003)(5660300001)(33964004)(786003)(6916009)(316002)(2351001)(7736002)(103116003)(97736004)(2361001)(59450400001)(6496006)(305945005)(6666003)(21480400003)(386003)(26005)(52116002)(16526019)(16586007)(36916002)(68736007)(106356001)(270700001)(36756003)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2443; H:taurus; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: uantwerpen.be does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR0501MB2443; 23:JCHXTy7+GMR1p4uzNlEnvSCddbNQxTaPkokoLgB?= =?us-ascii?Q?bLPFkrg8mk0DL0XjNBaU/enSjBUqCJq7wuO6j1y9GH562goeaRH1TCa1kzna?= =?us-ascii?Q?xJguYrzIx2cphAgxkFvmLeOy2cnY8UQPm5OXb2+wO8tRh715Y3VZ6UXBRIZ8?= =?us-ascii?Q?szxzid3+e66/DfCKy9OC3v8p1b1ryFjjTrtJKFhY0N7Xn7b/7sZHLx1/lZli?= =?us-ascii?Q?p+CiysUhBXoH1eUgj2J2BQOpCGTJPrD4qqGxT8G3JwzjCBehUtYKKmBUQ1v5?= =?us-ascii?Q?x1CsYqaPKx1+xkKilwVOGw6ovW582tJzSUn0GazraDxleqNUzvCe8Kuiqz7D?= =?us-ascii?Q?Xas59ZYUtL2AT5VTWZBeavOn4x/gjd+ABYb550SGObOw+bKgG5iaTd0XGQGB?= =?us-ascii?Q?UBNZlkseenWjf5MZ0taBGLhFqayl0PqdFKOY5mmAHuilRFbE+5YvoJF8MCGo?= =?us-ascii?Q?70tUtSpgEFt4xqfTRIbHnaty8mchGL1HbTitA15Oa3gIUZoTvCM0e12EFr3D?= =?us-ascii?Q?dRziAWjPAueEnD/EMyzUu8yYvQArqOHp8+hlF9fLku6U5/ysDrjqEIe+6HKw?= =?us-ascii?Q?/w+iLx3Bx4qWF0F8Fu/JmRkX+XPaYEDqqr5Fs9EKOBDoMHetYtyFOmJSrO59?= =?us-ascii?Q?ZY4GVLyTJgfr2qgKVl/WYGKRVyRyKaSvOnLCZpR+cJRiDnXwfcnAO0D7HuTj?= =?us-ascii?Q?+aunfdezRnyEDOcJTZLy1DRQ7lJb795duzxyt2lO9em+VwRXUL4LnmFk//ee?= =?us-ascii?Q?8gSj6c2BcJLnjEhzOln4Z0qm5cgxyLmMjXVp74dH9kLNVo4djSJMSqHx8LGG?= =?us-ascii?Q?8DOi53oLpWKjcF2SqIkLvs1o8ZSGjCsUW1/Dh1XqMbxYUe6dkt8YCnGNoU4K?= =?us-ascii?Q?lRErp/C3zA0frx//+2/WfC4LtRevD2K/nyGkcWveG+PlTYrjeUxnyrFWPESz?= =?us-ascii?Q?EodZsIXQjIitCSwMKt/7AhsNiMaoysaUjUQoqsnvwIhAvWNmjBoP+ZD6cVpa?= =?us-ascii?Q?s7eEFG2JopY1j0S/LFYA2nyhFpNUwstrU9gpr8c6yEwUfdgjEDVZUjilc9Xj?= =?us-ascii?Q?aNWP8xkPL2sA+R6/V/T28cxYU0VyUWMAFupQO5MVqxheeHTtrnrc2L4hbrdo?= =?us-ascii?Q?XQAXy7iNo6KsGBfZHP77vXT1rkh+L+1SEbo9Eb8eq/oR5MkUjfI38PZxlw7l?= =?us-ascii?Q?dbhJNUd6nf0Q3ZQQpMIlyxdxArmZ6fcG51mVaifyPdyPZYw349b2l8i33HA?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2443; 6:VKjFWSXAnY7Hv63KPijVXtEBJr29sPK4boP7x/ceazJUsXmJp5OufiUPBO+Ki4TBMFz8Hv46OBSw9Sms1ncbzDABcO/IDwIlrnGLLH+g6PFA5wGokzcONucD+9tG/L6gllfmWNPpzE/C4E9W47+nEC7BqO0r/vadyQB7G0Yg+hUjvArrEChsSsSJKjFZP5SrHL7g87L7dltq1z0u1k2ixS4SqAPhsDCZZeH/uSGKgrk3TsvSt92Py2/06TWHk4vntuHPef4C74FumpFGCt40tCeV96YE1OCrE+pIXJKKQrmfQUgBv2S4WKJYfj11x0xCb9JUTZSdZSAT1ooq4VfKriN0EyEg17GbrIgxmlEQtgw=; 5:SRYewYMbHUsjLuqWW7qiTZOoKgG7K4t8Ho2/uRWmt7KeMausoKtdBWUEZ0U1sw4jkvXd9dhT5HDU86J7nfUQBsFJogC1d0z3HWN+ykQBw+kMDkTAbzx1d5P+tNazkRataqjpijzgzIbR5Hs3DFxLVWkhKfvbuppD7GI1o041kwA=; 24:zKpFz08Fb4J60Fy0zGUTQw2k6bO/ItPhVtU9ePaUaozlCSStu5C+Wv31x3lpIpN2rwlNIZbUO8P507JBawJuASnU4aDfVPCoOEg5KU342E8=; 7:Ort1h37HUk9FBl7LYSwMDuaUzvj1ZwtRb46D493shbA9CzDiksbjkRF6Cx/uNs2Bva1fw9Yvo5MavpVXYexvbGzmEDZ4ESpcdLdQgeFgHtmBCm0Yz3foJxj7ztXKK0/+eQgl5fXgn2ChOErVrhblKk5xpVc1B/aL9mOMELKBslurdYVJDQgz9IdJg4C214W0r+pfjdg20PETz605wq55mVpcGXA/1fCYYdL9AAkrRv/Aich0UcxOlHMpFzrqKJrc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: uantwerpen.be X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2018 19:27:56.1235 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10ab2a5a-2ead-43a4-cbe3-08d5757361b9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 792e08fb-2d54-4a8e-af72-202548136ef6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2443 Archived-At: Subject: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 16 Feb 2018 19:28:02 -0000 --=-DWrYQOEY8C7Oq3AtTQQf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I think this has been already discussed, but I don't think I totally understand it. Is there any way to obtain the rank of the nodes at the DAGroot? (e.g. in order to monitor the network) One possible idea is obtain it through the ETX of the links. Apparently, some metrics can be sent in the in DAG Metric Container, but I'm not sure if this option can be included in DIOs and DAOs, or only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. Is there any important reason to not send them in the DAOs as well (at least in the non-storing mode)? If this is not possible, is there any other way within RPL to deliver this information to the DAGroot? Otherwise, I only only possibilities: - Send the rank values from the application layer (which is not very=C2=A0 convenient since that would require access to the RPL sublayer) - Through sniffer nodes that would get DIO packets in the network. (however this would require distributing additional nodes all over the network) Am I missing something? Any idea? Thank you and kind regards, Esteban=20 --=20 Esteban Municio IDLab - Dept. Mathematics and Computer Science=C2=A0 University of Antwerp - imec Middelheimlaan 1 , 2020 Antwerp, Belgium=C2=A0 Office M.G.322=C2=A0 --=-DWrYQOEY8C7Oq3AtTQQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEwXAVTO0Lr5fj2oZRgSPJgpHrOpwFAlqHMLEACgkQgSPJgpHr OpymVgf+JIAqLan68ZPV28HQkHtGXM66shyo340qjDgpwODxguhgPY+wwDusnren w6+R5vrkp4ijXSblmsEs/uJghtlfxbWCccawDjBrKwvUCXjVbJLgygfcouW9rmFG +kMBmAblCcqLiVWTdOkcZ7U9gaW33xCXd6wveJGUA6JTTNZTNlSLjzxy0NTb7fj2 n15NLiBkvipuERU8aU5g5Dbb9MXsfdWmOFm9Sy28GvuAAYGolWoZWtjWNAhf1trJ rgDU7TjEhAvygpAoLDNG/7RYgLdxACxUGlLr8AzQjBeaiYIHhV6MyGC6DXKTi7Y+ NjXTRz9CbwjboxWzTL31RRl3wUMB/w== =bQXK -----END PGP SIGNATURE----- --=-DWrYQOEY8C7Oq3AtTQQf-- From nobody Sat Feb 17 08:35:56 2018 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 10A8C124D37; Sat, 17 Feb 2018 08:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Uakud0OBl9; Sat, 17 Feb 2018 08:35:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414F6120725; Sat, 17 Feb 2018 08:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1HGZnob014540; Sat, 17 Feb 2018 17:35:49 +0100 (CET) Received: from client-0231.vpn.uni-bremen.de (client-0231.vpn.uni-bremen.de [134.102.107.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zkFxb641RzDXjF; Sat, 17 Feb 2018 17:35:47 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 540578138.655839-8607d65a67d924e15190ba9329501d11 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 17 Feb 2018 08:35:40 -0800 Message-Id: To: lo <6lo@ietf.org>, tisch <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF101: DRAFT AGENDA X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 17 Feb 2018 16:35:55 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF101. Remember that there is still quite some potential for changes. The painful ones (not necessarily fixable) this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC. All times are BST (UTC+0100). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Bleinheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Buckingham ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Buckingham SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Bleinheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Bleinheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Bleinheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Bleinheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Richm_Chl_Tow ART ice Interactive Connectivity Establishment = WG - 0930 - 1030 Sandringham INT homenet Home Networking WG Bleinheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG Balmoral SEC *** suit Software Updates for Internet of Things = WG 1150-1320 Afternoon Session I Bleinheim RTG detnet Deterministic Networking WG 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Sun Feb 18 18:00:55 2018 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 23993126FDC for ; Sun, 18 Feb 2018 18:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cLBpI3sasty for ; Sun, 18 Feb 2018 18:00:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D218126D3F for ; Sun, 18 Feb 2018 18:00:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C5F320091 for ; Sun, 18 Feb 2018 21:08:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 998FF80BE3 for ; Sun, 18 Feb 2018 21:00:50 -0500 (EST) From: Michael Richardson To: "Routing Over Low power and Lossy networks" In-Reply-To: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> References: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 02:00:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable {this may be a duplicate, but I don't see it in the archive} Pascal Thubert (pthubert) wrote: > From an architecture point of view, RPL either ignores or mixes the > preference for the network, the DODAG in the network, the Join Proxy = =3D in > the DODAG at join time, the parent in the DODAG once joined, and then > the next hop at forwarding time, all in one concept of Rank. It seems that you are making the following assumptions, which I think are worth making explicit. I further suggest that this gets written down into= =3D a requirements-like document before 101. 1) that the different DODAGs have different L2-network-wide-keys. That per-host-pair (802.15.9 mediated) keying never occurs. 2) that the different DODAGs have overlapping 2-byte short addresses. 3) that even after the initial enrollment, that the nodes can either reuse their PSKs (in the case of 6tisch minimal security) again, or that they have been provisioned with different PSKs for each PANID. 4) that the enrollment process does *not* result in a different credential (an LDevID for instance), that could be used to provide keying for all DODAGs. 5) it's unclear to me in a 6tisch context, if the different DODAGs/PANs have a coordinated schedule or not. To me, it seems like enrollment should occur once. These different DODAGs which might be on different PANIDs, should have different RPL instanceIDs. Perhaps it's enough to have different DODAGIDs. > I see that defining all the above belongs to ROLL and that 6TiSCH is > concerned with expressing requirements and mapping the information ba= =3D ck > into IEEE std 802.15.4 beacons. All in all, 6TiSCH recommends not to > beacon till L3 is up and running (including RPL) and then to set the > 802.15.4 Join preference in beacons with the Rank. Michael's draft > indicates that this is not enough and propose a 4 tuple: netID, > DODAG_Rank, JP-Rank, and RPL Rank. This will probably require a new > IE. Do you mean an IE other than the one that the 6tisch-enhanced-beacon propos= =3D es to create? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqKL9IACgkQgItw+93Q 3WUxbQgAnt4ou7e4742fB3eyWf1qbQS1dkX0kW7EuJGTUO58cGkXsUdsiQl0mH9+ T0B12Vn3invVG/Q8FJlUPk6S8fPIfs+GnvjeI8q7EMWxUo1DUe4SFrmYjfECON4g CGxI2FQQWSxuInXVVv19KSjkFA7Xb/xeUIm/BtCdh6UFj+iqfdhubvmsJLO4yW9o uW2b9d1A6G4+6OSHHpYsuV5/EX8pGGRqUOeSSyoZWqIzDROPYENQL2lr64lSBI2i bOV4EwJ0y6FlQfP58ND25xt73WBH8WffZavR8pXZjf5G14cpw0W/G5PGP47LgBBw 9EnDVPbJgGs9BtBflEL1K0aNa4B5BQ== =ZF1Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 18 19:29:30 2018 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 B5FBC1270A3 for ; Sun, 18 Feb 2018 19:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eKQsMkuu3KKt for ; Sun, 18 Feb 2018 19:29:27 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB1F1201FA for ; Sun, 18 Feb 2018 19:29:27 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t3so12504309wmc.2 for ; Sun, 18 Feb 2018 19:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qBDMzOljCb0+o0QMAMhD9ZYcFQ4bA/dLaRTzcgjZxb0=; b=i6hSyw+WTTOLQaZfder74OBnX+8VCae3a+uT0JqbDMWiLo1TA3viYkkurKT7+RHWKI bu8N+7tZ1y9yOA0hqrnI2lGy29Zdr9E1SzwC1Q4idPA6MPQAl25xWJsN7sfQmId8wqvw lTBTqUobqZTbBwvJe7q/bW1oTsntL97ayL+RP0kBp2aMJOBS947p3aNX13qo9l8Q0Q82 klGPcvcojc+DzpNlf43M/RLt6UXiuNHJZI/Emso2batA04nTxT6rbqMpvo9Pzc7qCw70 1DRM9ut8U6q/vm+2Tyvc8ikdm51566ZiKuMs1RqmV6krCtMcUYZLebMXR9K5uKfqfa7e 0uXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qBDMzOljCb0+o0QMAMhD9ZYcFQ4bA/dLaRTzcgjZxb0=; b=ikN/Y54sGK9DAR1mtrHdMW4MNuuHI9BkJGip4ypyUfQzoj6AMUtuFVrwaXqFDK78NW kmF5glFplOy8TcwWprf2PNZLKFfXhLZYuVekoJAavnQxeDW1VhBmw+0UlW7q3gOwzYoW lStAxCTXK6lAPFZni5IN7K6VYEGBG3xyIXh4z258gV3enjmq8ZgFB9MeWUqn4vg7kUO3 d+zFWxCPPtFUdkl566W3Qpl/EbpKf6lR5xsbKiloByNMIt1xKcJJaFny08fB3T4/nKRS kXumhouhjzb1wH26tC5nN2MN267hQmntwix1cQ0YNAL1HkFHRRIHWqiBBaBy61IEJAr6 BlLw== X-Gm-Message-State: APf1xPCHPN5lYMmvRDAlwBBgYiAMume0WeAWhzLte1EkSksgHnQ3tfGp pwgTXraO/eUUBn5mi6uHmUuhA02BvcZ6CD5acUA= X-Google-Smtp-Source: AH8x225EleY15IRxTLRggNgia4vs/QwIJEajIkGD2KE7yTZ+f33G8+KGrqzvumqPVRwShnK0prN7SndTaGVpgfZZSC4= X-Received: by 10.80.220.206 with SMTP id v14mr17816195edk.196.1519010965552; Sun, 18 Feb 2018 19:29:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.205.77 with HTTP; Sun, 18 Feb 2018 19:29:25 -0800 (PST) In-Reply-To: <1518809265.1358.3.camel@uantwerpen.be> References: <1518809265.1358.3.camel@uantwerpen.be> From: Rahul Jadhav Date: Mon, 19 Feb 2018 08:59:25 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403043e6ff00300680565884da9" Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 03:29:30 -0000 --f403043e6ff00300680565884da9 Content-Type: text/plain; charset="UTF-8" Hello Esteban, We had a similar requirement i.e. the root should be able to monitor the connectivity of the entire DODAG. We achieved it by using the target-parent information which is sent in the DAO. From this information you can form the complete DAG at the root. Is there any specific thing that is achieved by sending ETX/Rank ? i.e. if all you want is to monitor the DAG formation at the root then this information should work. Also even though parent-info is not 'usually' sent in the DAO in case of storing mode, we still ended up sending it in order to achieve this monitoring in storing mode as well. I dont think 6550 restricts sending parent info in DAO in storing mode. Regards, Rahul On 17 February 2018 at 00:57, Esteban Municio wrote: > Hi all, > > I think this has been already discussed, but I don't think I totally > understand it. > > Is there any way to obtain the rank of the nodes at the DAGroot? (e.g. > in order to monitor the network) > > One possible idea is obtain it through the ETX of the links. > > Apparently, some metrics can be sent in the in DAG Metric Container, > but I'm not sure if this option can be included in DIOs and DAOs, or > only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. > > Is there any important reason to not send them in the DAOs as well (at > least in the non-storing mode)? > > If this is not possible, is there any other way within RPL to deliver > this information to the DAGroot? > > Otherwise, I only only possibilities: > - Send the rank values from the application layer (which is not very > convenient since that would require access to the RPL sublayer) > - Through sniffer nodes that would get DIO packets in the network. > (however this would require distributing additional nodes all over the > network) > > Am I missing something? Any idea? > > Thank you and kind regards, > Esteban > > > > -- > Esteban Municio > > IDLab - Dept. Mathematics and Computer Science > > University of Antwerp - imec > > Middelheimlaan 1 , 2020 Antwerp, Belgium > > Office M.G.322 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --f403043e6ff00300680565884da9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Esteban,

We had a similar require= ment i.e. the root should be able to monitor the connectivity of the entire= DODAG.

We achieved it by using the target-parent = information which is sent in the DAO. From this information you can form th= e complete DAG at the root.=C2=A0

Is there any spe= cific thing that is achieved by sending ETX/Rank ? i.e. if all you want is = to monitor the DAG formation at the root then this information should work.=
Also even though parent-info is not 'usually' sent in th= e DAO in case of storing mode, we still ended up sending it in order to ach= ieve this monitoring in storing mode as well. I dont think 6550 restricts s= ending parent info in DAO in storing mode.

Regards= ,
Rahul



On 17 February 2018 at 00:57, Est= eban Municio <esteban.municio@uantwerpen.be> wro= te:
Hi all,

I think this has been already discussed, but I don't think I totally understand it.

Is there any way to obtain the rank of the nodes at the DAGroot? (e.g.
in order to monitor the network)

One possible idea is obtain it through the ETX of the links.

Apparently, some metrics can be sent in the in DAG Metric Container,
but I'm not sure if this option can be included in DIOs and DAOs, or only in DIOs. According to errata 5160 of RFC6560 is only in DIOs.

Is there any important reason to not send them in the DAOs as well (at
least in the non-storing mode)?

If this is not possible, is there any other way within RPL to deliver
this information to the DAGroot?

Otherwise, I only only possibilities:
- Send the rank values from the application layer (which is not very=C2=A0<= br> convenient since that would require access to the RPL sublayer)
- Through sniffer nodes that would get DIO packets in the network.
(however this would require distributing additional nodes all over the
network)

Am I missing something? Any idea?

Thank you and kind regards,
Esteban



--
Esteban Municio

IDLab - Dept. Mathematics and Computer Science=C2=A0

University of Antwerp - imec

Middelheimlaan 1 , 2020 Antwerp, Belgium=C2=A0

Office M.G.322=C2=A0


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


--f403043e6ff00300680565884da9-- From nobody Mon Feb 19 00:10:09 2018 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 D7522126C89 for ; Mon, 19 Feb 2018 00:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7MOQP6xnDW1y for ; Mon, 19 Feb 2018 00:10:02 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD931201FA for ; Mon, 19 Feb 2018 00:10:01 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id y19so1741260lfd.4 for ; Mon, 19 Feb 2018 00:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=+b6Pl4XrfKtP4MKEJo3CWT+qK//ewhUnkrBPNldMUOo=; b=ZJazA9z4VmDtXDAkgNkbrTB0cgjX5Xeo6ghBuKd67zPLN3Og9eNiMruvk2HzPGgjag p8WQkqsn7sHh1hdmJ22MaJq3hV2kMtwPwq084/NkHJFEF49RjDcJcF+McdORB2FRPXM7 VBGn0/Nl7HbuJU9PGe9o/4kVbKAXjN78IVR+YdpTY9ssFXIhprZfg7g9bPRFa48sj2Y6 Bqsf4Ad04EqvzwSUIEoDvYWsCtutFi1HeL3cJYfy5oGxHUOTBlUKsVPWjEzvUOHM5vBM lGCnroLWZNpHIuZffaBQGkwj+8sANUG/QI489tRS8UidpgWIB3/0SjAocENR+vWY+cCL sgoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=+b6Pl4XrfKtP4MKEJo3CWT+qK//ewhUnkrBPNldMUOo=; b=bwdzmnx30cn+aMFCUZqEy+VB/DwMz7cN4oWicl+2bpco2AOH2S+ejAdg7owpgpQsi1 QfanhpSS/yIU4lOJfTTqlD03ouEhC4ifiB0U0bsbEdKndViomigxmBWqbqhkwdBgULlu 6H9E3Wj4g2KgDzpCvfwxxCHa9zjwNnKJSNIhvJkNGGX/SPGcgR5uHqacVLMfx/oU3sD5 aTPmAOTSys9XxHBRQ2UyLirKQ6oCWWQovqATSrCvb+rElkNf3N0quQgb9EI8l0n6Po4D e1SxmV5+LTnfKxNPrn1JNa2+0UnynsTM1iYTy3zUxN01kCtUqPSaGC29GkolEVeqPON/ Xxjw== X-Gm-Message-State: APf1xPDnruC+kVf93KvC2ttNL669i5U6OONjXuia+TpCIILaIzQIiEjs bO6umYIV1skG8qZLTOEJRtFNXA== X-Google-Smtp-Source: AH8x2259QGkXmZXWbHAZl6XgaQyWm3LTpy3yPXKi0OjrmljVeBqQhBo7blzbnufr7r2ivHJvrvAmlQ== X-Received: by 10.25.33.203 with SMTP id h194mr8659976lfh.128.1519027799573; Mon, 19 Feb 2018 00:09:59 -0800 (PST) Received: from T40700DR057 ([130.233.145.29]) by smtp.gmail.com with ESMTPSA id c76sm188207ljd.61.2018.02.19.00.09.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Feb 2018 00:09:58 -0800 (PST) From: "Blockchain 2018" To: Date: Mon, 19 Feb 2018 10:09:58 +0200 Message-ID: <004f01d3a959$08b94760$1a2bd620$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01D3A969.CC448860" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdOpWP81R/mBDsfLSPePVUPeO+LVKw== Content-Language: fi Archived-At: Subject: [Roll] Call for paper - 2018 IEEE International Conference on Blockchain (Blockchain 2018) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 08:10:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0050_01D3A969.CC448860 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2018 IEEE International Conference on Blockchain (Blockchain 2018) = http://cse.stfx.ca/~blockchain2018/index.php =20 Halifax, Canada, July 30-August 03, 2018 =20 Introduction =20 As a promising technique to achieve decentralized consensus, blockchain = has been successfully applied into digital currency - bitcoin for = serving as a public ledger for transactions. Its secure design for = supporting a distributed computing system with high = Byzantine = fault tolerance is attracting wide attention all over the world. = Blockchain has a great potential for event recording, identity = management, fault provenance, behaviour tracking, and so on, especially = in a distributed system without a trusted authority or central server. = On one hand, blockchain will play an important role for secure = decentralization in such emerging fields as Internet of Things, Cyber = Physical Systems, edge computing, social networking, crowdsourcing and = next generation wireless communications, and even more other fields. On = the other hand, its advance should be further evolved in terms of = scalability, privacy, efficiency, flexibility and high dependability. =20 The 2018 IEEE International Conference on Blockchain (Blockchain-2018) = will provide a high-profile, leading-edge forum for researchers, = engineers, and practitioners to present latest advances and innovations = in key theories, infrastructure, schemes, and significant applications = for the blockchain, as well as to identify emerging research topics and = define the future. =20 Topics =20 The emergence and popularity of blockchain techniques will significantly = change the way of digital system operation and management. In the = meantime, the application of blockchain will exhibit a variety of = complicated problems and new requirements, which brings more open issues = and challenges for research communities. IEEE Blockchain-2018 will be held on July 30 =E2=80=93 August 03, 2018 = in Halifax, Canada. The goal of this conference is to promote = community-wide discussion identifying the advanced applications, = technologies and theories for blockchain. We seek submissions of papers = that invent novel techniques, investigate new applications, introduce = advanced methodologies, propose promising research directions and = discuss approaches for unsolved issues. Topics of interest include, but are not limited to: =20 =C5=B8 Theories of blockchain and its evolution =C5=B8 Smart contract and distributed ledger =C5=B8 Blockchain and Bitcoin security =C5=B8 Distributed consensus and fault tolerance mechanisms=20 =C5=B8 Blockchain schemes for decentralization=20 =C5=B8 Security, privacy and trust of blockchain and decentralized = schemes =C5=B8 Performance optimization of blockchain and decentralized schemes = =C5=B8 Applications with blockchain technique =C5=B8 Protocols and algorithms based on blockchain =C5=B8 Blockchain based lightweight data structures for IoT data =C5=B8 Blockchain based IoT security solutions =C5=B8 Blockchain in cyber physical systems =C5=B8 Blockchain in social networking =C5=B8 Bolckchain in crowdsourcing and crowdsensing =C5=B8 Blockchain in 5G =C5=B8 Blockchain in edge and cloud computing =C5=B8 Blockchain and trust management =C5=B8 Attacks on blockchain based systems =20 Special Issues: =C5=B8 IEEE Transactions on Systems, Man, and Cybernetics (IF: 6.22), = SI on Blockchain and Knowledge Automation = https://mp.weixin.qq.com/s/GU7u3E2kZ-S35xvQV-_Rhg =C5=B8 Future Generation Computer Systems, Elsevier (IF: 3.997), = Special Issue on Blockchain and Decentralization for Internet of Things = https://www.journals.elsevier.com/future-generation-computer-systems/call= -for-papers/special-issue-on-blockchain-and-decentralization-for-interne =C5=B8 IEEE Transactions on Big Data, Special Issue on Blockchain and = Big Data Fusion =C5=B8 Digital Communications and Networks, SI on Blockchain and = Communication Networks = http://www.keaipublishing.com/en/journals/digital-communications-and-netw= orks/call-for-papers/blockchain-and-communication-networks/ =C5=B8 Information Fusion, Elsevier (IF: 5.667), Special Issue on Data = Fusion in Heterogeneous Networks =C5=B8 Information Sciences, Elsevier (IF: 4.832), Special Issue on Big = Data Privacy =C5=B8 Information Sciences, Elsevier (IF: 4.832), Special Issue on = Privacy Computing: Principles and Applications = = https://www.journals.elsevier.com/information-sciences/call-for-papers/sp= ecial-issue-on-privacy-computing-principles-and-applicatio =C5=B8 Journal of Network and Computer Applications, Elsevier (IF: = 3.50) =20 Special Sessions and Workshops =C5=B8 BOCE 2018: 1st IEEE International Workshop on = Blockchain-Oriented Cybersecurity Engineering =C5=B8 = Special Session: Design of Blockchain = Applications =20 Submissions =20 All papers need to be submitted electronically through the conference = website ( http://edas.info/N24471) with PDF = format. Submitted papers must not substantially overlap with papers that = have been published or that are simultaneously submitted to a journal or = a conference with proceedings. Papers must be clearly presented in = English, must not exceed 8 pages in = IEEE Computer Society proceedings format (or up to 10 pages with = the pages over length charge), including tables, figures, references and = appendices. Papers will be selected based on their originality, = significance, relevance, and clarity of presentation assessed by at = least three reviewers. Submission of a paper should be regarded as a = commitment that, should the paper be accepted, at least one of the = authors will register and attend the conference to present the work. = Blockchain 2018 reserves the right to exclude a paper from distribution = after the conference (e.g., removal from the digital library and = indexing services), if the paper is not presented at the conference. All = accepted papers will be published in IEEE CPS proceedings (EI Indexed) = and collected by IEEE Xplorer Digital Library. One outstanding papers = will be selected to receive the Best Paper Awards. =20 Important Dates =20 Workshop Proposal Due: February 15, 2018 Paper Submission Deadline: March 15, 2018 Author Notification: April 15, 2018 Final Manuscript Due: May 15, 2018 =20 Organization Committee =20 General Chairs Vijay Varadharajan, The University of Newcastle, Australia Dinesh C. Verma, IBM, USA=20 Zheng Yan, Xidian University, China and Aalto University, Finland =20 Program Chairs Mohammed Atiquzzaman, University of Oklahoma, USA Jin Li, Guangzhou University, China Weizhi Meng, Technical University of Denmark, Denmark =20 Special Session and Workshop Chairs Xin Huang, University of Xi=E2=80=99an Jiaotong Liverpool, China Qinghua Lu, CSIRO, Australia Ruppa Thulasiram, University of Manitoba, Canada Hongsheng Zhou, Virginia Commonwealth University, USA =20 Technical Program Committee Ashiq Anjum, University of Derby, UK Giuseppe Ateniese, Stevens Institute of Technology, USA Man Ho Au, Hong Kong Polytechnic University, Hong Kong Natalia Beloff, University of Sussex, UK Yu Chen, University of California, Irvine, USA Fei Chen, Shenzhen University, China Alexander Chepurnoy, IOHK Research, Hong Kong Kostas Christidis, North Carolina State University, USA Tiziana Cimoli, University of Cagliari, Italy Shlomi Dolev, Ben-Gurion University, Israel Zeki Erkin, Delft University of Technology, Netherlands Wei Feng, Xidian University, China=20 Christopher Frantz, Norwegian University of Science and Technology, = Norway Antonio Faonio, IMDEA Software Institute, Spain Rosario Gennaro, City University of New York, USA Vincent Gramoli, University of Sydney, Australia Feng Hao, Newcastle University, UK Debiao He, Wuhan University, China Xin Huang, University of Xi=E2=80=99an Jiaotong Liverpool, China Praveen Jayachandran, IBM Research, India Raja Jurdak, CSIRO, Australia Salil S. Kanhere, University of New South Wales (Sydney), Australia Ghassan Karame, NEC Laboratories Europe, Germany Dilip Krishnaswamy, IBM Research, India Anthony Krzesinski, Stellenbosch University, South Africa Rami Khalil, ETH Zurich, Switzerland Mario Larangeira, Tokyo Institute of Technology, Japan Wenjuan Li, City University of Hong Kong, Hong Kong Jian Liu, Aalto University, Finland=20 Zhiqiang Liu, Shanghai Jiao Tong University, China Erwu Liu, Tongji University, China Xueqin Liang, Xidian University, China=20 Qinghua Lu, CSIRO, Australia Guillermo Navarro, Universitat Aut=C3=B2noma de Barcelona, Spain Christopher Natoli, The University of Sydney, Australia Mariusz Nowostawski, Norwegian University of Science and Technology, = Norway Federico Maggi, Trend Micro, Inc., Italy Breno de Medeiros, Google Inc., USA Pedro Moreno-Sanchez, Purdue University, USA Petr Novotny, IBM T. J. Watson Research Center, USA Zhonghong Ou, Beijing University of Posts and Telecommunications, China Claudio Orlandi, Aarhus University, Denmark John Palfreyman, IBM&Palfreyman Ventures, UK Cristina P=C3=A9rez-Sol=C3=A0, Universitat Aut=C3=B2noma de Barcelona, = Spain Laura Ricci, University of Pisa, Italy Na Ruan, Shanghai Jiaotong University, China Kouichi Sakurai, Kyushu University, Japan Rei Safavi-Naini, The University of Calgary, Canada Bjorn Scheuermann, Humboldt University of Berlin, Germany Claudio Schifanella, University of Turin, Italy Alessandro Sorniotti, IBM Research, Zurich Pawel Szalachowski, Singapore University of Technology and Design, = Singapore Peter Taylor, University of Melbourne, Australia Qiang Tang, New Jersey Institute of Technology University, USA Paolo Tasca, University College London, UK Stefan Tai, TU Berlin, Germany Shruti Tople, National University of Singapore, Singapore Hoang Tam Vo, IBM Research, Australia Qianhong Wu, Beihang University, China Danny Yang, BlockSeer, USA Anjia Yang, Jinan University, China Dengpan Ye, Wuhan University, China Kuo-Hui Yeh, National Dong Hwa University, Taiwan Qi Zhang, IBM Thomas J. Research Center, USA Yunhui Zhuang, City University of Hong Kong, Hong Kong Jan Ziegeldorf, RWTH Aachen University, Germany Dionysis Zindros, University of Athens, Greece =20 Steering Committee Elisa Bertino, Purdue University, USA Jinjun Chen, Swinburne University of Technology, Australia Robert H. Deng, Singapore Management University, Singapore Victor C. M. Leung, University of British Columbia, Canada Fenghua Li, Chinese Academy of Sciences, China Wenjing Lou, Virginia Polytechnic Institute and State University, USA Pierangela Samarati, Universit=C3=A0 degli Studi = di Milano, Italy Vijay = Varadharajan, University of Newcastle, Australia Chonggang Wang, InterDigital, USA Yang Xiang, Swinburne University of Technology, Australia=20 Zheng Yan, Xidian University, China and Aalto University, Finland = (chair) Laurence T. Yang, St. Francis Xavier University, Canada (chair) Qinghua Zheng, Xi=E2=80=99an Jiaotong University, China =20 Publicity chairs Entao Luo, Hunan university of science and engineering, China Wei Wang, Huazhong University of Science and Technology, China Xiaokang Wang, St Francis Xavier University, Canada=20 ------=_NextPart_000_0050_01D3A969.CC448860 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

2018 IEEE = International Conference on Blockchain (Blockchain = 2018)

http://cse.stfx.ca/~blockchain= 2018/index.php

 

Halifax, Canada, July 30-August 03, = 2018

 

Introduction

 

As a promising technique to achieve = decentralized consensus, blockchain has been successfully applied into = digital currency - bitcoin for serving as a public ledger for = transactions. Its secure design for supporting a distributed computing = system with high Byzantine fault = tolerance is = attracting wide attention all over the world. Blockchain has a great = potential for event recording, identity management, fault provenance, = behaviour tracking, and so on, especially in a distributed system = without a trusted authority or central server. On one hand, blockchain = will play an important role for secure decentralization in such emerging = fields as Internet of Things, Cyber Physical Systems, edge computing, = social networking, crowdsourcing and next generation wireless = communications, and even more other fields. On the other hand, its = advance should be further evolved in terms of scalability, privacy, = efficiency, flexibility and high dependability.

 

The 2018 IEEE International = Conference on Blockchain (Blockchain-2018) will provide a high-profile, = leading-edge forum for researchers, engineers, and practitioners to = present latest advances and innovations in key theories, infrastructure, = schemes, and significant applications for the blockchain, as well as to = identify emerging research topics and define the = future.

 

Topics

 

The emergence and popularity of = blockchain techniques will significantly change the way of digital = system operation and management. In the meantime, the application of = blockchain will exhibit a variety of complicated problems and new = requirements, which brings more open issues and challenges for research = communities.

IEEE Blockchain-2018 will be held on July 30 = =E2=80=93 August 03, 2018 in Halifax, Canada. The goal of this = conference is to promote community-wide discussion identifying the = advanced applications, technologies and theories for blockchain. We seek = submissions of papers that invent novel techniques, investigate new = applications, introduce advanced methodologies, propose promising = research directions and discuss approaches for unsolved = issues.

Topics of interest include, but are not limited = to:

 

=C5=B8  Theories of blockchain and its = evolution

=C5=B8  Smart contract and distributed ledger

=C5=B8  Blockchain and Bitcoin = security

=C5=B8  Distributed consensus and fault tolerance = mechanisms

=C5=B8  Blockchain schemes for decentralization =

=C5=B8  Security, privacy and trust of blockchain and = decentralized schemes

=C5=B8  Performance optimization of blockchain and = decentralized schemes

=C5=B8  Applications with blockchain technique

=C5=B8  Protocols and algorithms based on = blockchain

=C5=B8  Blockchain based lightweight data structures for = IoT data

=C5=B8  Blockchain based IoT security = solutions

=C5=B8  Blockchain in cyber physical systems

=C5=B8  Blockchain in social = networking

=C5=B8  Bolckchain in crowdsourcing and = crowdsensing

=C5=B8  Blockchain in 5G

=C5=B8  Blockchain in edge and cloud = computing

=C5=B8  Blockchain and trust = management

=C5=B8  Attacks on blockchain based = systems

 

Special Issues:

=C5=B8  IEEE Transactions on Systems, Man, and Cybernetics = (IF: 6.22), SI on Blockchain and Knowledge Automation = https://mp.weixin.qq.com/s/GU7u3E2kZ-S35xvQV-_Rhg

=C5=B8  Future Generation Computer Systems, Elsevier (IF: = 3.997), Special Issue on Blockchain and Decentralization for Internet of = Things = https://www.journals.elsevier.com/future-generation-computer-systems/call= -for-papers/special-issue-on-blockchain-and-decentralization-for-interne<= o:p>

=C5=B8  IEEE Transactions on Big Data, Special Issue on = Blockchain and Big Data Fusion

=C5=B8  Digital Communications and Networks, SI on = Blockchain and Communication Networks = http://www.keaipublishing.com/en/journals/digital-communications-and-netw= orks/call-for-papers/blockchain-and-communication-networks/

=C5=B8  Information Fusion, Elsevier (IF: 5.667), Special = Issue on Data Fusion in Heterogeneous Networks

=C5=B8  Information Sciences, Elsevier (IF: 4.832), = Special Issue on Big Data Privacy

=C5=B8  Information Sciences, Elsevier (IF: 4.832), = Special Issue on Privacy Computing: Principles and Applications = https://www.journals.elsevier.= com/information-sciences/call-for-papers/special-issue-on-privacy-computi= ng-principles-and-applicatio

=C5=B8  Journal of Network and Computer Applications, = Elsevier (IF: 3.50)

 

Special Sessions and = Workshops

=C5=B8  BOCE 2018: 1st IEEE International Workshop on = Blockchain-Oriented Cybersecurity Engineering

=C5=B8  Special Session: Design of = Blockchain Applications

 

Submissions

 

All papers need to = be submitted electronically through the conference website (http://edas.i= nfo/N24471) with PDF format. Submitted = papers must not substantially overlap with papers that have been = published or that are simultaneously submitted to a journal or a = conference with proceedings. Papers must be clearly presented in = English, must not exceed 8 pages in IEEE = Computer Society proceedings format (or up to 10 pages with = the pages over length charge), including tables, figures, references and = appendices. Papers will be selected based on their originality, = significance, relevance, and clarity of presentation assessed by at = least three reviewers. Submission of a paper should be regarded as a = commitment that, should the paper be accepted, at least one of the = authors will register and attend the conference to present the work. = Blockchain 2018 reserves the right to exclude a paper from distribution = after the conference (e.g., removal from the digital library and = indexing services), if the paper is not presented at the conference. All = accepted papers will be published in IEEE CPS proceedings (EI Indexed) = and collected by IEEE Xplorer Digital Library. One outstanding papers = will be selected to receive the Best Paper Awards.

 

Important = Dates

 

Workshop Proposal = Due:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 February 15, 2018

Paper Submission = Deadline:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 March 15, = 2018

Author = Notification:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= April 15, 2018

Final Manuscript = Due:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 May 15, = 2018

 

Organization = Committee

 

General Chairs

Vijay = Varadharajan, The University of Newcastle, = Australia

Dinesh C. Verma, IBM, USA

Zheng Yan, = Xidian University, China and Aalto University, = Finland

 

Program Chairs

Mohammed = Atiquzzaman, University of Oklahoma, USA

Jin Li, = Guangzhou University, China

Weizhi Meng, = Technical University of Denmark, Denmark

 

Special Session and Workshop = Chairs

Xin Huang, University of Xi=E2=80=99an Jiaotong = Liverpool, China

Qinghua Lu, CSIRO, = Australia

Ruppa Thulasiram, University of Manitoba, = Canada

Hongsheng Zhou, Virginia Commonwealth University, = USA

 

Technical Program = Committee

Ashiq = Anjum, University of Derby, UK

Giuseppe = Ateniese, Stevens Institute of Technology, USA

Man Ho = Au, Hong Kong Polytechnic University, Hong Kong

Natalia = Beloff, University of Sussex, UK

Yu Chen, = University of California, Irvine, USA

Fei Chen, = Shenzhen University, China

Alexander = Chepurnoy, IOHK Research, Hong Kong

Kostas Christidis, North Carolina State = University, USA

Tiziana = Cimoli, University of Cagliari, Italy

Shlomi = Dolev, Ben-Gurion University, Israel

Zeki = Erkin, Delft University of Technology, = Netherlands

Wei Feng, = Xidian University, China

Christopher Frantz, Norwegian University of Science and = Technology, Norway

Antonio = Faonio, IMDEA Software Institute, Spain

Rosario = Gennaro, City University of New York, USA

Vincent = Gramoli, University of Sydney, Australia

Feng Hao, = Newcastle University, UK

Debiao = He, Wuhan University, China

Xin = Huang, University of Xi=E2=80=99an Jiaotong Liverpool, = China

Praveen = Jayachandran, IBM Research, India

Raja = Jurdak, CSIRO, Australia

Salil S. = Kanhere, University of New South Wales (Sydney), = Australia

Ghassan = Karame, NEC Laboratories Europe, Germany

Dilip = Krishnaswamy, IBM Research, India

Anthony = Krzesinski, Stellenbosch University, South = Africa

Rami = Khalil, ETH Zurich, Switzerland

Mario = Larangeira, Tokyo Institute of Technology, Japan

Wenjuan = Li, City University of Hong Kong, Hong Kong

Jian Liu, = Aalto University, Finland

Zhiqiang = Liu, Shanghai Jiao Tong University, China

Erwu Liu, = Tongji University, China

Xueqin = Liang, Xidian University, China

Qinghua = Lu, CSIRO, Australia

Guillermo = Navarro, Universitat Aut=C3=B2noma de Barcelona, = Spain

Christopher Natoli, The University of Sydney, = Australia

Mariusz = Nowostawski, Norwegian University of Science and Technology, = Norway

Federico = Maggi, Trend Micro, Inc., Italy

Breno de = Medeiros, Google Inc., USA

Pedro Moreno-Sanchez, Purdue University, = USA

Petr = Novotny, IBM T. J. Watson Research Center, USA

Zhonghong = Ou, Beijing University of Posts and Telecommunications, = China

Claudio = Orlandi, Aarhus University, Denmark

John = Palfreyman, IBM&Palfreyman Ventures, UK

Cristina = P=C3=A9rez-Sol=C3=A0, Universitat Aut=C3=B2noma de Barcelona, = Spain

Laura = Ricci, University of Pisa, Italy

Na Ruan, = Shanghai Jiaotong University, China

Kouichi = Sakurai, Kyushu University, Japan

Rei = Safavi-Naini, The University of Calgary, Canada

Bjorn = Scheuermann, Humboldt University of Berlin, = Germany

Claudio = Schifanella, University of Turin, Italy

Alessandro Sorniotti, IBM Research, = Zurich

Pawel = Szalachowski, Singapore University of Technology and Design, = Singapore

Peter = Taylor, University of Melbourne, Australia

Qiang Tang, New Jersey Institute of Technology = University, USA

Paolo Tasca, University College London, = UK

Stefan Tai, TU Berlin, = Germany

Shruti Tople, National University of Singapore, = Singapore

Hoang Tam Vo, IBM Research, = Australia

Qianhong Wu, Beihang University, = China

Danny Yang, BlockSeer, = USA

Anjia Yang, Jinan University, = China

Dengpan Ye, Wuhan University, = China

Kuo-Hui Yeh, National Dong Hwa University, = Taiwan

Qi Zhang, IBM Thomas J. Research Center, = USA

Yunhui Zhuang, City University of Hong Kong, = Hong Kong

Jan Ziegeldorf, RWTH Aachen University, = Germany

Dionysis = Zindros, University of Athens, Greece

 

Steering Committee

Elisa Bertino, Purdue University, = USA

Jinjun Chen, Swinburne University of Technology, = Australia

Robert H. Deng, Singapore Management University, = Singapore

Victor C. M. Leung, University of British = Columbia, Canada

Fenghua Li, Chinese Academy of Sciences, = China

Wenjing Lou, Virginia Polytechnic Institute and = State University, USA

Pierangela Samarati, Universit=C3=A0 degli Studi = di Milano, = Italy

Vijay = Varadharajan, = University of Newcastle, Australia

Chonggang Wang, InterDigital, = USA

Yang Xiang, Swinburne University of Technology, = Australia

Zheng Yan, Xidian University, China and Aalto = University, Finland (chair)

Laurence T. Yang, St. Francis Xavier University, = Canada (chair)

Qinghua Zheng, Xi=E2=80=99an Jiaotong University, = China

 

Publicity = chairs

Entao Luo, Hunan university of science and = engineering, China

Wei Wang, = Huazhong University of Science and Technology, = China

Xiaokang = Wang, St Francis Xavier University, Canada =

------=_NextPart_000_0050_01D3A969.CC448860-- From nobody Mon Feb 19 00:20:44 2018 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 5540D126B72 for ; Mon, 19 Feb 2018 00:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueUHVF_IDq_1 for ; Mon, 19 Feb 2018 00:20:38 -0800 (PST) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0491201FA for ; Mon, 19 Feb 2018 00:20:38 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:212]) by smtp-cloud8.xs4all.net with ESMTPA id nggdeNFATar0wnggdeMmwO; Mon, 19 Feb 2018 09:20:36 +0100 Received: from AMontpellier-654-1-73-22.w90-0.abo.wanadoo.fr ([90.0.168.22]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 19 Feb 2018 09:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 19 Feb 2018 09:20:35 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <004f01d3a959$08b94760$1a2bd620$@gmail.com> References: <004f01d3a959$08b94760$1a2bd620$@gmail.com> Message-ID: <51440d1e83c901c46773bfd95f065714@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfP0eAIq6wJ1/b3wCv2dDhZy9y6749MsoBPtpxoQgnZGzNC+lA3cWqbsdL4SxYOZ89uIAodCAqE2muwtb+aW+74DFg+pr/7fidmOZztv5Whm+qbZX/hll 86/tgsKd2BJUocUs4Hw5UJd6YwfhU0DqKzYEfWjL94w5m4+qylRfO9y200lUt2XY+mPyoRxPpOovEBULP7uGyojoBGti+dy0penpb3RqKU7BtStycFLFip3R cYmQ8Oqb5zqRSWGMNBZKjZVqeL8YlKJ5HoUtpSN6sSY= Archived-At: Subject: Re: [Roll] Call for paper - 2018 IEEE International Conference on Blockchain (Blockchain 2018) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 08:20:42 -0000 Hi Bockchain 2018.. Several times we have asked people to first ask our permission to distribute CFPs. We would certainly have refused this one. Please, stop doing this. The ROLL ML is a professional tool, not to be misused for PR activities. Peter van der Stok Blockchain 2018 schreef op 2018-02-19 09:09: > 2018 IEEE INTERNATIONAL CONFERENCE ON BLOCKCHAIN (BLOCKCHAIN 2018) > > http://cse.stfx.ca/~blockchain2018/index.php [1] > > Halifax, Canada, July 30-August 03, 2018 > > INTRODUCTION > > As a promising technique to achieve decentralized consensus, > blockchain has been successfully applied into digital currency - > bitcoin for serving as a public ledger for transactions. Its secure > design for supporting a distributed computing system with high > Byzantine fault tolerance [2] is attracting wide attention all over > the world. Blockchain has a great potential for event recording, > identity management, fault provenance, behaviour tracking, and so on, > especially in a distributed system without a trusted authority or > central server. On one hand, blockchain will play an important role > for secure decentralization in such emerging fields as Internet of > Things, Cyber Physical Systems, edge computing, social networking, > crowdsourcing and next generation wireless communications, and even > more other fields. On the other hand, its advance should be further > evolved in terms of scalability, privacy, efficiency, flexibility and > high dependability. > > The 2018 IEEE International Conference on Blockchain (Blockchain-2018) > will provide a high-profile, leading-edge forum for researchers, > engineers, and practitioners to present latest advances and > innovations in key theories, infrastructure, schemes, and significant > applications for the blockchain, as well as to identify emerging > research topics and define the future. > > TOPICS > > The emergence and popularity of blockchain techniques will > significantly change the way of digital system operation and > management. In the meantime, the application of blockchain will > exhibit a variety of complicated problems and new requirements, which > brings more open issues and challenges for research communities. > > IEEE Blockchain-2018 will be held on July 30 – August 03, 2018 in > Halifax, Canada. The goal of this conference is to promote > community-wide discussion identifying the advanced applications, > technologies and theories for blockchain. We seek submissions of > papers that invent novel techniques, investigate new applications, > introduce advanced methodologies, propose promising research > directions and discuss approaches for unsolved issues. > > Topics of interest include, but are not limited to: > > Ÿ Theories of blockchain and its evolution > > Ÿ Smart contract and distributed ledger > > Ÿ Blockchain and Bitcoin security > > Ÿ Distributed consensus and fault tolerance mechanisms > > Ÿ Blockchain schemes for decentralization > > Ÿ Security, privacy and trust of blockchain and decentralized > schemes > > Ÿ Performance optimization of blockchain and decentralized schemes > > Ÿ Applications with blockchain technique > > Ÿ Protocols and algorithms based on blockchain > > Ÿ Blockchain based lightweight data structures for IoT data > > Ÿ Blockchain based IoT security solutions > > Ÿ Blockchain in cyber physical systems > > Ÿ Blockchain in social networking > > Ÿ Bolckchain in crowdsourcing and crowdsensing > > Ÿ Blockchain in 5G > > Ÿ Blockchain in edge and cloud computing > > Ÿ Blockchain and trust management > > Ÿ Attacks on blockchain based systems > > SPECIAL ISSUES: > > Ÿ IEEE Transactions on Systems, Man, and Cybernetics (IF: 6.22), SI > on Blockchain and Knowledge Automation > https://mp.weixin.qq.com/s/GU7u3E2kZ-S35xvQV-_Rhg > > Ÿ Future Generation Computer Systems, Elsevier (IF: 3.997), Special > Issue on Blockchain and Decentralization for Internet of Things > https://www.journals.elsevier.com/future-generation-computer-systems/call-for-papers/special-issue-on-blockchain-and-decentralization-for-interne > > Ÿ IEEE Transactions on Big Data, Special Issue on Blockchain and Big > Data Fusion > > Ÿ Digital Communications and Networks, SI on Blockchain and > Communication Networks > http://www.keaipublishing.com/en/journals/digital-communications-and-networks/call-for-papers/blockchain-and-communication-networks/ > > Ÿ Information Fusion, Elsevier (IF: 5.667), Special Issue on Data > Fusion in Heterogeneous Networks > > Ÿ Information Sciences, Elsevier (IF: 4.832), Special Issue on Big > Data Privacy > > Ÿ Information Sciences, Elsevier (IF: 4.832), Special Issue on > Privacy Computing: Principles and Applications > https://www.journals.elsevier.com/information-sciences/call-for-papers/special-issue-on-privacy-computing-principles-and-applicatio > [3] > > Ÿ Journal of Network and Computer Applications, Elsevier (IF: 3.50) > > SPECIAL SESSIONS AND WORKSHOPS > > Ÿ BOCE 2018: 1st IEEE International Workshop on Blockchain-Oriented > Cybersecurity Engineering > > Ÿ Special Session: Design of Blockchain Applications [4] > > SUBMISSIONS > > All papers need to be submitted electronically through the conference > website (http://edas.info/N24471 [5]) with PDF format. Submitted > papers must not substantially overlap with papers that have been > published or that are simultaneously submitted to a journal or a > conference with proceedings. Papers must be clearly presented in > English, must not exceed 8 pages in IEEE Computer Society proceedings > [6] format (or up to 10 pages with the pages over length charge), > including tables, figures, references and appendices. Papers will be > selected based on their originality, significance, relevance, and > clarity of presentation assessed by at least three reviewers. > Submission of a paper should be regarded as a commitment that, should > the paper be accepted, at least one of the authors will register and > attend the conference to present the work. Blockchain 2018 reserves > the right to exclude a paper from distribution after the conference > (e.g., removal from the digital library and indexing services), if the > paper is not presented at the conference. All accepted papers will be > published in IEEE CPS proceedings (EI Indexed) and collected by IEEE > Xplorer Digital Library. One outstanding papers will be selected to > receive the Best Paper Awards. > > IMPORTANT DATES > > Workshop Proposal Due: February 15, 2018 > > Paper Submission Deadline: March 15, 2018 > > Author Notification: April 15, 2018 > > Final Manuscript Due: May 15, 2018 > > ORGANIZATION COMMITTEE > > GENERAL CHAIRS > > Vijay Varadharajan, The University of Newcastle, Australia > > Dinesh C. Verma, IBM, USA > > Zheng Yan, Xidian University, China and Aalto University, Finland > > PROGRAM CHAIRS > > Mohammed Atiquzzaman, University of Oklahoma, USA > > Jin Li, Guangzhou University, China > > Weizhi Meng, Technical University of Denmark, Denmark > > SPECIAL SESSION AND WORKSHOP CHAIRS > > Xin Huang, University of Xi’an Jiaotong Liverpool, China > > Qinghua Lu, CSIRO, Australia > > Ruppa Thulasiram, University of Manitoba, Canada > > Hongsheng Zhou, Virginia Commonwealth University, USA > > TECHNICAL PROGRAM COMMITTEE > > Ashiq Anjum, University of Derby, UK > > Giuseppe Ateniese, Stevens Institute of Technology, USA > > Man Ho Au, Hong Kong Polytechnic University, Hong Kong > > Natalia Beloff, University of Sussex, UK > > Yu Chen, University of California, Irvine, USA > > Fei Chen, Shenzhen University, China > > Alexander Chepurnoy, IOHK Research, Hong Kong > > Kostas Christidis, North Carolina State University, USA > > Tiziana Cimoli, University of Cagliari, Italy > > Shlomi Dolev, Ben-Gurion University, Israel > > Zeki Erkin, Delft University of Technology, Netherlands > > Wei Feng, Xidian University, China > > Christopher Frantz, Norwegian University of Science and Technology, > Norway > > Antonio Faonio, IMDEA Software Institute, Spain > > Rosario Gennaro, City University of New York, USA > > Vincent Gramoli, University of Sydney, Australia > > Feng Hao, Newcastle University, UK > > Debiao He, Wuhan University, China > > Xin Huang, University of Xi’an Jiaotong Liverpool, China > > Praveen Jayachandran, IBM Research, India > > Raja Jurdak, CSIRO, Australia > > Salil S. Kanhere, University of New South Wales (Sydney), Australia > > Ghassan Karame, NEC Laboratories Europe, Germany > > Dilip Krishnaswamy, IBM Research, India > > Anthony Krzesinski, Stellenbosch University, South Africa > > Rami Khalil, ETH Zurich, Switzerland > > Mario Larangeira, Tokyo Institute of Technology, Japan > > Wenjuan Li, City University of Hong Kong, Hong Kong > > Jian Liu, Aalto University, Finland > > Zhiqiang Liu, Shanghai Jiao Tong University, China > > Erwu Liu, Tongji University, China > > Xueqin Liang, Xidian University, China > > Qinghua Lu, CSIRO, Australia > > Guillermo Navarro, Universitat Autònoma de Barcelona, Spain > > Christopher Natoli, The University of Sydney, Australia > > Mariusz Nowostawski, Norwegian University of Science and Technology, > Norway > > Federico Maggi, Trend Micro, Inc., Italy > > Breno de Medeiros, Google Inc., USA > > Pedro Moreno-Sanchez, Purdue University, USA > > Petr Novotny, IBM T. J. Watson Research Center, USA > > Zhonghong Ou, Beijing University of Posts and Telecommunications, > China > > Claudio Orlandi, Aarhus University, Denmark > > John Palfreyman, IBM&Palfreyman Ventures, UK > > Cristina Pérez-Solà, Universitat Autònoma de Barcelona, Spain > > Laura Ricci, University of Pisa, Italy > > Na Ruan, Shanghai Jiaotong University, China > > Kouichi Sakurai, Kyushu University, Japan > > Rei Safavi-Naini, The University of Calgary, Canada > > Bjorn Scheuermann, Humboldt University of Berlin, Germany > > Claudio Schifanella, University of Turin, Italy > > Alessandro Sorniotti, IBM Research, Zurich > > Pawel Szalachowski, Singapore University of Technology and Design, > Singapore > > Peter Taylor, University of Melbourne, Australia > > Qiang Tang, New Jersey Institute of Technology University, USA > > Paolo Tasca, University College London, UK > > Stefan Tai, TU Berlin, Germany > > Shruti Tople, National University of Singapore, Singapore > > Hoang Tam Vo, IBM Research, Australia > > Qianhong Wu, Beihang University, China > > Danny Yang, BlockSeer, USA > > Anjia Yang, Jinan University, China > > Dengpan Ye, Wuhan University, China > > Kuo-Hui Yeh, National Dong Hwa University, Taiwan > > Qi Zhang, IBM Thomas J. Research Center, USA > > Yunhui Zhuang, City University of Hong Kong, Hong Kong > > Jan Ziegeldorf, RWTH Aachen University, Germany > > Dionysis Zindros, University of Athens, Greece > > STEERING COMMITTEE > > Elisa Bertino, Purdue University, USA > > Jinjun Chen, Swinburne University of Technology, Australia > > Robert H. Deng, Singapore Management University, Singapore > > Victor C. M. Leung, University of British Columbia, Canada > > Fenghua Li, Chinese Academy of Sciences, China > > Wenjing Lou, Virginia Polytechnic Institute and State University, USA > > Pierangela Samarati, Università degli Studi di Milano [7], Italy > > Vijay Varadharajan [8], University of Newcastle, Australia > > Chonggang Wang, InterDigital, USA > > Yang Xiang, Swinburne University of Technology, Australia > > Zheng Yan, Xidian University, China and Aalto University, Finland > (chair) > > Laurence T. Yang, St. Francis Xavier University, Canada (chair) > > Qinghua Zheng, Xi’an Jiaotong University, China > > PUBLICITY CHAIRS > > Entao Luo, Hunan university of science and engineering, China > > Wei Wang, Huazhong University of Science and Technology, China > > Xiaokang Wang, St Francis Xavier University, Canada > > Links: > ------ > [1] http://cse.stfx.ca/~blockchain2018/index.php > [2] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance > [3] > https://www.journals.elsevier.com/information-sciences/call-for-papers/special-issue-on-privacy-computing-principles-and-applicatio > [4] > file://Users/yanz1/Work/NewPublications/Services/Blockchain/download/CFP-ICBC%20Special%20Track.pdf > [5] http://edas.info/N24471 > [6] > http://www.ieee.org/conferences_events/conferences/publishing/templates.html > [7] http://www.unimi.it > [8] https://www.newcastle.edu.au/profile/vijay-varadharajan > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Feb 19 01:04:03 2018 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 EBA1C12711E for ; Mon, 19 Feb 2018 01:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 qXWWRhMfNTB7 for ; Mon, 19 Feb 2018 01:03:50 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA4F12426E for ; Mon, 19 Feb 2018 01:03:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id C1B1681A75 for ; Mon, 19 Feb 2018 10:03:47 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id tZA8O8kHpMEW for ; Mon, 19 Feb 2018 10:03:47 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 18DA281A99 for ; Mon, 19 Feb 2018 10:03:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 18DA281A99 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1519031027; bh=x434X9FP81UdwxjZ5RzXsjndlLmz/e31f9YOz8TVURM=; h=From:Message-Id:Mime-Version:Date:To; b=C9cvhHflYIQAt4bfYUWEkBiV7oFAiW4L+QRXKEuYnRWrf9sizkz3w4ZDXAuhxvF+g yhTHN6Wbi3I7gftUbMA//RnGwR8K4VaS0IRnA2tBBACDJmBXAPyunCX5d1jaWzOSje uh4MVi26TlrJrndryNKbDdaTPItP9mzCM3IfhwTo= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id AaqgeurAoFrz for ; Mon, 19 Feb 2018 10:03:47 +0100 (CET) Received: from [IPv6:2a01:e35:8af9:cc70:2508:a2b2:52b5:7199] (unknown [IPv6:2a01:e35:8af9:cc70:2508:a2b2:52b5:7199]) by zproxy110.enst.fr (Postfix) with ESMTPSA id C3E5581A75 for ; Mon, 19 Feb 2018 10:03:46 +0100 (CET) From: "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="Apple-Mail=_13ECF370-4271-4CD0-A26A-BEDB242C50FF" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 19 Feb 2018 10:03:45 +0100 References: <1518809265.1358.3.camel@uantwerpen.be> To: Routing Over Low power and Lossy networks In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 09:03:53 -0000 --Apple-Mail=_13ECF370-4271-4CD0-A26A-BEDB242C50FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Rahul, A minor question: You do this once the RPL DODAG is constructed? I assume the DAOs that are transmitted are in unicast, from child to = parent? Please correct me, if I misunderstood. Cheers, Georgios > On Feb 19, 2018, at 04:29, Rahul Jadhav wrote: >=20 > Hello Esteban, >=20 > We had a similar requirement i.e. the root should be able to monitor = the connectivity of the entire DODAG. >=20 > We achieved it by using the target-parent information which is sent in = the DAO. =46rom this information you can form the complete DAG at the = root.=20 >=20 > Is there any specific thing that is achieved by sending ETX/Rank ? = i.e. if all you want is to monitor the DAG formation at the root then = this information should work. > Also even though parent-info is not 'usually' sent in the DAO in case = of storing mode, we still ended up sending it in order to achieve this = monitoring in storing mode as well. I dont think 6550 restricts sending = parent info in DAO in storing mode. >=20 > Regards, > Rahul >=20 >=20 >=20 > On 17 February 2018 at 00:57, Esteban Municio = > = wrote: > Hi all, >=20 > I think this has been already discussed, but I don't think I totally > understand it. >=20 > Is there any way to obtain the rank of the nodes at the DAGroot? (e.g. > in order to monitor the network) >=20 > One possible idea is obtain it through the ETX of the links. >=20 > Apparently, some metrics can be sent in the in DAG Metric Container, > but I'm not sure if this option can be included in DIOs and DAOs, or > only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. >=20 > Is there any important reason to not send them in the DAOs as well (at > least in the non-storing mode)? >=20 > If this is not possible, is there any other way within RPL to deliver > this information to the DAGroot? >=20 > Otherwise, I only only possibilities: > - Send the rank values from the application layer (which is not very=20= > convenient since that would require access to the RPL sublayer) > - Through sniffer nodes that would get DIO packets in the network. > (however this would require distributing additional nodes all over the > network) >=20 > Am I missing something? Any idea? >=20 > Thank you and kind regards, > Esteban >=20 >=20 >=20 > -- > Esteban Municio >=20 > IDLab - Dept. Mathematics and Computer Science=20 >=20 > University of Antwerp - imec >=20 > Middelheimlaan 1 , 2020 Antwerp, Belgium=20 >=20 > Office M.G.322=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_13ECF370-4271-4CD0-A26A-BEDB242C50FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Rahul,

A = minor question:
You do this once the RPL DODAG is = constructed?
I assume the DAOs that are transmitted = are in unicast, from child to parent?

Please correct me, if I = misunderstood.

Cheers,
Georgios

On = Feb 19, 2018, at 04:29, Rahul Jadhav <rahul.ietf@gmail.com> wrote:

Hello Esteban,

We had a similar requirement i.e. the root should be able to = monitor the connectivity of the entire DODAG.

We achieved it by using the = target-parent information which is sent in the DAO. =46rom this = information you can form the complete DAG at the root. 

Is there any specific = thing that is achieved by sending ETX/Rank ? i.e. if all you want is to = monitor the DAG formation at the root then this information should = work.
Also even though parent-info is not 'usually' = sent in the DAO in case of storing mode, we still ended up sending it in = order to achieve this monitoring in storing mode as well. I dont think = 6550 restricts sending parent info in DAO in storing mode.

Regards,
Rahul



On 17 February 2018 at 00:57, = Esteban Municio <esteban.municio@uantwerpen.be> wrote:
Hi all,

I think this has been already discussed, but I don't think I totally
understand it.

Is there any way to obtain the rank of the nodes at the DAGroot? = (e.g.
in order to monitor the network)

One possible idea is obtain it through the ETX of the links.

Apparently, some metrics can be sent in the in DAG Metric Container,
but I'm not sure if this option can be included in DIOs and DAOs, or
only in DIOs. According to errata 5160 of RFC6560 is only in DIOs.

Is there any important reason to not send them in the DAOs as well = (at
least in the non-storing mode)?

If this is not possible, is there any other way within RPL to deliver
this information to the DAGroot?

Otherwise, I only only possibilities:
- Send the rank values from the application layer (which is not = very 
convenient since that would require access to the RPL sublayer)
- Through sniffer nodes that would get DIO packets in the network.
(however this would require distributing additional nodes all over = the
network)

Am I missing something? Any idea?

Thank you and kind regards,
Esteban



--
Esteban Municio

IDLab - Dept. Mathematics and Computer Science 

University of Antwerp - imec

Middelheimlaan 1 , 2020 Antwerp, Belgium 

Office M.G.322 


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


_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

= --Apple-Mail=_13ECF370-4271-4CD0-A26A-BEDB242C50FF-- From nobody Mon Feb 19 01:15:02 2018 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 6D6E31270FC for ; Mon, 19 Feb 2018 01:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IiZULDMMSQeZ for ; Mon, 19 Feb 2018 01:15:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B505127058 for ; Mon, 19 Feb 2018 01:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2718; q=dns/txt; s=iport; t=1519031700; x=1520241300; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c6/BrGUq+oMI6c0vM49HobR1lbExD9xT6VPDwk0skzw=; b=YfK3xtyjmSp4TlHgOpFClpKk2XsDKKETHBeh2KdyUVhYkyetubcJ1INE 80ba4kU/g7/IWiw40nJK8qu/9fBolIldrRgc6btiXD7fVZngyi8fXAPuz Hy/R2KRsZOwWu4Svh+aGusCECxAhHxwdBCXA7o4JAyXtz6s6tBFhA5X9A A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAA9lYpa/40NJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAog2eKJY4DggKBF5ZJghYKGAuFGAIagjVUGAECAQE?= =?us-ascii?q?BAQEBAmsohSQBAQMBAQEhEToQCQICAQgaAiYCAgIUEQsVEAIEE4oaCBCqYYI?= =?us-ascii?q?nhQGDcoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQqDfIIogVeCEYJPNoM?= =?us-ascii?q?wAQGBcYMXMYI0BaQ1CQKMKolelEeXcgIRGQGBOwEfOYFRcBU6KgGCGIR2eI5?= =?us-ascii?q?SAQEB?= X-IronPort-AV: E=Sophos;i="5.46,534,1511827200"; d="scan'208";a="347175923" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 09:14:39 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1J9EdF3015935 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Feb 2018 09:14:39 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 03:14:38 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 03:14:38 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Obtaining ranks at the DAGroot Thread-Index: AQHTp1xIYHjFv3lTjkutt4iFOIqsXqOrdWoC Date: Mon, 19 Feb 2018 09:14:38 +0000 Message-ID: <33B50D4F-B98A-416D-B6A6-09A1BA680979@cisco.com> References: <1518809265.1358.3.camel@uantwerpen.be> In-Reply-To: <1518809265.1358.3.camel@uantwerpen.be> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 09:15:01 -0000 SGVsbG8gRXN0ZWJhbg0KDQpSUEwgZG9lcyBub3QgdHJhbnNwb3J0IHRoZSBSYW5rIHRvIHRoZSBy b290LiBXZSBhY3R1YWxseSBkZXNpZ25lZCB0byBzYXZlIHRoZSBjb3N0IG9mIGRvaW5nIHRoYXQg KGFuZCBtYWludGFpbmluZyBpdCBhZnRlcndhcmRzKS4NCg0KUlBMIGFzc3VtZXMgdGhhdCB0aGUg bGlua3MgYXJlIHN5bW1ldHJpY2FsIGVub3VnaCBzbyByb3V0aW5nIGRvd253YXJkcyBjYW4gZm9s bG93IHRoZSB0YXJnZXTigJlzIHN1YmRhZy4gVGhhdCBzdWJkYWcgaXMgd2l0aGluIHRoZSByb290 4oCZcyBET0RBRyBidXQgZGlyZWN0ZWQgdG8gdGhlIHRhcmdldCBzbyB0aGVyZSBpcyBubyBuZWVk IG9mIGEgUmFuayB0byBidWlsZCBpdC4NCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCj4gTGUgMTYg ZsOpdnIuIDIwMTggw6AgMjA6MjgsIEVzdGViYW4gTXVuaWNpbyA8ZXN0ZWJhbi5tdW5pY2lvQHVh bnR3ZXJwZW4uYmU+IGEgw6ljcml0IDoNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkgdGhpbmsgdGhp cyBoYXMgYmVlbiBhbHJlYWR5IGRpc2N1c3NlZCwgYnV0IEkgZG9uJ3QgdGhpbmsgSSB0b3RhbGx5 DQo+IHVuZGVyc3RhbmQgaXQuDQo+IA0KPiBJcyB0aGVyZSBhbnkgd2F5IHRvIG9idGFpbiB0aGUg cmFuayBvZiB0aGUgbm9kZXMgYXQgdGhlIERBR3Jvb3Q/IChlLmcuDQo+IGluIG9yZGVyIHRvIG1v bml0b3IgdGhlIG5ldHdvcmspDQo+IA0KPiBPbmUgcG9zc2libGUgaWRlYSBpcyBvYnRhaW4gaXQg dGhyb3VnaCB0aGUgRVRYIG9mIHRoZSBsaW5rcy4NCj4gDQo+IEFwcGFyZW50bHksIHNvbWUgbWV0 cmljcyBjYW4gYmUgc2VudCBpbiB0aGUgaW4gREFHIE1ldHJpYyBDb250YWluZXIsDQo+IGJ1dCBJ J20gbm90IHN1cmUgaWYgdGhpcyBvcHRpb24gY2FuIGJlIGluY2x1ZGVkIGluIERJT3MgYW5kIERB T3MsIG9yDQo+IG9ubHkgaW4gRElPcy4gQWNjb3JkaW5nIHRvIGVycmF0YSA1MTYwIG9mIFJGQzY1 NjAgaXMgb25seSBpbiBESU9zLg0KPiANCj4gSXMgdGhlcmUgYW55IGltcG9ydGFudCByZWFzb24g dG8gbm90IHNlbmQgdGhlbSBpbiB0aGUgREFPcyBhcyB3ZWxsIChhdA0KPiBsZWFzdCBpbiB0aGUg bm9uLXN0b3JpbmcgbW9kZSk/DQo+IA0KPiBJZiB0aGlzIGlzIG5vdCBwb3NzaWJsZSwgaXMgdGhl cmUgYW55IG90aGVyIHdheSB3aXRoaW4gUlBMIHRvIGRlbGl2ZXINCj4gdGhpcyBpbmZvcm1hdGlv biB0byB0aGUgREFHcm9vdD8NCj4gDQo+IE90aGVyd2lzZSwgSSBvbmx5IG9ubHkgcG9zc2liaWxp dGllczoNCj4gLSBTZW5kIHRoZSByYW5rIHZhbHVlcyBmcm9tIHRoZSBhcHBsaWNhdGlvbiBsYXll ciAod2hpY2ggaXMgbm90IHZlcnkgDQo+IGNvbnZlbmllbnQgc2luY2UgdGhhdCB3b3VsZCByZXF1 aXJlIGFjY2VzcyB0byB0aGUgUlBMIHN1YmxheWVyKQ0KPiAtIFRocm91Z2ggc25pZmZlciBub2Rl cyB0aGF0IHdvdWxkIGdldCBESU8gcGFja2V0cyBpbiB0aGUgbmV0d29yay4NCj4gKGhvd2V2ZXIg dGhpcyB3b3VsZCByZXF1aXJlIGRpc3RyaWJ1dGluZyBhZGRpdGlvbmFsIG5vZGVzIGFsbCBvdmVy IHRoZQ0KPiBuZXR3b3JrKQ0KPiANCj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gQW55IGlkZWE/ DQo+IA0KPiBUaGFuayB5b3UgYW5kIGtpbmQgcmVnYXJkcywNCj4gRXN0ZWJhbiANCj4gDQo+IA0K PiANCj4gLS0gDQo+IEVzdGViYW4gTXVuaWNpbw0KPiANCj4gSURMYWIgLSBEZXB0LiBNYXRoZW1h dGljcyBhbmQgQ29tcHV0ZXIgU2NpZW5jZSANCj4gDQo+IFVuaXZlcnNpdHkgb2YgQW50d2VycCAt IGltZWMNCj4gDQo+IE1pZGRlbGhlaW1sYWFuIDEgLCAyMDIwIEFudHdlcnAsIEJlbGdpdW0gDQo+ IA0KPiBPZmZpY2UgTS5HLjMyMiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Mon Feb 19 01:37:32 2018 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 3ACAC1271DF for ; Mon, 19 Feb 2018 01:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 a6_glAdZ6_cR for ; Mon, 19 Feb 2018 01:37:29 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0ED012706D for ; Mon, 19 Feb 2018 01:37:28 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id x21so13747703wmh.0 for ; Mon, 19 Feb 2018 01:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k+E6se2G/BVMDjxech/fNASUmrn8BJO9bYpwfq/BB3M=; b=VSRbA8rPpChTrWyKV5yaZfepkWQK7JTzUwG4wd3vHCWQpHeM9DQ2j9DDnHJ4kSj2Wu UF/cue83mSlImq45EvPRVmT0Yf26Otm6PDm+PGMXiwjMWkEN9KkhO3V2Hyj/cFwgf2fw DopRBRSFAgXTY39yF8E3Jf8mz/kdfEyZji0W/ez0sVRazNq21yxObQoeCBUuWNnZNidw 49l210sqMwY/WCOGfDUwyaqh0QRvWhBDUG5VDgE9Xr96NgPBF2LfA078lg48qfSQgsfb i1CPCUZrc2AEkmJgyJLB8RopWymYEpPYeYSP0clft2nDgnBvhhAgfFpjnTLtYaw68IiM 6THg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k+E6se2G/BVMDjxech/fNASUmrn8BJO9bYpwfq/BB3M=; b=ZV4c28jAaKOTTGilEuwb/IxsCi00korUMY+UZflV7FzU7I6WXaphwVn04Jrm7DYA+n DmkP2dmIp5LtTNzWPEbR6onQjSZHYu0Rychxusq+vxO/LE6pgU+Q1H8jm9K/wJL9zK17 RPc9lmlkTJ0DtHLRqCCuEA2ZhOfkUmYxS8O6JDVPYWPxNRKFuFjAmkFalqIFIRCI3WGa sOioD9/WmlxCb2zbGE3/nY7jw+jA58T6ZETt4cstFbFAGwiIxS7Tn5TIwc/TSPrqyPSS jUx0wS0O3CFUdct4MPfUer60wf3xvniEfZD20PrfHmyYlN8AIdq2OZLHX+Q0jSuSvLr4 71Ig== X-Gm-Message-State: APf1xPBHBS5ld7WHL0BZfVCh3WjamJd/hULoo+hPhksNqJZ/rZLpKkzX KsZSQCkdBFDRpF1k8jAnRO/YjJkxmJ5uN8Mbe/M= X-Google-Smtp-Source: AH8x227gTtS3A/HCTvhOETso0zKhtqs4VW+9Pa3g8SoNGZAV8BZ+GvdhGD8hyPdYsTj47TtGY5vzOL2cY6SiuwsPe5o= X-Received: by 10.80.220.206 with SMTP id v14mr18837324edk.196.1519033046869; Mon, 19 Feb 2018 01:37:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.205.77 with HTTP; Mon, 19 Feb 2018 01:37:26 -0800 (PST) In-Reply-To: References: <1518809265.1358.3.camel@uantwerpen.be> From: Rahul Jadhav Date: Mon, 19 Feb 2018 15:07:26 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403043e6ff0292c5605658d7129" Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 09:37:31 -0000 --f403043e6ff0292c5605658d7129 Content-Type: text/plain; charset="UTF-8" Please find resp inline [RJ]. Regards, Rahul On 19 February 2018 at 14:33, Georgios Z. Papadopoulos < georgios.papadopoulos@imt-atlantique.fr> wrote: > Rahul, > > A minor question: > You do this once the RPL DODAG is constructed? > [RJ] This can be done while the DODAG formation is in progress ... so essentially you get a view of nodes gradually connecting in the network. > I assume the DAOs that are transmitted are in unicast, from child to > parent? > [RJ] Yes the DAOs are unicast. > > Please correct me, if I misunderstood. > > Cheers, > Georgios > > On Feb 19, 2018, at 04:29, Rahul Jadhav wrote: > > Hello Esteban, > > We had a similar requirement i.e. the root should be able to monitor the > connectivity of the entire DODAG. > > We achieved it by using the target-parent information which is sent in the > DAO. From this information you can form the complete DAG at the root. > > Is there any specific thing that is achieved by sending ETX/Rank ? i.e. if > all you want is to monitor the DAG formation at the root then this > information should work. > Also even though parent-info is not 'usually' sent in the DAO in case of > storing mode, we still ended up sending it in order to achieve this > monitoring in storing mode as well. I dont think 6550 restricts sending > parent info in DAO in storing mode. > > Regards, > Rahul > > > > On 17 February 2018 at 00:57, Esteban Municio < > esteban.municio@uantwerpen.be> wrote: > >> Hi all, >> >> I think this has been already discussed, but I don't think I totally >> understand it. >> >> Is there any way to obtain the rank of the nodes at the DAGroot? (e.g. >> in order to monitor the network) >> >> One possible idea is obtain it through the ETX of the links. >> >> Apparently, some metrics can be sent in the in DAG Metric Container, >> but I'm not sure if this option can be included in DIOs and DAOs, or >> only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. >> >> Is there any important reason to not send them in the DAOs as well (at >> least in the non-storing mode)? >> >> If this is not possible, is there any other way within RPL to deliver >> this information to the DAGroot? >> >> Otherwise, I only only possibilities: >> - Send the rank values from the application layer (which is not very >> convenient since that would require access to the RPL sublayer) >> - Through sniffer nodes that would get DIO packets in the network. >> (however this would require distributing additional nodes all over the >> network) >> >> Am I missing something? Any idea? >> >> Thank you and kind regards, >> Esteban >> >> >> >> -- >> Esteban Municio >> >> IDLab - Dept. Mathematics and Computer Science >> >> University of Antwerp - imec >> >> Middelheimlaan 1 , 2020 Antwerp, Belgium >> >> Office M.G.322 >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --f403043e6ff0292c5605658d7129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find resp inline [RJ].

Regards,<= /div>
Rahul

On 19 February 2018 at 14:33, Georgios Z. Papadopoulos = <georgios.papadopoulos@imt-atlantique.fr> wrote:
Rahul,
<= br>
A minor question:
You do this once the RPL DODAG is= constructed?
=C2=A0
[RJ] This can b= e done while the DODAG formation is in progress ... so essentially you get = a view of nodes gradually connecting in the network.
=C2=A0
=
I a= ssume the DAOs that are transmitted are in unicast, from child to parent?

[RJ] Yes the DAOs are unicast.= =C2=A0

Please correct me, if I misunderstood.
Cheers,
Georgios
On Feb 19, 2018, at 04:29, Rahul Jadh= av <rahul.ietf= @gmail.com> wrote:

Hello Esteban,

W= e had a similar requirement i.e. the root should be able to monitor the con= nectivity of the entire DODAG.

We achieved it by u= sing the target-parent information which is sent in the DAO. From this info= rmation you can form the complete DAG at the root.=C2=A0

Is there any specific thing that is achieved by sending ETX/Rank ? i= .e. if all you want is to monitor the DAG formation at the root then this i= nformation should work.
Also even though parent-info is not '= usually' sent in the DAO in case of storing mode, we still ended up sen= ding it in order to achieve this monitoring in storing mode as well. I dont= think 6550 restricts sending parent info in DAO in storing mode.

Regards,
Rahul



On 17 Febr= uary 2018 at 00:57, Esteban Municio <esteban.municio@uantwerpe= n.be> wrote:
Hi all,<= br>
I think this has been already discussed, but I don't think I totally understand it.

Is there any way to obtain the rank of the nodes at the DAGroot? (e.g.
in order to monitor the network)

One possible idea is obtain it through the ETX of the links.

Apparently, some metrics can be sent in the in DAG Metric Container,
but I'm not sure if this option can be included in DIOs and DAOs, or only in DIOs. According to errata 5160 of RFC6560 is only in DIOs.

Is there any important reason to not send them in the DAOs as well (at
least in the non-storing mode)?

If this is not possible, is there any other way within RPL to deliver
this information to the DAGroot?

Otherwise, I only only possibilities:
- Send the rank values from the application layer (which is not very=C2=A0<= br> convenient since that would require access to the RPL sublayer)
- Through sniffer nodes that would get DIO packets in the network.
(however this would require distributing additional nodes all over the
network)

Am I missing something? Any idea?

Thank you and kind regards,
Esteban



--
Esteban Municio

IDLab - Dept. Mathematics and Computer Science=C2=A0

University of Antwerp - imec

Middelheimlaan 1 , 2020 Antwerp, Belgium=C2=A0

Office M.G.322=C2=A0


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


_______________________________________________
Roll mailing listRoll@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/roll


____________________________________= ___________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


--f403043e6ff0292c5605658d7129-- From nobody Mon Feb 19 08:20:26 2018 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 77C69127909 for ; Mon, 19 Feb 2018 08:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zpM0_D5BPPkT for ; Mon, 19 Feb 2018 08:20:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFA91205F0 for ; Mon, 19 Feb 2018 08:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3391; q=dns/txt; s=iport; t=1519057221; x=1520266821; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RmpmahdI99RmAWUj2VQgjBJW9UjO0CvInMcjV385sJs=; b=GPP7LzsMJMErJm4gVQW/VWM1i0T7W2jNdPApkLrHc7UOYoThCN2quwW+ Np9XkeCTQD8dbh7/jg8otQ2uSjges1v9DSjfNHI/IyBeG4DalNcJzxZvM 9z40iKAIugCFHT/uMPlpW28Puyyaw2EBuXXUR88y1XdsC7jMzXfLlVeXN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAADC+Ipa/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMYFWKAqOAo4EggKBF5ZJghYKggGDOgKCW1QYAQIBAQEBAQE?= =?us-ascii?q?CayiFIwEBAQMBgQUEAgEIEQEDAQEBJwcyFAMGCAIEEwiKEgi1Z4h5ghMBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhQuCKIFXgWiDLoUHhhgFkx+RFgkClX+UUJdyAhE?= =?us-ascii?q?ZAYE7AR85gVFwFYJ9hHZ4jFqBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,535,1511827200"; d="scan'208";a="356047228" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 16:20:20 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1JGKKVK024457 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Feb 2018 16:20:20 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 10:20:19 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 10:20:20 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Join preference calculation Thread-Index: AQHTqSWICiUi7+UVrkS19/JBmiRjr6OrZ6RQ Date: Mon, 19 Feb 2018 16:20:13 +0000 Deferred-Delivery: Mon, 19 Feb 2018 16:19:36 +0000 Message-ID: <25cca3919d684a11bce04a244c01a448@XCH-RCD-001.cisco.com> References: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> <12383.1519005650@obiwan.sandelman.ca> In-Reply-To: <12383.1519005650@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 16:20:25 -0000 Hello Michael This will certainly be an interesting discussion at ROLL. I do not really m= atch my assumptions with the one you state below so we'll need to resync. My assumption is that there is a concept of domain where a device can join = and keep getting connectivity using credentials that it obtains once at joi= n time for a long period.=20 A network (which is typically a subnet identified with a /64) should be inc= luded in a domain, and a DODAG is included in a network. 6lo and 6TiSCH have the concept of a backbone router that federates multipl= e DODAGs in one to form a subnet; this implies that a PAN-ID is the same an= d that the short address namespace is common, at least if nodes derive thei= r IPv6 address from section "6. Stateless Address Autoconfiguration" of RF= C 4944. Take care, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: lundi 19 f=E9vrier 2018 03:01 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Join preference calculation {this may be a duplicate, but I don't see it in the archive} Pascal Thubert (pthubert) wrote: > From an architecture point of view, RPL either ignores or mixes the > preference for the network, the DODAG in the network, the Join Proxy = =3D in > the DODAG at join time, the parent in the DODAG once joined, and then > the next hop at forwarding time, all in one concept of Rank. It seems that you are making the following assumptions, which I think are worth making explicit. I further suggest that this gets written down into= =3D a requirements-like document before 101. 1) that the different DODAGs have different L2-network-wide-keys. That per-host-pair (802.15.9 mediated) keying never occurs. 2) that the different DODAGs have overlapping 2-byte short addresses. 3) that even after the initial enrollment, that the nodes can either reuse their PSKs (in the case of 6tisch minimal security) again, or that they have been provisioned with different PSKs for each PANID. 4) that the enrollment process does *not* result in a different credential (an LDevID for instance), that could be used to provide keying for all DODAGs. 5) it's unclear to me in a 6tisch context, if the different DODAGs/PANs have a coordinated schedule or not. To me, it seems like enrollment should occur once. These different DODAGs which might be on different PANIDs, should have diff= erent RPL instanceIDs. Perhaps it's enough to have different DODAGIDs. > I see that defining all the above belongs to ROLL and that 6TiSCH is > concerned with expressing requirements and mapping the information ba= =3D ck > into IEEE std 802.15.4 beacons. All in all, 6TiSCH recommends not to > beacon till L3 is up and running (including RPL) and then to set the > 802.15.4 Join preference in beacons with the Rank. Michael's draft > indicates that this is not enough and propose a 4 tuple: netID, > DODAG_Rank, JP-Rank, and RPL Rank. This will probably require a new > IE. Do you mean an IE other than the one that the 6tisch-enhanced-beacon propos= =3D es to create? -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Feb 19 08:39:30 2018 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 9A415126CD8 for ; Mon, 19 Feb 2018 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B38TGKLTHRvh for ; Mon, 19 Feb 2018 08:39:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F4E1241F8 for ; Mon, 19 Feb 2018 08:39:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 957DA20091 for ; Mon, 19 Feb 2018 11:46:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 031EB80C42 for ; Mon, 19 Feb 2018 11:39:26 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <25cca3919d684a11bce04a244c01a448@XCH-RCD-001.cisco.com> References: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> <12383.1519005650@obiwan.sandelman.ca> <25cca3919d684a11bce04a244c01a448@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 16:39:30 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > This will certainly be an interesting discussion at ROLL. I do not > really match my assumptions with the one you state below so we'll need > to resync. That's why I ask to write them down :-) I'm stating what I heard as assumptions, not that I agree with them all. > My assumption is that there is a concept of domain where a device can > join and keep getting connectivity using credentials that it obtains > once at join time for a long period. That's also been my assumption which to me, means that it does not matter which DODAG one enrolls through, as long as it's got bandwidth to do the en= roll process. But I hear others saying that they want to pick the network in adv= ance. > A network (which is typically a subnet identified with a /64) should = be > included in a domain, and a DODAG is included in a network. I think we agree: Domain > Network(/64) > DODAG. but maybe we need to write this down. Perhaps there is a section of backbo= ne router that explains that should get a WG Consensus call in ROLL. > 6lo and 6TiSCH have the concept of a backbone router that federates > multiple DODAGs in one to form a subnet; this implies that a PAN-ID is > the same and that the short address namespace is common, at least if > nodes derive their IPv6 address from section "6. Stateless Address > Autoconfiguration" of RFC 4944. Again, let's write this down. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqK/b0ACgkQgItw+93Q 3WUHzAf8DlF1s4JG1gIPlwfOvZ/9sioMCzShGH+Z1KbXiIFDribMcXPyW6YohhAk 1Cv3/i6Wjx7YF46uNFQO0SbEjUARX7Q7u0Ou47GSRm02WdDDcjGaVYYiBJKthWlK Zw8dmTPQ3M3HjSJ/w9V9cTkR2FNS2v5CkRMw3xvIxfH2PL58pFy0U3D1+ZRs2AuI sgIoxRmXkVXVq9+s78uTyZNj4Aa0h7O8LTnhHc/LH8LwFuaNE1HzVhkuHSaaa/KI STr75AaGe/61Ot5VGwcrTjoPEOLfRowNFnfrDSG4N9UMSd6oJD8Huxg3s9ElWsBO 3j4yRUEmR6qDeEUMw9SnWuVNM8Xm9w== =XriU -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 19 10:16:07 2018 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 5EEAE120721 for ; Mon, 19 Feb 2018 10:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uantwerpen.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 tB_8GOPVr1z7 for ; Mon, 19 Feb 2018 10:16:02 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CE61201F2 for ; Mon, 19 Feb 2018 10:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uantwerpen.onmicrosoft.com; s=selector1-uantwerpen-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NsenQLWdNeZxezCUOussrQ+Y3f5KgAiE/bDKFHFGHo8=; b=maKAUgwAP5XvA9itd4fGs7o00BH6y6bRNaY2P3BmJ1eyG9od8vPqPLpdC28tyxatCk637pAjVbC9yTpK9bjUjjWkQLfRzP52mkKIpWbfu4OOM3V7JKoSdey58tmmN4yu0eSahD4JEWl/4Yt4hrFk4x/SoB9DzigI8OG5Js7utyc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Esteban.Municio@uantwerpen.be; Received: from taurus (2001:6a8:500:e076:c4e3:9cc2:77e2:d467) by HE1PR0501MB2444.eurprd05.prod.outlook.com (2603:10a6:3:6c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Mon, 19 Feb 2018 18:15:58 +0000 Message-ID: <1519064154.14739.4.camel@uantwerpen.be> From: Esteban Municio To: roll@ietf.org Date: Mon, 19 Feb 2018 19:15:54 +0100 Organization: UAntwerpen - imec Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-Z4X4NgRPcX52esDK30cW" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 X-Originating-IP: [2001:6a8:500:e076:c4e3:9cc2:77e2:d467] X-ClientProxiedBy: AM3PR05CA0099.eurprd05.prod.outlook.com (2603:10a6:207:1::25) To HE1PR0501MB2444.eurprd05.prod.outlook.com (2603:10a6:3:6c::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2ae524bb-4656-49f3-cbd7-08d577c4d378 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR0501MB2444; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2444; 3:lW6TVBJvZkpLyFqoE89tF6A6g6fg1xEn4WdoJoroDqq4b+x2BLOD96r5NvkMx9eRcnz77TmlbtMJJfF2B9sxpie7AfLMEACubScbKrMLUanDZhuFJoKzKedLQBtei6yTPa154xeJfbmWBg43MJSFa04loxKcVr+oPoeZuA4Qwfua1zknFf8WxgNWSha+ww2WLwsndvU/qREDiPgiErmU0fC9pz6ppjIQ1YEtdYQ4E/WXfS3a9eYIJVA7E7Cb/AQE; 25:pAXMAIzsQx3kTyTIESKj983YPHO2k+mJLLxksoadrOlMPZVfMBJ578piBLCbm3avLglwO1aRRM1TzN6uHTCrXfOkuPE0BGCLmbA+33hipTYCvhcnuOJPXuYBhStbzxMhruALYWSfsw37VL7cqQBbr0OA61WVYHA5d/15uQ1V//xeTS7qc3FMV+Mra9/ia5p25XS0O0dJWolVXAhE3W+dqQV2usuDFt6LKePH9z49ui+PUsPkSHfWycKvSGjIc7NvVGUsDFHPLW6OyBOPLMA+uiOwbwA3+OMAEeOh5wg6TZsOFcO2I8oaX1KjGcQ/xIlZZmtLWFhGV8HV2hBxthd7IA==; 31:FMbh8IwmTpNSe8mfmFBe0ZxN6e3jjijjRQEVLZBJkv/YQ2WqYTEnziprcl9ZxmGb0niUSNATpklLg4kL/U8gHvE8U8SyKV3FNS/7pu0l4hm3au2wPgy0KGc2wVXWK6LBDgAgttuyZ4HbkewaXGWiuF6XAC9jeCUwg8mcvndXK5Saf1q1UMOjN0jp8ACz0suqLiSiR0FC9JMOCI+BDSEUrS8FHUNn0Id4f54x29VISZw= X-MS-TrafficTypeDiagnostic: HE1PR0501MB2444: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2444; 20:cgCSiKlRZurY+0wSTUEPVXZpFBZi2QcXDCd2c1wHzYqbY9PjNW1Sw6u5Yk1U4E28AEW5oGY220sH3rgNT005Zp0f7/wVYJ9XTNDCGSoIzL1quHzZzs+ZhxVeGuxSUSmP11+2hrgCfrcGO7rxREq5E1yNywExBpprQje6+ZA/reU=; 4:DLP5rKQ68Nl5+7rsLprsGJ0qNR1n4asewQffeS04mePgiGzXEOSzX3DbU1sV2i33W8AoexL4Zaj4DHZlwjq/wS8EyeXnc4KYEJv8KJL1zUWHNdDppNUAeaH4mX4LSpaQIRM331Nwo5YnCJJi5usOz4JU0XG6OGjlt16RHnA8jeXtn/6zc+1ww4AQRxFgF/18j+kAVjLq7Tyia/mMsSd7Of9YzjykQxzYR1P5wbE9Fwhw1XycFYdXyg0RBMa9t0c2usGu5RoQn1ZXw+FM6vuP5g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0501MB2444; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2444; X-Forefront-PRVS: 0588B2BD96 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39380400002)(39850400004)(376002)(199004)(189003)(53754006)(2351001)(16586007)(966005)(478600001)(2361001)(106356001)(270700001)(84326002)(786003)(6246003)(86362001)(74482002)(6116002)(68736007)(72206003)(21480400003)(5660300001)(103116003)(6486002)(53936002)(52116002)(25786009)(6496006)(52396003)(36916002)(2906002)(6666003)(16526019)(186003)(33964004)(229853002)(105586002)(386003)(59450400001)(8676002)(6306002)(36756003)(81166006)(50226002)(6916009)(97736004)(81156014)(316002)(7736002)(305945005)(8936002)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2444; H:taurus; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: uantwerpen.be does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR0501MB2444; 23:KXV3bSIt72I2kpxp0RNPS2/G4UEkQB7MiIPBqq0?= =?us-ascii?Q?VJKOUzITYfCwbf4arDvRssAvRlHMLyD972inevwPAcTHugOedpJXF3AcLZTi?= =?us-ascii?Q?pszrEYBd03GKbXhUtR53Tz+Ut9fzNsnj07CrGdMsYj4xvHZeZ0/qWMpD4tUe?= =?us-ascii?Q?L6PsdrFg7Cn+UYF/sJuoBeQxzgDAnn3O8s96SVOg5bdmpvjBoumb8YFv54lX?= =?us-ascii?Q?9jQNGJhWnX+5yNPKvPb9C6DQ/Kx5PrnNVwEKGFoxMXrkLLc0Cw399+4rTvpp?= =?us-ascii?Q?AXwOrti0sBJIct2qxrPD98pPYxxvwcdEBXWPu3dzKHkBlYLa9eK9okIS3zyJ?= =?us-ascii?Q?JGSlaZ9i4xgC7g3hTErYM+k1LnvnSoISDmOfBd5wCahtv0DhqdR/bors/4pv?= =?us-ascii?Q?f2FqpF+cDxhoLikNnAJupxwAHWQd3YCh690abggLrasIVuZ64hh+Qv4KY/KX?= =?us-ascii?Q?c+UWjSSXwAA3tru6ET/ymFRELZcwmZArvxVM+JQBuCNjIdgOA1XIrD2H9Fu7?= =?us-ascii?Q?o7feFGpU7FYvL9XCXWD9X3ecsBd82iM9VyB11oX4tCBWugY14rpLpXrWQ1kB?= =?us-ascii?Q?IarBebm8iZLfrZzTcyFtinlnyEW3uExXeb+VqLDHVGAplbkO9lpqlhglGk0t?= =?us-ascii?Q?OHrdOP+UIanK27IWOGud44n9x7zYlysqoHOlXyd+s9XpmozGwWJMWy00v5e/?= =?us-ascii?Q?t6XDSkKyKI2hWt18R5amy4g7/cfrJ7OP9iUbE9Y6Siybg9XCAMca7SXyBbq1?= =?us-ascii?Q?wjC7DoXtOzGyuK6nAskeZjmswbbNlxiJkQnm0osOb4eAX386XF2FOxSzpFdS?= =?us-ascii?Q?YJ+84/t9OTSrWbtkSjF1I1AcVw85ewAm6ottMAofXOxeZmxfkJem2SYJJjry?= =?us-ascii?Q?FFNexQYLPuSTrskBtlhNLCq7MXrkBArUSYNUAhUN2cwgsAXVQsHpKY/L4J/E?= =?us-ascii?Q?qXhW7CpCQL3qUUWvwZn+OMUQ3A6wGdX/alkj0lwL5rW+Yu+4RgqkEoMVKyaV?= =?us-ascii?Q?bjYPnAx49F7Wl63br8/eVNticboCSDUFm+UM4uh0fkEq084lw9qhC7RVIMV2?= =?us-ascii?Q?98SQRCZDPPQ2RY1HJpzKvgqgT2fmvFwg1Oy/X+NId0EdFGXwRHUTpfYz/a5E?= =?us-ascii?Q?SZ+e3ervboh5OY6G3zs23OAA3d9avpTZtSrwzezpZVq0Uy3AZiCQA6nWzAR9?= =?us-ascii?Q?40q/FxaFd2VfOSxyecYA5oeugN17Hf26s4PyiL0tv0FId/1/WZSbBeD/tRA6?= =?us-ascii?Q?rscorx+4ql+alP3B6CUZWUVJxHyqAQKmsmjne8CG4?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2444; 6:NhOiORcSEVHNHDCMXBNDZAgIEIZbsrCh6v2u7AEV0e1IE3WzM3i9XqjKaKWWguB5Rt+0mFH3YJgGqvpNCfZ/ayp5n3L2G5zjNnCN8sBGWGiPxOCwP4L5rUHodc6rQXQ3SqfvNUUeWF8qDSG2Xp2SA7uxziXmVl1+59cb8cNxzwUP7XuYsoKkbS/u0rV048Ox2Xf7vxqLxJE1TapMIdD5H3l7MN6/ihUb2uOHtT+zf8lFoOKDckW3HMq3jZBZqOUjS+ZHNpuKU/pFAQLK5DjNgkI09n0Zll9wZCM0kZ1ADs8Ki6GSboVqjBcM/XWE6MdjdipEtXrn3vHg6bWDnrpv7q1+/Qxyf7aty7Y99MGu8MA=; 5:m0zQyTQgJ52l8q88HuvEudVQpi034X/8GPN9XHc5S6QKzQ16mIzw0jk9tvqC7mWGL8Z2zqHUsW/NDLAmeh0PQioarPprrUwswHQNEYape49ZYIbp3iZxnwIUl92E1Cx3phWedxhhNXZvBZRqC5wD0kLEfoaXfJSsOGbVOpA//NY=; 24:QKvGH38fJsVBTNA9puWC0QU8baBR1TgBja8aT/udlY5Lec9mlV4mnGHjRKozgk6YkKzN7C+PCO4LpIs9EJ2AuWVAfmYwlGfq3GxV523uw8k=; 7:IyJltxxCPcVDRVpejIQcrAS+9WsACo44z+0KCtIiv7Ea6DNjGYwZq2a8hrj8DUgFOg9bXHiVNwnUnrlItLUVhjwlsqAEW/tdkkIS2YUN086jO6vD88mTPXcX0MuBuGZv4ufovJW7B41XZDsoCpKTec1w5SPalq1O2baOzF9IcUO4ab+v8NtMFuJTX5FCpq2q3lFqIJjwFvXNijKh5AD42Sl4dlleIHQ+kCb4hGDAazzBlws2z2NYdHSCLk3jCR2L SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: uantwerpen.be X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2018 18:15:58.6591 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2ae524bb-4656-49f3-cbd7-08d577c4d378 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 792e08fb-2d54-4a8e-af72-202548136ef6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2444 Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 18:16:05 -0000 --=-Z4X4NgRPcX52esDK30cW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, Rahul, Yes, that was actually one of my doubts: if a node can send uplink through one path and receive downlink through a different path using the same DODAG instance. If links are assumed symmetric that means that is not possible. @Rahul, yes, the idea was to monitor the rank in the nodes (e.g. for visualize it in a graph), and maybe play a bit with it. For only the DAG, indeed the target-parent option in the DAOs is enough. Thanks and kind regards, Esteban > Hello Esteban >=20 > RPL does not transport the Rank to the root. We actually designed to > save the cost of doing that (and maintaining it afterwards). >=20 > RPL assumes that the links are symmetrical enough so routing > downwards can follow the target=E2=80=99s subdag. That subdag is within t= he > root=E2=80=99s DODAG but directed to the target so there is no need of a = Rank > to build it. >=20 > Regards, >=20 > Pascal >=20 > > Le 16 f=C3=A9vr. 2018 =C3=A0 20:28, Esteban Municio en.be>; a =C3=A9crit : > >=C2=A0 > > Hi all, > >=C2=A0 > > I think this has been already discussed, but I don't think I > totally > > understand it. > >=C2=A0 > > Is there any way to obtain the rank of the nodes at the DAGroot? > (e.g. > > in order to monitor the network) > >=C2=A0 > > One possible idea is obtain it through the ETX of the links. > >=C2=A0 > > Apparently, some metrics can be sent in the in DAG Metric > Container, > > but I'm not sure if this option can be included in DIOs and DAOs, > or > > only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. > >=C2=A0 > > Is there any important reason to not send them in the DAOs as well > (at > > least in the non-storing mode)? > >=C2=A0 > > If this is not possible, is there any other way within RPL to > deliver > > this information to the DAGroot? > >=C2=A0 > > Otherwise, I only only possibilities: > > - Send the rank values from the application layer (which is not > very=C2=A0 > > convenient since that would require access to the RPL sublayer) > > - Through sniffer nodes that would get DIO packets in the network. > > (however this would require distributing additional nodes all over > the > > network) > >=C2=A0 > > Am I missing something? Any idea? > >=C2=A0 > > Thank you and kind regards, > > Esteban=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > > --=C2=A0 > > Esteban Municio > >=C2=A0 > > IDLab - Dept. Mathematics and Computer Science=C2=A0 > >=C2=A0 > > University of Antwerp - imec > >=C2=A0 > > Middelheimlaan 1 , 2020 Antwerp, Belgium=C2=A0 > >=C2=A0 > > Office M.G.322=C2=A0 > >=C2=A0 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll --=20 Esteban Municio IDLab - Dept. Mathematics and Computer Science=C2=A0 University of Antwerp - imec Middelheimlaan 1 , 2020 Antwerp, Belgium=C2=A0 Office M.G.322=C2=A0 --=-Z4X4NgRPcX52esDK30cW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEwXAVTO0Lr5fj2oZRgSPJgpHrOpwFAlqLFFoACgkQgSPJgpHr OpwKewf/Wn/vyGQhxfo16OFp4GWTvFQgAqP50lm20mJEwaxpHbL+ayTX7aDbttZi QFozBYCGGZtiJIhVT8YiJESC39NOwvkl2WNngkYJZCYjoGpQRbJJhEQjbryZL0lg 0UenedvG/7DHnB2paDi1h5NuLN7cZxSbGb9YXoFne08mRsQQ3F9DrGY2ddftSaD7 YjqDKkyZQCirr/aQWVV/XHq0H97gnMAJcKs3JMuOypiql9H+1Afa0TGzr2Yjpw4J oWX6Gqg2vskRUYN9jGi3I5bdxo1v69oetAKmYdFcPkTlmmFCJX9FeqGJ4YDaSAbO 6V/cWCM5exaMFhIY1X/aGEB+k5d76Q== =1ehd -----END PGP SIGNATURE----- --=-Z4X4NgRPcX52esDK30cW-- From nobody Mon Feb 19 10:53:03 2018 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 E4AB3126C3D for ; Mon, 19 Feb 2018 10:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-KdtSoaIOh6 for ; Mon, 19 Feb 2018 10:52:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACCF126C0F for ; Mon, 19 Feb 2018 10:52:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF48120091 for ; Mon, 19 Feb 2018 14:00:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D969680BCA for ; Mon, 19 Feb 2018 13:52:48 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <1518809265.1358.3.camel@uantwerpen.be> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 18:52:51 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Rahul Jadhav wrote: > Is there any specific thing that is achieved by sending ETX/Rank ? It's awefully good for diagnostics. We really need a mgmt interface that either lets the DAGroot query directly, or lets' the leaves send the information. But if we send it from leaf->roo= t, then we need to decide how often to do that, and this means appling trickle to it. So I prefer to have the root query this information; it's just another P2MP control flow. It would be nice to have some bit that tells the root if the new leaf is capable of the new interface. This would fit into our SMI (now YANG/NETCONF) requirements, btw. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqLHQAACgkQgItw+93Q 3WVqxAf/WivtWmktgD7vDIj1wgUijoWO42y3UghJh7gcb/b7RweQAqZyc1fMR/RR WDtzLshmEsaq2LiO6bOPj/Ra7vDKAxAMtUeuI17cN0QhR7tDLhuamwk9lFwyQMcE OQT+Wt6zXWJVIcPSXvSpb2jwbGq2JYn+JRNPNWIXDZ/DzGdulpj7zNCnkhpIibAk WEtzoHBfSJEDbBKIUykRopbgjLaFcmURdnniAwqXGjT1TEmlMfzLUBatQ4ja4s4k gExpSSZxxrgFUfLJ1XgMPRtaF0WdIyZCEnUqfJHRzcHgrF7eSwBEw+zJ3wcANISj 0p6btU45USbz62RNhNKVPkprhwmyqw== =Ynpo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 19 10:57:39 2018 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 07F3612420B for ; Mon, 19 Feb 2018 10:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nHshT0mBdH3c for ; Mon, 19 Feb 2018 10:57:37 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EAE1204DA for ; Mon, 19 Feb 2018 10:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4512; q=dns/txt; s=iport; t=1519066657; x=1520276257; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5NACGsVzKDUKcB8dqe+tHxviey1pBcXaG4QhDFv4ERI=; b=N4dyDSC9xWxGDJunJ/o2JJepfzEZ7/xXAaQWFoeQW55Qm11IOpPavU13 fo/Wk/A611yk6AiSMHtkSAhEtHrTuzIFWzdZK2wuQ0DbTRYJ/cBQC+QE4 HJ+dWstm1JwNrHjekE69cIcyB1QVVSQlAkHWhZT09RW1OvKqVF9Ato59Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAAAOHYta/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAog2eKJY4EgVsngReWSYIWChgLhRgCGoJBVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUkAQEDAQEBIRE6EAkCAgEIGgImAgICFBELFRACBBOKGggQtgmCJ4UBg?= =?us-ascii?q?3iCEwEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQqDfIIogVeCEQyCQzaDMAEBA4F?= =?us-ascii?q?ugxcxgjQFpDUJAogihAiJXpRHl3ICERkBgTsBHzmBUXAVOioBghgJhG14jXMBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.46,536,1511827200"; d="scan'208";a="72404054" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 18:57:36 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1JIvafv032392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Feb 2018 18:57:36 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 12:57:35 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 12:57:35 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Obtaining ranks at the DAGroot Thread-Index: AQHTqa2uYHjFv3lTjkutt4iFOIqsXqOsE6fZ Date: Mon, 19 Feb 2018 18:57:35 +0000 Message-ID: <280CB2A8-5B9E-416F-9086-F9483D554827@cisco.com> References: <1519064154.14739.4.camel@uantwerpen.be> In-Reply-To: <1519064154.14739.4.camel@uantwerpen.be> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 18:57:39 -0000 SGVsbG8gRXN0ZWJhbg0KDQpGb3IgYXN5bW1ldHJpYyBsaW5rIG9uZSBjYW4gYnVpbGQgMiBET0RB R3MuIFRoZXJlIGlzIGEgZHJhZnQgSSBwdWJsaXNoZWQgc2V2ZXJhbCB5ZWFycyBhZ28gYWJvdXQg dGhhdC4uLg0KDQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQo+IExlIDE5IGbDqXZyLiAyMDE4IMOg IDE5OjE2LCBFc3RlYmFuIE11bmljaW8gPGVzdGViYW4ubXVuaWNpb0B1YW50d2VycGVuLmJlPiBh IMOpY3JpdCA6DQo+IA0KPiBIaSBQYXNjYWwsIFJhaHVsLA0KPiANCj4gWWVzLCB0aGF0IHdhcyBh Y3R1YWxseSBvbmUgb2YgbXkgZG91YnRzOiBpZiBhIG5vZGUgY2FuIHNlbmQgdXBsaW5rDQo+IHRo cm91Z2ggb25lIHBhdGggYW5kIHJlY2VpdmUgZG93bmxpbmsgdGhyb3VnaCBhIGRpZmZlcmVudCBw YXRoIHVzaW5nDQo+IHRoZSBzYW1lIERPREFHIGluc3RhbmNlLg0KPiANCj4gSWYgbGlua3MgYXJl IGFzc3VtZWQgc3ltbWV0cmljIHRoYXQgbWVhbnMgdGhhdCBpcyBub3QgcG9zc2libGUuDQo+IA0K PiANCj4gQFJhaHVsLCB5ZXMsIHRoZSBpZGVhIHdhcyB0byBtb25pdG9yIHRoZSByYW5rIGluIHRo ZSBub2RlcyAoZS5nLiBmb3INCj4gdmlzdWFsaXplIGl0IGluIGEgZ3JhcGgpLCBhbmQgbWF5YmUg cGxheSBhIGJpdCB3aXRoIGl0LiBGb3Igb25seSB0aGUNCj4gREFHLCBpbmRlZWQgdGhlIHRhcmdl dC1wYXJlbnQgb3B0aW9uIGluIHRoZSBEQU9zIGlzIGVub3VnaC4NCj4gDQo+IFRoYW5rcyBhbmQg a2luZCByZWdhcmRzLA0KPiBFc3RlYmFuDQo+IA0KPiANCj4+IEhlbGxvIEVzdGViYW4NCj4+IA0K Pj4gUlBMIGRvZXMgbm90IHRyYW5zcG9ydCB0aGUgUmFuayB0byB0aGUgcm9vdC4gV2UgYWN0dWFs bHkgZGVzaWduZWQgdG8NCj4+IHNhdmUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhhdCAoYW5kIG1haW50 YWluaW5nIGl0IGFmdGVyd2FyZHMpLg0KPj4gDQo+PiBSUEwgYXNzdW1lcyB0aGF0IHRoZSBsaW5r cyBhcmUgc3ltbWV0cmljYWwgZW5vdWdoIHNvIHJvdXRpbmcNCj4+IGRvd253YXJkcyBjYW4gZm9s bG93IHRoZSB0YXJnZXTigJlzIHN1YmRhZy4gVGhhdCBzdWJkYWcgaXMgd2l0aGluIHRoZQ0KPj4g cm9vdOKAmXMgRE9EQUcgYnV0IGRpcmVjdGVkIHRvIHRoZSB0YXJnZXQgc28gdGhlcmUgaXMgbm8g bmVlZCBvZiBhIFJhbmsNCj4+IHRvIGJ1aWxkIGl0Lg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+ PiBQYXNjYWwNCj4+IA0KPj4+IExlIDE2IGbDqXZyLiAyMDE4IMOgIDIwOjI4LCBFc3RlYmFuIE11 bmljaW8gPGVzdGViYW4ubXVuaWNpb0B1YW50d2VycA0KPj4gZW4uYmU+OyBhIMOpY3JpdCA6DQo+ Pj4gIA0KPj4+IEhpIGFsbCwNCj4+PiAgDQo+Pj4gSSB0aGluayB0aGlzIGhhcyBiZWVuIGFscmVh ZHkgZGlzY3Vzc2VkLCBidXQgSSBkb24ndCB0aGluayBJDQo+PiB0b3RhbGx5DQo+Pj4gdW5kZXJz dGFuZCBpdC4NCj4+PiAgDQo+Pj4gSXMgdGhlcmUgYW55IHdheSB0byBvYnRhaW4gdGhlIHJhbmsg b2YgdGhlIG5vZGVzIGF0IHRoZSBEQUdyb290Pw0KPj4gKGUuZy4NCj4+PiBpbiBvcmRlciB0byBt b25pdG9yIHRoZSBuZXR3b3JrKQ0KPj4+ICANCj4+PiBPbmUgcG9zc2libGUgaWRlYSBpcyBvYnRh aW4gaXQgdGhyb3VnaCB0aGUgRVRYIG9mIHRoZSBsaW5rcy4NCj4+PiAgDQo+Pj4gQXBwYXJlbnRs eSwgc29tZSBtZXRyaWNzIGNhbiBiZSBzZW50IGluIHRoZSBpbiBEQUcgTWV0cmljDQo+PiBDb250 YWluZXIsDQo+Pj4gYnV0IEknbSBub3Qgc3VyZSBpZiB0aGlzIG9wdGlvbiBjYW4gYmUgaW5jbHVk ZWQgaW4gRElPcyBhbmQgREFPcywNCj4+IG9yDQo+Pj4gb25seSBpbiBESU9zLiBBY2NvcmRpbmcg dG8gZXJyYXRhIDUxNjAgb2YgUkZDNjU2MCBpcyBvbmx5IGluIERJT3MuDQo+Pj4gIA0KPj4+IElz IHRoZXJlIGFueSBpbXBvcnRhbnQgcmVhc29uIHRvIG5vdCBzZW5kIHRoZW0gaW4gdGhlIERBT3Mg YXMgd2VsbA0KPj4gKGF0DQo+Pj4gbGVhc3QgaW4gdGhlIG5vbi1zdG9yaW5nIG1vZGUpPw0KPj4+ ICANCj4+PiBJZiB0aGlzIGlzIG5vdCBwb3NzaWJsZSwgaXMgdGhlcmUgYW55IG90aGVyIHdheSB3 aXRoaW4gUlBMIHRvDQo+PiBkZWxpdmVyDQo+Pj4gdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgREFH cm9vdD8NCj4+PiAgDQo+Pj4gT3RoZXJ3aXNlLCBJIG9ubHkgb25seSBwb3NzaWJpbGl0aWVzOg0K Pj4+IC0gU2VuZCB0aGUgcmFuayB2YWx1ZXMgZnJvbSB0aGUgYXBwbGljYXRpb24gbGF5ZXIgKHdo aWNoIGlzIG5vdA0KPj4gdmVyeSANCj4+PiBjb252ZW5pZW50IHNpbmNlIHRoYXQgd291bGQgcmVx dWlyZSBhY2Nlc3MgdG8gdGhlIFJQTCBzdWJsYXllcikNCj4+PiAtIFRocm91Z2ggc25pZmZlciBu b2RlcyB0aGF0IHdvdWxkIGdldCBESU8gcGFja2V0cyBpbiB0aGUgbmV0d29yay4NCj4+PiAoaG93 ZXZlciB0aGlzIHdvdWxkIHJlcXVpcmUgZGlzdHJpYnV0aW5nIGFkZGl0aW9uYWwgbm9kZXMgYWxs IG92ZXINCj4+IHRoZQ0KPj4+IG5ldHdvcmspDQo+Pj4gIA0KPj4+IEFtIEkgbWlzc2luZyBzb21l dGhpbmc/IEFueSBpZGVhPw0KPj4+ICANCj4+PiBUaGFuayB5b3UgYW5kIGtpbmQgcmVnYXJkcywN Cj4+PiBFc3RlYmFuIA0KPj4+ICANCj4+PiAgDQo+Pj4gIA0KPj4+IC0tIA0KPj4+IEVzdGViYW4g TXVuaWNpbw0KPj4+ICANCj4+PiBJRExhYiAtIERlcHQuIE1hdGhlbWF0aWNzIGFuZCBDb21wdXRl ciBTY2llbmNlIA0KPj4+ICANCj4+PiBVbml2ZXJzaXR5IG9mIEFudHdlcnAgLSBpbWVjDQo+Pj4g IA0KPj4+IE1pZGRlbGhlaW1sYWFuIDEgLCAyMDIwIEFudHdlcnAsIEJlbGdpdW0gDQo+Pj4gIA0K Pj4+IE9mZmljZSBNLkcuMzIyIA0KPj4+ICANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4gUm9sbEBp ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K PiANCj4gLS0gDQo+IEVzdGViYW4gTXVuaWNpbw0KPiANCj4gSURMYWIgLSBEZXB0LiBNYXRoZW1h dGljcyBhbmQgQ29tcHV0ZXIgU2NpZW5jZSANCj4gDQo+IFVuaXZlcnNpdHkgb2YgQW50d2VycCAt IGltZWMNCj4gDQo+IE1pZGRlbGhlaW1sYWFuIDEgLCAyMDIwIEFudHdlcnAsIEJlbGdpdW0gDQo+ IA0KPiBPZmZpY2UgTS5HLjMyMiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Mon Feb 19 11:01:04 2018 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 66EE6129BBF for ; Mon, 19 Feb 2018 11:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PpI3ZI1uK592 for ; Mon, 19 Feb 2018 11:00:55 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8410B124BFA for ; Mon, 19 Feb 2018 11:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1519066855; x=1520276455; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ay7DDEUs7RxVnzZKfpSwXyrLuHrmWRpIBs2wt0kK3JQ=; b=dxkR1wFhwzeK6LlqZ/jLBp/YVpnV1oxmgDwdhVxexic1nLhSnV8bCjUX b35UVZkDUrdXNMWYiLRFeC0U1cuGcFO0EbNnoY5Tf2mVfmF+RU20EEe7P NUvIpJLa0mJPzte8aLXzMninyYbbpT/vBJhRw6AjzkOR+4VW4Att3RUtx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAAAdHota/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAog2eKJY4EggKBF5ZJghYKGAuBXoM6AhqCQVQYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQMBAQEhEToQCwIBCBgCAiYCAgIlCxUQAgQTihoIELYcgieFA?= =?us-ascii?q?YN4ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg3yCKIFXgWgpgwWDMAEBhQg?= =?us-ascii?q?xgjQFpDUJApYIlEeXcgIRGQGBOwEfOYFRcBU6KgGCGIR2eI1zAQEB?= X-IronPort-AV: E=Sophos;i="5.46,536,1511827200"; d="scan'208";a="357952004" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 19:00:54 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1JJ0sNs014620 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Feb 2018 19:00:54 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 13:00:53 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 13:00:53 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Join preference calculation Thread-Index: AQHTqSWICiUi7+UVrkS19/JBmiRjr6OrZ6RQgADrDYD//8LynA== Date: Mon, 19 Feb 2018 19:00:53 +0000 Message-ID: <8C01CD50-9A61-495C-A6D9-E1C5CF0D8778@cisco.com> References: <0ec15896a326445c805c3e7d5d94c39f@XCH-RCD-001.cisco.com> <12383.1519005650@obiwan.sandelman.ca> <25cca3919d684a11bce04a244c01a448@XCH-RCD-001.cisco.com>, <12348.1519058365@obiwan.sandelman.ca> In-Reply-To: <12348.1519058365@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Join preference calculation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 19:00:57 -0000 QWdyZWUgMTAwJQ0KDQpQYXNjYWwNCg0KPiBMZSAxOSBmw6l2ci4gMjAxOCDDoCAxNzozOSwgTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IGEgw6ljcml0IDoNCj4gDQo+ IA0KPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3Rl Og0KPj4gVGhpcyB3aWxsIGNlcnRhaW5seSBiZSBhbiBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIGF0 IFJPTEwuIEkgZG8gbm90DQo+PiByZWFsbHkgbWF0Y2ggbXkgYXNzdW1wdGlvbnMgd2l0aCB0aGUg b25lIHlvdSBzdGF0ZSBiZWxvdyBzbyB3ZSdsbCBuZWVkDQo+PiB0byByZXN5bmMuDQo+IA0KPiBU aGF0J3Mgd2h5IEkgYXNrIHRvIHdyaXRlIHRoZW0gZG93biA6LSkNCj4gSSdtIHN0YXRpbmcgd2hh dCBJIGhlYXJkIGFzIGFzc3VtcHRpb25zLCBub3QgdGhhdCBJIGFncmVlIHdpdGggdGhlbSBhbGwu DQo+IA0KPj4gTXkgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGEgY29uY2VwdCBvZiBkb21h aW4gd2hlcmUgYSBkZXZpY2UgY2FuDQo+PiBqb2luIGFuZCBrZWVwIGdldHRpbmcgY29ubmVjdGl2 aXR5IHVzaW5nIGNyZWRlbnRpYWxzIHRoYXQgaXQgb2J0YWlucw0KPj4gb25jZSBhdCBqb2luIHRp bWUgZm9yIGEgbG9uZyBwZXJpb2QuDQo+IA0KPiBUaGF0J3MgYWxzbyBiZWVuIG15IGFzc3VtcHRp b24gd2hpY2ggdG8gbWUsIG1lYW5zIHRoYXQgaXQgZG9lcyBub3QgbWF0dGVyDQo+IHdoaWNoIERP REFHIG9uZSBlbnJvbGxzIHRocm91Z2gsIGFzIGxvbmcgYXMgaXQncyBnb3QgYmFuZHdpZHRoIHRv IGRvIHRoZSBlbnJvbGwNCj4gcHJvY2Vzcy4gQnV0IEkgaGVhciBvdGhlcnMgc2F5aW5nIHRoYXQg dGhleSB3YW50IHRvIHBpY2sgdGhlIG5ldHdvcmsgaW4gYWR2YW5jZS4NCj4gDQo+PiBBIG5ldHdv cmsgKHdoaWNoIGlzIHR5cGljYWxseSBhIHN1Ym5ldCBpZGVudGlmaWVkIHdpdGggYSAvNjQpIHNo b3VsZCBiZQ0KPj4gaW5jbHVkZWQgaW4gYSBkb21haW4sIGFuZCBhIERPREFHIGlzIGluY2x1ZGVk IGluIGEgbmV0d29yay4NCj4gDQo+IEkgdGhpbmsgd2UgYWdyZWU6DQo+ICBEb21haW4gPiBOZXR3 b3JrKC82NCkgPiBET0RBRy4NCj4gDQo+IGJ1dCBtYXliZSB3ZSBuZWVkIHRvIHdyaXRlIHRoaXMg ZG93bi4gIFBlcmhhcHMgdGhlcmUgaXMgYSBzZWN0aW9uIG9mIGJhY2tib25lDQo+IHJvdXRlciB0 aGF0IGV4cGxhaW5zIHRoYXQgc2hvdWxkIGdldCBhIFdHIENvbnNlbnN1cyBjYWxsIGluIFJPTEwu DQo+IA0KPj4gNmxvIGFuZCA2VGlTQ0ggaGF2ZSB0aGUgY29uY2VwdCBvZiBhIGJhY2tib25lIHJv dXRlciB0aGF0IGZlZGVyYXRlcw0KPj4gbXVsdGlwbGUgRE9EQUdzIGluIG9uZSB0byBmb3JtIGEg c3VibmV0OyB0aGlzIGltcGxpZXMgdGhhdCBhIFBBTi1JRCBpcw0KPj4gdGhlIHNhbWUgYW5kIHRo YXQgdGhlIHNob3J0IGFkZHJlc3MgbmFtZXNwYWNlIGlzIGNvbW1vbiwgYXQgbGVhc3QgaWYNCj4+ IG5vZGVzIGRlcml2ZSB0aGVpciBJUHY2IGFkZHJlc3MgZnJvbSBzZWN0aW9uICI2LiAgU3RhdGVs ZXNzIEFkZHJlc3MNCj4+IEF1dG9jb25maWd1cmF0aW9uIiBvZiBSRkMgNDk0NC4NCj4gDQo+IEFn YWluLCBsZXQncyB3cml0ZSB0aGlzIGRvd24uDQo+IA0KPiAtLSANCj4gTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4g LT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBS b2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bA0K From nobody Mon Feb 19 12:34:56 2018 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 EFA2E1205D3 for ; Mon, 19 Feb 2018 12:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 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_LOW=-0.7, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 PokqD_wPOLdm for ; Mon, 19 Feb 2018 12:34:52 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6841200B9 for ; Mon, 19 Feb 2018 12:34:51 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id t185so2886688oif.6 for ; Mon, 19 Feb 2018 12:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eUB8fNhmgcD6iHctjb5lIcw7/JFu0iWoRNIB3NfLwnY=; b=Pt8mTKQLRV7Ll/lqgZeBIxERwv5zs1awGVXJLSF4y1Cx60853uikfHrK79iOWHTxXh etB0LDpxihcQs2ZLmXCGXAEz9palDvRtInabX+fFGWJIcw8Lr4PWBQVf+aG9i5DyEdGS 6WkTlmrURRImI2VQr/wiPIdUwAOx/DvI2JWLXocL+EoxcHmXD/ruIrkA9bgWTfJuXTZ/ pYBuqRs1ss3UhuvTEBbLL7DN8sN0Z5yS3DnK89sh85yaZk1m+tSPUjsvCELztwlgiZVF PQ8rbc4vAXrnfcLDfM4+YOwZyWQHxo529FHV12lPPyWh9ao+8NmALgBHgHJdIfVKC+Ti wBJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eUB8fNhmgcD6iHctjb5lIcw7/JFu0iWoRNIB3NfLwnY=; b=GqZs5zis9zTeiiuT/k7RP5LjVmqOI4jmkugXIUBRh5g0GkNdSPTdurDXA6fq0+kNk/ YpGJJCWddrclH+7/96pjcugfmu8CdLu5P7CCqNGjkPHLZKC+rErJKCEUe8AdYjpUqtO4 WyzJiWIUXQkcmNK/lpn/WhHw8dkZtZayjc4BfuoUdcS9ftdTHSQcwETMCdhq4/IvzQDG 6kMTrwb5gBwHKri8RDlwRUNzcv8GuNY+p2yqrfPFS47nZQ06jowDSouzSyduwPr1n7tP e2S79sGyv2VWq9vy7CWqsk7HfxZaczcD5fanHl2WtjqJ6U9DFSwK8xdbQ5x8jxq7nYgK TMWA== X-Gm-Message-State: APf1xPB3S22gO9X9VOgWPQsWfjwbCvXFJ/FV1l/7JqhNjP/EGHmg0yrc jQqrf/ii7rIlFe6tg7PQreJc/T+JEe0vMHOyAdvTrA== X-Google-Smtp-Source: AH8x2245LEG04i+dt8PyzpMfPxeL22vtCKnJlOqfxKzjXgb2e1bzdywUsLlZCIuStIL79UB5RU2gf92ZIG3orjHPA5w= X-Received: by 10.202.227.7 with SMTP id a7mr10690542oih.193.1519072490570; Mon, 19 Feb 2018 12:34:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.22 with HTTP; Mon, 19 Feb 2018 12:34:50 -0800 (PST) In-Reply-To: <280CB2A8-5B9E-416F-9086-F9483D554827@cisco.com> References: <1519064154.14739.4.camel@uantwerpen.be> <280CB2A8-5B9E-416F-9086-F9483D554827@cisco.com> From: "Prof. Diego Dujovne" Date: Mon, 19 Feb 2018 17:34:50 -0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a1140952e3055fc056596a057" Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 19 Feb 2018 20:34:55 -0000 --001a1140952e3055fc056596a057 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pascal, I'm interested in that draft. Do you have a pointer to it? Thanks, Diego Le lundi 19 f=C3=A9vrier 2018, Pascal Thubert (pthubert) a =C3=A9crit : > Hello Esteban > > For asymmetric link one can build 2 DODAGs. There is a draft I published > several years ago about that... > > > Regards, > > Pascal > > > Le 19 f=C3=A9vr. 2018 =C3=A0 19:16, Esteban Municio > a =C3=A9crit : > > > > Hi Pascal, Rahul, > > > > Yes, that was actually one of my doubts: if a node can send uplink > > through one path and receive downlink through a different path using > > the same DODAG instance. > > > > If links are assumed symmetric that means that is not possible. > > > > > > @Rahul, yes, the idea was to monitor the rank in the nodes (e.g. for > > visualize it in a graph), and maybe play a bit with it. For only the > > DAG, indeed the target-parent option in the DAOs is enough. > > > > Thanks and kind regards, > > Esteban > > > > > >> Hello Esteban > >> > >> RPL does not transport the Rank to the root. We actually designed to > >> save the cost of doing that (and maintaining it afterwards). > >> > >> RPL assumes that the links are symmetrical enough so routing > >> downwards can follow the target=E2=80=99s subdag. That subdag is withi= n the > >> root=E2=80=99s DODAG but directed to the target so there is no need of= a Rank > >> to build it. > >> > >> Regards, > >> > >> Pascal > >> > >>> Le 16 f=C3=A9vr. 2018 =C3=A0 20:28, Esteban Municio >> en.be>; a =C3=A9crit : > >>> > >>> Hi all, > >>> > >>> I think this has been already discussed, but I don't think I > >> totally > >>> understand it. > >>> > >>> Is there any way to obtain the rank of the nodes at the DAGroot? > >> (e.g. > >>> in order to monitor the network) > >>> > >>> One possible idea is obtain it through the ETX of the links. > >>> > >>> Apparently, some metrics can be sent in the in DAG Metric > >> Container, > >>> but I'm not sure if this option can be included in DIOs and DAOs, > >> or > >>> only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. > >>> > >>> Is there any important reason to not send them in the DAOs as well > >> (at > >>> least in the non-storing mode)? > >>> > >>> If this is not possible, is there any other way within RPL to > >> deliver > >>> this information to the DAGroot? > >>> > >>> Otherwise, I only only possibilities: > >>> - Send the rank values from the application layer (which is not > >> very > >>> convenient since that would require access to the RPL sublayer) > >>> - Through sniffer nodes that would get DIO packets in the network. > >>> (however this would require distributing additional nodes all over > >> the > >>> network) > >>> > >>> Am I missing something? Any idea? > >>> > >>> Thank you and kind regards, > >>> Esteban > >>> > >>> > >>> > >>> -- > >>> Esteban Municio > >>> > >>> IDLab - Dept. Mathematics and Computer Science > >>> > >>> University of Antwerp - imec > >>> > >>> Middelheimlaan 1 , 2020 Antwerp, Belgium > >>> > >>> Office M.G.322 > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > > > > -- > > Esteban Municio > > > > IDLab - Dept. Mathematics and Computer Science > > > > University of Antwerp - imec > > > > Middelheimlaan 1 , 2020 Antwerp, Belgium > > > > Office M.G.322 > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a1140952e3055fc056596a057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pascal,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm interes= ted in that draft. Do you have a pointer to it?
Thanks,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego
=
Le=C2=A0lundi 19 f=C3=A9vrier 2018, Pascal Thubert (pthubert) <pthubert@cisco.com> a =C3=A9crit=C2= =A0:
Hello Esteban

For asymmetric link one can build 2 DODAGs. There is a draft I published se= veral years ago about that...


Regards,

Pascal

> Le 19 f=C3=A9vr. 2018 =C3=A0 19:16, Esteban Municio <esteban.municio@uantwerpen.be> a = =C3=A9crit :
>
> Hi Pascal, Rahul,
>
> Yes, that was actually one of my doubts: if a node can send uplink
> through one path and receive downlink through a different path using > the same DODAG instance.
>
> If links are assumed symmetric that means that is not possible.
>
>
> @Rahul, yes, the idea was to monitor the rank in the nodes (e.g. for > visualize it in a graph), and maybe play a bit with it. For only the > DAG, indeed the target-parent option in the DAOs is enough.
>
> Thanks and kind regards,
> Esteban
>
>
>> Hello Esteban
>>
>> RPL does not transport the Rank to the root. We actually designed = to
>> save the cost of doing that (and maintaining it afterwards).
>>
>> RPL assumes that the links are symmetrical enough so routing
>> downwards can follow the target=E2=80=99s subdag. That subdag is w= ithin the
>> root=E2=80=99s DODAG but directed to the target so there is no nee= d of a Rank
>> to build it.
>>
>> Regards,
>>
>> Pascal
>>
>>> Le 16 f=C3=A9vr. 2018 =C3=A0 20:28, Esteban Municio <esteba= n.municio@uantwerp
>> en.be>; a =C3=A9= crit :
>>>
>>> Hi all,
>>>
>>> I think this has been already discussed, but I don't think= I
>> totally
>>> understand it.
>>>
>>> Is there any way to obtain the rank of the nodes at the DAGroo= t?
>> (e.g.
>>> in order to monitor the network)
>>>
>>> One possible idea is obtain it through the ETX of the links. >>>
>>> Apparently, some metrics can be sent in the in DAG Metric
>> Container,
>>> but I'm not sure if this option can be included in DIOs an= d DAOs,
>> or
>>> only in DIOs. According to errata 5160 of RFC6560 is only in D= IOs.
>>>
>>> Is there any important reason to not send them in the DAOs as = well
>> (at
>>> least in the non-storing mode)?
>>>
>>> If this is not possible, is there any other way within RPL to<= br> >> deliver
>>> this information to the DAGroot?
>>>
>>> Otherwise, I only only possibilities:
>>> - Send the rank values from the application layer (which is no= t
>> very
>>> convenient since that would require access to the RPL sublayer= )
>>> - Through sniffer nodes that would get DIO packets in the netw= ork.
>>> (however this would require distributing additional nodes all = over
>> the
>>> network)
>>>
>>> Am I missing something? Any idea?
>>>
>>> Thank you and kind regards,
>>> Esteban
>>>
>>>
>>>
>>> --
>>> Esteban Municio
>>>
>>> IDLab - Dept. Mathematics and Computer Science
>>>
>>> University of Antwerp - imec
>>>
>>> Middelheimlaan 1 , 2020 Antwerp, Belgium
>>>
>>> Office M.G.322
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>
> --
> Esteban Municio
>
> IDLab - Dept. Mathematics and Computer Science
>
> University of Antwerp - imec
>
> Middelheimlaan 1 , 2020 Antwerp, Belgium
>
> Office M.G.322
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Tele= comunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales = - Chile
www.i= ngenieria.udp.cl
(56 2) 676 8125

--001a1140952e3055fc056596a057-- From nobody Mon Feb 19 22:25:16 2018 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 E82A6124235 for ; Mon, 19 Feb 2018 22:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Q6wIe-OItDs1 for ; Mon, 19 Feb 2018 22:25:12 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569A1126D74 for ; Mon, 19 Feb 2018 22:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15653; q=dns/txt; s=iport; t=1519107912; x=1520317512; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JdqsG1yHHZ4WHkQvUGZJuj5afacrLZ/F4KyQTHXYvbY=; b=DCH9ZEITK7elY9vRPXglH9Mu7yt6BVHkjZ7iZkJEHkR9EjxQuX1dx8+d Vri3nJMj+zXtCADGrZdrl2VcSF8Fij35ll0NYqFGnNpNj10VvdkmiDFuP Vwd1X2xSotUtpftJv4GRB7O8eS+y1cp2297G1eCKqIWA/AflXtwR/Ve/d I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAQDyvota/5xdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAog2djiUKOBYFbJ4EXkG2FXIIWChgBCoUYAhqCQVQYAQI?= =?us-ascii?q?BAQEBAQECayiFJAEBAwEBASEmJRAJAgIBCD8DAgICFBELFBECBBOJPlwIELFXg?= =?us-ascii?q?ieFAYQCghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYUGgiiBV4IRDIJDNoMwAQE?= =?us-ascii?q?DgU4BATWDADGCNAWkNQkCiCKBKIJgiV6CIJInjgaJbAIRGQGBOwEfOYFRcBU6K?= =?us-ascii?q?gGCGAmCEoJbeIsegj4BAQE?= X-IronPort-AV: E=Sophos;i="5.46,537,1511827200"; d="scan'208,217";a="358134349" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 06:25:10 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1K6PAFk022231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Feb 2018 06:25:10 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 00:25:10 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 20 Feb 2018 00:25:10 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Obtaining ranks at the DAGroot Thread-Index: AQHTqa2uYHjFv3lTjkutt4iFOIqsXqOsE6fZgAB/wACAAEBbag== Date: Tue, 20 Feb 2018 06:25:10 +0000 Message-ID: <1564E806-6773-4155-ADE3-487B6B0AC984@cisco.com> References: <1519064154.14739.4.camel@uantwerpen.be> <280CB2A8-5B9E-416F-9086-F9483D554827@cisco.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_1564E80667734155ADE3487B6B0AC984ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 06:25:15 -0000 --_000_1564E80667734155ADE3487B6B0AC984ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRGllZ28NCg0KVGhhdCBpcw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdGh1YmVydC1yb2xsLWFzeW1saW5rLTAyDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCkxl IDE5IGbDqXZyLiAyMDE4IMOgIDIxOjM1LCBQcm9mLiBEaWVnbyBEdWpvdm5lIDxkaWVnby5kdWpv dm5lQG1haWwudWRwLmNsPG1haWx0bzpkaWVnby5kdWpvdm5lQG1haWwudWRwLmNsPj4gYSDDqWNy aXQgOg0KDQpQYXNjYWwsDQogICAgICAgICAgICAgSSdtIGludGVyZXN0ZWQgaW4gdGhhdCBkcmFm dC4gRG8geW91IGhhdmUgYSBwb2ludGVyIHRvIGl0Pw0KVGhhbmtzLA0KDQoNCiAgICAgICAgICBE aWVnbw0KDQpMZSBsdW5kaSAxOSBmw6l2cmllciAyMDE4LCBQYXNjYWwgVGh1YmVydCAocHRodWJl cnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+IGEgw6lj cml0IDoNCkhlbGxvIEVzdGViYW4NCg0KRm9yIGFzeW1tZXRyaWMgbGluayBvbmUgY2FuIGJ1aWxk IDIgRE9EQUdzLiBUaGVyZSBpcyBhIGRyYWZ0IEkgcHVibGlzaGVkIHNldmVyYWwgeWVhcnMgYWdv IGFib3V0IHRoYXQuLi4NCg0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0KPiBMZSAxOSBmw6l2ci4g MjAxOCDDoCAxOToxNiwgRXN0ZWJhbiBNdW5pY2lvIDxlc3RlYmFuLm11bmljaW9AdWFudHdlcnBl bi5iZTxtYWlsdG86ZXN0ZWJhbi5tdW5pY2lvQHVhbnR3ZXJwZW4uYmU+PiBhIMOpY3JpdCA6DQo+ DQo+IEhpIFBhc2NhbCwgUmFodWwsDQo+DQo+IFllcywgdGhhdCB3YXMgYWN0dWFsbHkgb25lIG9m IG15IGRvdWJ0czogaWYgYSBub2RlIGNhbiBzZW5kIHVwbGluaw0KPiB0aHJvdWdoIG9uZSBwYXRo IGFuZCByZWNlaXZlIGRvd25saW5rIHRocm91Z2ggYSBkaWZmZXJlbnQgcGF0aCB1c2luZw0KPiB0 aGUgc2FtZSBET0RBRyBpbnN0YW5jZS4NCj4NCj4gSWYgbGlua3MgYXJlIGFzc3VtZWQgc3ltbWV0 cmljIHRoYXQgbWVhbnMgdGhhdCBpcyBub3QgcG9zc2libGUuDQo+DQo+DQo+IEBSYWh1bCwgeWVz LCB0aGUgaWRlYSB3YXMgdG8gbW9uaXRvciB0aGUgcmFuayBpbiB0aGUgbm9kZXMgKGUuZy4gZm9y DQo+IHZpc3VhbGl6ZSBpdCBpbiBhIGdyYXBoKSwgYW5kIG1heWJlIHBsYXkgYSBiaXQgd2l0aCBp dC4gRm9yIG9ubHkgdGhlDQo+IERBRywgaW5kZWVkIHRoZSB0YXJnZXQtcGFyZW50IG9wdGlvbiBp biB0aGUgREFPcyBpcyBlbm91Z2guDQo+DQo+IFRoYW5rcyBhbmQga2luZCByZWdhcmRzLA0KPiBF c3RlYmFuDQo+DQo+DQo+PiBIZWxsbyBFc3RlYmFuDQo+Pg0KPj4gUlBMIGRvZXMgbm90IHRyYW5z cG9ydCB0aGUgUmFuayB0byB0aGUgcm9vdC4gV2UgYWN0dWFsbHkgZGVzaWduZWQgdG8NCj4+IHNh dmUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhhdCAoYW5kIG1haW50YWluaW5nIGl0IGFmdGVyd2FyZHMp Lg0KPj4NCj4+IFJQTCBhc3N1bWVzIHRoYXQgdGhlIGxpbmtzIGFyZSBzeW1tZXRyaWNhbCBlbm91 Z2ggc28gcm91dGluZw0KPj4gZG93bndhcmRzIGNhbiBmb2xsb3cgdGhlIHRhcmdldOKAmXMgc3Vi ZGFnLiBUaGF0IHN1YmRhZyBpcyB3aXRoaW4gdGhlDQo+PiByb2904oCZcyBET0RBRyBidXQgZGly ZWN0ZWQgdG8gdGhlIHRhcmdldCBzbyB0aGVyZSBpcyBubyBuZWVkIG9mIGEgUmFuaw0KPj4gdG8g YnVpbGQgaXQuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBQYXNjYWwNCj4+DQo+Pj4gTGUgMTYg ZsOpdnIuIDIwMTggw6AgMjA6MjgsIEVzdGViYW4gTXVuaWNpbyA8ZXN0ZWJhbi5tdW5pY2lvQHVh bnR3ZXJwDQo+PiBlbi5iZTxodHRwOi8vZW4uYmU+PjsgYSDDqWNyaXQgOg0KPj4+DQo+Pj4gSGkg YWxsLA0KPj4+DQo+Pj4gSSB0aGluayB0aGlzIGhhcyBiZWVuIGFscmVhZHkgZGlzY3Vzc2VkLCBi dXQgSSBkb24ndCB0aGluayBJDQo+PiB0b3RhbGx5DQo+Pj4gdW5kZXJzdGFuZCBpdC4NCj4+Pg0K Pj4+IElzIHRoZXJlIGFueSB3YXkgdG8gb2J0YWluIHRoZSByYW5rIG9mIHRoZSBub2RlcyBhdCB0 aGUgREFHcm9vdD8NCj4+IChlLmcuDQo+Pj4gaW4gb3JkZXIgdG8gbW9uaXRvciB0aGUgbmV0d29y aykNCj4+Pg0KPj4+IE9uZSBwb3NzaWJsZSBpZGVhIGlzIG9idGFpbiBpdCB0aHJvdWdoIHRoZSBF VFggb2YgdGhlIGxpbmtzLg0KPj4+DQo+Pj4gQXBwYXJlbnRseSwgc29tZSBtZXRyaWNzIGNhbiBi ZSBzZW50IGluIHRoZSBpbiBEQUcgTWV0cmljDQo+PiBDb250YWluZXIsDQo+Pj4gYnV0IEknbSBu b3Qgc3VyZSBpZiB0aGlzIG9wdGlvbiBjYW4gYmUgaW5jbHVkZWQgaW4gRElPcyBhbmQgREFPcywN Cj4+IG9yDQo+Pj4gb25seSBpbiBESU9zLiBBY2NvcmRpbmcgdG8gZXJyYXRhIDUxNjAgb2YgUkZD NjU2MCBpcyBvbmx5IGluIERJT3MuDQo+Pj4NCj4+PiBJcyB0aGVyZSBhbnkgaW1wb3J0YW50IHJl YXNvbiB0byBub3Qgc2VuZCB0aGVtIGluIHRoZSBEQU9zIGFzIHdlbGwNCj4+IChhdA0KPj4+IGxl YXN0IGluIHRoZSBub24tc3RvcmluZyBtb2RlKT8NCj4+Pg0KPj4+IElmIHRoaXMgaXMgbm90IHBv c3NpYmxlLCBpcyB0aGVyZSBhbnkgb3RoZXIgd2F5IHdpdGhpbiBSUEwgdG8NCj4+IGRlbGl2ZXIN Cj4+PiB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBEQUdyb290Pw0KPj4+DQo+Pj4gT3RoZXJ3aXNl LCBJIG9ubHkgb25seSBwb3NzaWJpbGl0aWVzOg0KPj4+IC0gU2VuZCB0aGUgcmFuayB2YWx1ZXMg ZnJvbSB0aGUgYXBwbGljYXRpb24gbGF5ZXIgKHdoaWNoIGlzIG5vdA0KPj4gdmVyeQ0KPj4+IGNv bnZlbmllbnQgc2luY2UgdGhhdCB3b3VsZCByZXF1aXJlIGFjY2VzcyB0byB0aGUgUlBMIHN1Ymxh eWVyKQ0KPj4+IC0gVGhyb3VnaCBzbmlmZmVyIG5vZGVzIHRoYXQgd291bGQgZ2V0IERJTyBwYWNr ZXRzIGluIHRoZSBuZXR3b3JrLg0KPj4+IChob3dldmVyIHRoaXMgd291bGQgcmVxdWlyZSBkaXN0 cmlidXRpbmcgYWRkaXRpb25hbCBub2RlcyBhbGwgb3Zlcg0KPj4gdGhlDQo+Pj4gbmV0d29yaykN Cj4+Pg0KPj4+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/IEFueSBpZGVhPw0KPj4+DQo+Pj4gVGhh bmsgeW91IGFuZCBraW5kIHJlZ2FyZHMsDQo+Pj4gRXN0ZWJhbg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ IC0tDQo+Pj4gRXN0ZWJhbiBNdW5pY2lvDQo+Pj4NCj4+PiBJRExhYiAtIERlcHQuIE1hdGhlbWF0 aWNzIGFuZCBDb21wdXRlciBTY2llbmNlDQo+Pj4NCj4+PiBVbml2ZXJzaXR5IG9mIEFudHdlcnAg LSBpbWVjDQo+Pj4NCj4+PiBNaWRkZWxoZWltbGFhbiAxICwgMjAyMCBBbnR3ZXJwLCBCZWxnaXVt DQo+Pj4NCj4+PiBPZmZpY2UgTS5HLjMyMg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4+IFJv bGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+DQo+IC0tDQo+IEVzdGViYW4gTXVuaWNpbw0KPg0K PiBJRExhYiAtIERlcHQuIE1hdGhlbWF0aWNzIGFuZCBDb21wdXRlciBTY2llbmNlDQo+DQo+IFVu aXZlcnNpdHkgb2YgQW50d2VycCAtIGltZWMNCj4NCj4gTWlkZGVsaGVpbWxhYW4gMSAsIDIwMjAg QW50d2VycCwgQmVsZ2l1bQ0KPg0KPiBPZmZpY2UgTS5HLjMyMg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0K PiBSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWls dG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0KDQoNCi0tDQpESUVHTyBEVUpPVk5FDQpQcm9mZXNvciBBc29jaWFkbw0KRXNjdWVsYSBk ZSBJbmZvcm3DoXRpY2EgeSBUZWxlY29tdW5pY2FjaW9uZXMNCkZhY3VsdGFkIGRlIEluZ2VuaWVy w61hIC0gVW5pdmVyc2lkYWQgRGllZ28gUG9ydGFsZXMgLSBDaGlsZQ0Kd3d3LmluZ2VuaWVyaWEu dWRwLmNsPGh0dHA6Ly93d3cuaW5nZW5pZXJpYS51ZHAuY2w+DQooNTYgMikgNjc2IDgxMjUNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= --_000_1564E80667734155ADE3487B6B0AC984ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBEaWVnbyZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhdCBpczwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMjwvYT48YnI+DQo8YnI+DQpUYWtl IGNhcmUsPGJyPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pjxicj4NCkxlIDE5IGbDqXZyLiAyMDE4IMOgIDIxOjM1LCBQcm9mLiBEaWVn byBEdWpvdm5lICZsdDs8YSBocmVmPSJtYWlsdG86ZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbCI+ ZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj4NCjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PlBhc2NhbCwNCjxkaXY+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SSdtIGludGVy ZXN0ZWQgaW4gdGhhdCBkcmFmdC4gRG8geW91IGhhdmUgYSBwb2ludGVyIHRvIGl0PzwvZGl2Pg0K PGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEaWVnbzxicj4NCjxicj4N CkxlJm5ic3A7bHVuZGkgMTkgZsOpdnJpZXIgMjAxOCwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lzY28u Y29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpIZWxsbyBFc3RlYmFuPGJyPg0KPGJyPg0KRm9yIGFzeW1t ZXRyaWMgbGluayBvbmUgY2FuIGJ1aWxkIDIgRE9EQUdzLiBUaGVyZSBpcyBhIGRyYWZ0IEkgcHVi bGlzaGVkIHNldmVyYWwgeWVhcnMgYWdvIGFib3V0IHRoYXQuLi48YnI+DQo8YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCjxicj4NClBhc2NhbDxicj4NCjxicj4NCiZndDsgTGUgMTkgZsOpdnIuIDIw MTggw6AgMTk6MTYsIEVzdGViYW4gTXVuaWNpbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVzdGViYW4u bXVuaWNpb0B1YW50d2VycGVuLmJlIj5lc3RlYmFuLm11bmljaW9AdWFudHdlcnBlbi5iZTwvYT4m Z3Q7IGEgw6ljcml0IDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBQYXNjYWwsIFJhaHVsLDxicj4N CiZndDs8YnI+DQomZ3Q7IFllcywgdGhhdCB3YXMgYWN0dWFsbHkgb25lIG9mIG15IGRvdWJ0czog aWYgYSBub2RlIGNhbiBzZW5kIHVwbGluazxicj4NCiZndDsgdGhyb3VnaCBvbmUgcGF0aCBhbmQg cmVjZWl2ZSBkb3dubGluayB0aHJvdWdoIGEgZGlmZmVyZW50IHBhdGggdXNpbmc8YnI+DQomZ3Q7 IHRoZSBzYW1lIERPREFHIGluc3RhbmNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIGxpbmtzIGFy ZSBhc3N1bWVkIHN5bW1ldHJpYyB0aGF0IG1lYW5zIHRoYXQgaXMgbm90IHBvc3NpYmxlLjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBAUmFodWwsIHllcywgdGhlIGlkZWEgd2FzIHRvIG1v bml0b3IgdGhlIHJhbmsgaW4gdGhlIG5vZGVzIChlLmcuIGZvcjxicj4NCiZndDsgdmlzdWFsaXpl IGl0IGluIGEgZ3JhcGgpLCBhbmQgbWF5YmUgcGxheSBhIGJpdCB3aXRoIGl0LiBGb3Igb25seSB0 aGU8YnI+DQomZ3Q7IERBRywgaW5kZWVkIHRoZSB0YXJnZXQtcGFyZW50IG9wdGlvbiBpbiB0aGUg REFPcyBpcyBlbm91Z2guPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGFuZCBraW5kIHJlZ2Fy ZHMsPGJyPg0KJmd0OyBFc3RlYmFuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBI ZWxsbyBFc3RlYmFuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSUEwgZG9lcyBub3QgdHJh bnNwb3J0IHRoZSBSYW5rIHRvIHRoZSByb290LiBXZSBhY3R1YWxseSBkZXNpZ25lZCB0bzxicj4N CiZndDsmZ3Q7IHNhdmUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhhdCAoYW5kIG1haW50YWluaW5nIGl0 IGFmdGVyd2FyZHMpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUlBMIGFzc3VtZXMgdGhh dCB0aGUgbGlua3MgYXJlIHN5bW1ldHJpY2FsIGVub3VnaCBzbyByb3V0aW5nPGJyPg0KJmd0OyZn dDsgZG93bndhcmRzIGNhbiBmb2xsb3cgdGhlIHRhcmdldOKAmXMgc3ViZGFnLiBUaGF0IHN1YmRh ZyBpcyB3aXRoaW4gdGhlPGJyPg0KJmd0OyZndDsgcm9vdOKAmXMgRE9EQUcgYnV0IGRpcmVjdGVk IHRvIHRoZSB0YXJnZXQgc28gdGhlcmUgaXMgbm8gbmVlZCBvZiBhIFJhbms8YnI+DQomZ3Q7Jmd0 OyB0byBidWlsZCBpdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQYXNjYWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBMZSAxNiBmw6l2ci4gMjAxOCDDoCAyMDoyOCwgRXN0ZWJhbiBNdW5pY2lvICZsdDtlc3Rl YmFuLm11bmljaW9AdWFudHdlcnA8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vZW4uYmUi IHRhcmdldD0iX2JsYW5rIj5lbi5iZTwvYT4mZ3Q7OyBhIMOpY3JpdCA6PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgSSB0aGluayB0aGlzIGhhcyBiZWVuIGFscmVhZHkgZGlzY3Vzc2VkLCBidXQgSSBk b24ndCB0aGluayBJPGJyPg0KJmd0OyZndDsgdG90YWxseTxicj4NCiZndDsmZ3Q7Jmd0OyB1bmRl cnN0YW5kIGl0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJcyB0aGVyZSBh bnkgd2F5IHRvIG9idGFpbiB0aGUgcmFuayBvZiB0aGUgbm9kZXMgYXQgdGhlIERBR3Jvb3Q/PGJy Pg0KJmd0OyZndDsgKGUuZy48YnI+DQomZ3Q7Jmd0OyZndDsgaW4gb3JkZXIgdG8gbW9uaXRvciB0 aGUgbmV0d29yayk8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT25lIHBvc3Np YmxlIGlkZWEgaXMgb2J0YWluIGl0IHRocm91Z2ggdGhlIEVUWCBvZiB0aGUgbGlua3MuPGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFwcGFyZW50bHksIHNvbWUgbWV0cmljcyBj YW4gYmUgc2VudCBpbiB0aGUgaW4gREFHIE1ldHJpYzxicj4NCiZndDsmZ3Q7IENvbnRhaW5lciw8 YnI+DQomZ3Q7Jmd0OyZndDsgYnV0IEknbSBub3Qgc3VyZSBpZiB0aGlzIG9wdGlvbiBjYW4gYmUg aW5jbHVkZWQgaW4gRElPcyBhbmQgREFPcyw8YnI+DQomZ3Q7Jmd0OyBvcjxicj4NCiZndDsmZ3Q7 Jmd0OyBvbmx5IGluIERJT3MuIEFjY29yZGluZyB0byBlcnJhdGEgNTE2MCBvZiBSRkM2NTYwIGlz IG9ubHkgaW4gRElPcy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSXMgdGhl cmUgYW55IGltcG9ydGFudCByZWFzb24gdG8gbm90IHNlbmQgdGhlbSBpbiB0aGUgREFPcyBhcyB3 ZWxsPGJyPg0KJmd0OyZndDsgKGF0PGJyPg0KJmd0OyZndDsmZ3Q7IGxlYXN0IGluIHRoZSBub24t c3RvcmluZyBtb2RlKT88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSWYgdGhp cyBpcyBub3QgcG9zc2libGUsIGlzIHRoZXJlIGFueSBvdGhlciB3YXkgd2l0aGluIFJQTCB0bzxi cj4NCiZndDsmZ3Q7IGRlbGl2ZXI8YnI+DQomZ3Q7Jmd0OyZndDsgdGhpcyBpbmZvcm1hdGlvbiB0 byB0aGUgREFHcm9vdD88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT3RoZXJ3 aXNlLCBJIG9ubHkgb25seSBwb3NzaWJpbGl0aWVzOjxicj4NCiZndDsmZ3Q7Jmd0OyAtIFNlbmQg dGhlIHJhbmsgdmFsdWVzIGZyb20gdGhlIGFwcGxpY2F0aW9uIGxheWVyICh3aGljaCBpcyBub3Q8 YnI+DQomZ3Q7Jmd0OyB2ZXJ5PGJyPg0KJmd0OyZndDsmZ3Q7IGNvbnZlbmllbnQgc2luY2UgdGhh dCB3b3VsZCByZXF1aXJlIGFjY2VzcyB0byB0aGUgUlBMIHN1YmxheWVyKTxicj4NCiZndDsmZ3Q7 Jmd0OyAtIFRocm91Z2ggc25pZmZlciBub2RlcyB0aGF0IHdvdWxkIGdldCBESU8gcGFja2V0cyBp biB0aGUgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyZndDsgKGhvd2V2ZXIgdGhpcyB3b3VsZCByZXF1 aXJlIGRpc3RyaWJ1dGluZyBhZGRpdGlvbmFsIG5vZGVzIGFsbCBvdmVyPGJyPg0KJmd0OyZndDsg dGhlPGJyPg0KJmd0OyZndDsmZ3Q7IG5ldHdvcmspPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/IEFueSBpZGVhPzxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFuayB5b3UgYW5kIGtpbmQgcmVnYXJkcyw8YnI+DQom Z3Q7Jmd0OyZndDsgRXN0ZWJhbjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyBF c3RlYmFuIE11bmljaW88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSURMYWIg LSBEZXB0LiBNYXRoZW1hdGljcyBhbmQgQ29tcHV0ZXIgU2NpZW5jZTxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBVbml2ZXJzaXR5IG9mIEFudHdlcnAgLSBpbWVjPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE1pZGRlbGhlaW1sYWFuIDEgLCAyMDIwIEFudHdl cnAsIEJlbGdpdW08YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT2ZmaWNlIE0u Ry4zMjI8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBS b2xsIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86Um9sbEBp ZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3JvbGw8L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IEVzdGViYW4gTXVuaWNpbzxicj4NCiZndDs8YnI+ DQomZ3Q7IElETGFiIC0gRGVwdC4gTWF0aGVtYXRpY3MgYW5kIENvbXB1dGVyIFNjaWVuY2U8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBVbml2ZXJzaXR5IG9mIEFudHdlcnAgLSBpbWVjPGJyPg0KJmd0Ozxi cj4NCiZndDsgTWlkZGVsaGVpbWxhYW4gMSAsIDIwMjAgQW50d2VycCwgQmVsZ2l1bTxicj4NCiZn dDs8YnI+DQomZ3Q7IE9mZmljZSBNLkcuMzIyPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgUm9s bCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5S b2xsQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3JvbGw8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZv L3JvbGw8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnI+DQotLSA8YnI+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+RElFR08gRFVK T1ZORTxicj4NClByb2Zlc29yIEFzb2NpYWRvPGJyPg0KRXNjdWVsYSBkZSBJbmZvcm3DoXRpY2Eg eSBUZWxlY29tdW5pY2FjaW9uZXM8YnI+DQpGYWN1bHRhZCBkZSBJbmdlbmllcsOtYSAtIFVuaXZl cnNpZGFkIERpZWdvIFBvcnRhbGVzIC0gQ2hpbGU8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmlu Z2VuaWVyaWEudWRwLmNsIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZ2VuaWVyaWEudWRwLmNsPC9h Pjxicj4NCig1NiAyKSA2NzYgODEyNTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyPg0KPHNwYW4+Um9sbCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+ PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+PC9zcGFuPjxi cj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjwvc3Bh bj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1564E80667734155ADE3487B6B0AC984ciscocom_-- From nobody Tue Feb 20 00:17:05 2018 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 E9FA01243F3 for ; Tue, 20 Feb 2018 00:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 nakncVOGbp7a for ; Tue, 20 Feb 2018 00:17:00 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C59124239 for ; Tue, 20 Feb 2018 00:17:00 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id e64so10708787ote.4 for ; Tue, 20 Feb 2018 00:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GHmOPa11DvPJydTFirl6+dMo0pXS3nVgP3OT1c/O494=; b=t9wVoYAHRkyG6+JJNWs6eRFQGgxHpslR6T4KN19ABrZfybMrz3zuvv4PtWQnOf+XPN baNIp7kuIxFhZrfwSCHAl7I3RsaBBjBQZe3D1D/Peg7Z3IuyiASqmDvEA9hULFpCbj/6 6YOhKT2PayQgOGK+Dg3xKsl8Vohza/aPMCtHokcxMu2E0pvbAZ7YXcVLG7rXmJaBVD28 Uk0cnS2zj5rhZx9E1iG5mXxdpBHlf+XqagMXxr9sZcAO5b+UyNkwP4xOPyS5JK7kL5VA pYD3DV6N+sczQ9124piDh0YNr5bWkTGt6r3gHtTTx8Efca10/FqXUlFOib7y1pkcuD59 wTyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GHmOPa11DvPJydTFirl6+dMo0pXS3nVgP3OT1c/O494=; b=KGm/nOMTLzWnoPii8rI52BNP/PkszsO1/4dKcrlGHISecYeZSXEA8dxz7l5iF8pIxT wsrPMN9ENuwDd9yDjEafveDTvQg8MSbdXzwGq416BszkRC4pAqwLR0QWqiElj+nOphTp 7RNtns2PLUd1s60L0QY/G3/lnDtxQASZWoyjyqWtU/ugbMLtugLu56BYwGWAc50Kxsw8 Kk+ahYbqkWEFdppKS8DZGoNRAXKugmtmuhiun7LBqeI9vPuPg8+7nLLIvC7fdTOxoXLU BvKUR6Fo/iPXJi39uBO3mIkKpNyrUo/NowFU2/lw9GnTcSQcdPruOYL0bU9xRfb9KzpV Zmfg== X-Gm-Message-State: APf1xPCLjTPfJ8LMU4BFXpTp7nQoHDrJj4WL32eV6BABsxwOdNGM0QEg ggy884qwxn4Jti7a0dCX26GDoJDiIlz1azCJaBuCRw== X-Google-Smtp-Source: AH8x225+mNbIkNhN9auArjoQj9niLQrEdg8huqFpQKQUbDRK7tQr8tgMjOyR0bZohuW3HEn0jP73dG2HYI0J49TFX5w= X-Received: by 10.157.72.231 with SMTP id a36mr4338284otj.308.1519114619432; Tue, 20 Feb 2018 00:16:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.22 with HTTP; Tue, 20 Feb 2018 00:16:58 -0800 (PST) In-Reply-To: <1564E806-6773-4155-ADE3-487B6B0AC984@cisco.com> References: <1519064154.14739.4.camel@uantwerpen.be> <280CB2A8-5B9E-416F-9086-F9483D554827@cisco.com> <1564E806-6773-4155-ADE3-487B6B0AC984@cisco.com> From: "Prof. Diego Dujovne" Date: Tue, 20 Feb 2018 05:16:58 -0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="94eb2c1c215243c14a0565a06fba" Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 08:17:04 -0000 --94eb2c1c215243c14a0565a06fba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pascal, Thanks! Regards, Diego Le mardi 20 f=C3=A9vrier 2018, Pascal Thubert (pthubert) a =C3=A9crit : > Hello Diego > > That is > > https://tools.ietf.org/html/draft-thubert-roll-asymlink-02 > > Take care, > > Pascal > > Le 19 f=C3=A9vr. 2018 =C3=A0 21:35, Prof. Diego Dujovne > a =C3=A9crit : > > Pascal, > I'm interested in that draft. Do you have a pointer to it? > Thanks, > > > Diego > > Le lundi 19 f=C3=A9vrier 2018, Pascal Thubert (pthubert) > a =C3=A9crit : > >> Hello Esteban >> >> For asymmetric link one can build 2 DODAGs. There is a draft I published >> several years ago about that... >> >> >> Regards, >> >> Pascal >> >> > Le 19 f=C3=A9vr. 2018 =C3=A0 19:16, Esteban Municio < >> esteban.municio@uantwerpen.be> a =C3=A9crit : >> > >> > Hi Pascal, Rahul, >> > >> > Yes, that was actually one of my doubts: if a node can send uplink >> > through one path and receive downlink through a different path using >> > the same DODAG instance. >> > >> > If links are assumed symmetric that means that is not possible. >> > >> > >> > @Rahul, yes, the idea was to monitor the rank in the nodes (e.g. for >> > visualize it in a graph), and maybe play a bit with it. For only the >> > DAG, indeed the target-parent option in the DAOs is enough. >> > >> > Thanks and kind regards, >> > Esteban >> > >> > >> >> Hello Esteban >> >> >> >> RPL does not transport the Rank to the root. We actually designed to >> >> save the cost of doing that (and maintaining it afterwards). >> >> >> >> RPL assumes that the links are symmetrical enough so routing >> >> downwards can follow the target=E2=80=99s subdag. That subdag is with= in the >> >> root=E2=80=99s DODAG but directed to the target so there is no need o= f a Rank >> >> to build it. >> >> >> >> Regards, >> >> >> >> Pascal >> >> >> >>> Le 16 f=C3=A9vr. 2018 =C3=A0 20:28, Esteban Municio > >> en.be>; a =C3=A9crit : >> >>> >> >>> Hi all, >> >>> >> >>> I think this has been already discussed, but I don't think I >> >> totally >> >>> understand it. >> >>> >> >>> Is there any way to obtain the rank of the nodes at the DAGroot? >> >> (e.g. >> >>> in order to monitor the network) >> >>> >> >>> One possible idea is obtain it through the ETX of the links. >> >>> >> >>> Apparently, some metrics can be sent in the in DAG Metric >> >> Container, >> >>> but I'm not sure if this option can be included in DIOs and DAOs, >> >> or >> >>> only in DIOs. According to errata 5160 of RFC6560 is only in DIOs. >> >>> >> >>> Is there any important reason to not send them in the DAOs as well >> >> (at >> >>> least in the non-storing mode)? >> >>> >> >>> If this is not possible, is there any other way within RPL to >> >> deliver >> >>> this information to the DAGroot? >> >>> >> >>> Otherwise, I only only possibilities: >> >>> - Send the rank values from the application layer (which is not >> >> very >> >>> convenient since that would require access to the RPL sublayer) >> >>> - Through sniffer nodes that would get DIO packets in the network. >> >>> (however this would require distributing additional nodes all over >> >> the >> >>> network) >> >>> >> >>> Am I missing something? Any idea? >> >>> >> >>> Thank you and kind regards, >> >>> Esteban >> >>> >> >>> >> >>> >> >>> -- >> >>> Esteban Municio >> >>> >> >>> IDLab - Dept. Mathematics and Computer Science >> >>> >> >>> University of Antwerp - imec >> >>> >> >>> Middelheimlaan 1 , 2020 Antwerp, Belgium >> >>> >> >>> Office M.G.322 >> >>> >> >>> _______________________________________________ >> >>> Roll mailing list >> >>> Roll@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/roll >> > >> > -- >> > Esteban Municio >> > >> > IDLab - Dept. Mathematics and Computer Science >> > >> > University of Antwerp - imec >> > >> > Middelheimlaan 1 , 2020 Antwerp, Belgium >> > >> > Office M.G.322 >> > >> > _______________________________________________ >> > Roll mailing list >> > Roll@ietf.org >> > https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --94eb2c1c215243c14a0565a06fba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pascal,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks!
Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Diego

Le=C2=A0mardi 20 f=C3=A9vrier 2018, Pascal Th= ubert (pthubert) <pthubert@cisco.c= om> a =C3=A9crit=C2=A0:
Hello Diego=C2=A0

That is

https://tools.ietf.org/html/draft-thubert-roll-asym= link-02

Take care,

Pascal

Le 19 f=C3=A9vr. 2018 =C3=A0 21:35, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> a =C3=A9crit=C2=A0:

Pascal,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm interested in = that draft. Do you have a pointer to it?
Thanks,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego

Le=C2=A0lundi 19 f=C3=A9vrier 2018, Pascal Thubert (pthubert) <pthubert@cisco.com>= a =C3=A9crit=C2=A0:
Hello Esteban

For asymmetric link one can build 2 DODAGs. There is a draft I published se= veral years ago about that...


Regards,

Pascal

> Le 19 f=C3=A9vr. 2018 =C3=A0 19:16, Esteban Municio <esteban.municio@uantwe= rpen.be> a =C3=A9crit :
>
> Hi Pascal, Rahul,
>
> Yes, that was actually one of my doubts: if a node can send uplink
> through one path and receive downlink through a different path using > the same DODAG instance.
>
> If links are assumed symmetric that means that is not possible.
>
>
> @Rahul, yes, the idea was to monitor the rank in the nodes (e.g. for > visualize it in a graph), and maybe play a bit with it. For only the > DAG, indeed the target-parent option in the DAOs is enough.
>
> Thanks and kind regards,
> Esteban
>
>
>> Hello Esteban
>>
>> RPL does not transport the Rank to the root. We actually designed = to
>> save the cost of doing that (and maintaining it afterwards).
>>
>> RPL assumes that the links are symmetrical enough so routing
>> downwards can follow the target=E2=80=99s subdag. That subdag is w= ithin the
>> root=E2=80=99s DODAG but directed to the target so there is no nee= d of a Rank
>> to build it.
>>
>> Regards,
>>
>> Pascal
>>
>>> Le 16 f=C3=A9vr. 2018 =C3=A0 20:28, Esteban Municio <esteba= n.municio@uantwerp
>> en.be>; a =C3=A9= crit :
>>>
>>> Hi all,
>>>
>>> I think this has been already discussed, but I don't think= I
>> totally
>>> understand it.
>>>
>>> Is there any way to obtain the rank of the nodes at the DAGroo= t?
>> (e.g.
>>> in order to monitor the network)
>>>
>>> One possible idea is obtain it through the ETX of the links. >>>
>>> Apparently, some metrics can be sent in the in DAG Metric
>> Container,
>>> but I'm not sure if this option can be included in DIOs an= d DAOs,
>> or
>>> only in DIOs. According to errata 5160 of RFC6560 is only in D= IOs.
>>>
>>> Is there any important reason to not send them in the DAOs as = well
>> (at
>>> least in the non-storing mode)?
>>>
>>> If this is not possible, is there any other way within RPL to<= br> >> deliver
>>> this information to the DAGroot?
>>>
>>> Otherwise, I only only possibilities:
>>> - Send the rank values from the application layer (which is no= t
>> very
>>> convenient since that would require access to the RPL sublayer= )
>>> - Through sniffer nodes that would get DIO packets in the netw= ork.
>>> (however this would require distributing additional nodes all = over
>> the
>>> network)
>>>
>>> Am I missing something? Any idea?
>>>
>>> Thank you and kind regards,
>>> Esteban
>>>
>>>
>>>
>>> --
>>> Esteban Municio
>>>
>>> IDLab - Dept. Mathematics and Computer Science
>>>
>>> University of Antwerp - imec
>>>
>>> Middelheimlaan 1 , 2020 Antwerp, Belgium
>>>
>>> Office M.G.322
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/roll
>
> --
> Esteban Municio
>
> IDLab - Dept. Mathematics and Computer Science
>
> University of Antwerp - imec
>
> Middelheimlaan 1 , 2020 Antwerp, Belgium
>
> Office M.G.322
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.u= dp.cl
(56 2) 676 8125

_______________________________________________
Roll mailing list
Roll@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/roll


--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Tele= comunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales = - Chile
www.i= ngenieria.udp.cl
(56 2) 676 8125

--94eb2c1c215243c14a0565a06fba-- From nobody Tue Feb 20 00:37:19 2018 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 51E071243F3 for ; Tue, 20 Feb 2018 00:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx_GAEbH8Mqx for ; Tue, 20 Feb 2018 00:37:16 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205A5124239 for ; Tue, 20 Feb 2018 00:37:15 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud9.xs4all.net with ESMTPA id o3QIeH2yjoWCOo3QIejBoP; Tue, 20 Feb 2018 09:37:14 +0100 Received: from AMontpellier-654-1-186-134.w92-145.abo.wanadoo.fr ([92.145.165.134]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 20 Feb 2018 09:37:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 20 Feb 2018 09:37:14 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14748.1519066368@obiwan.sandelman.ca> References: <1518809265.1358.3.camel@uantwerpen.be> <14748.1519066368@obiwan.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfAyYksl/9zq7pCIhI8u/mJ8w2EbWp+t6uzcq7QW5pdiRUdyQOKwaxcdDDFbErF4BKdXf1taMLUn17XWTr2cXucdkfbSPAOASIpqaz60VplOYsYCXH3QF zFHRMC5tj546/KvLvlZLuURnD0StH2Eq9wBYwt8NLtgHJtpnLkcT8EYfcq7f8NaIxU2JJaPhp1ur4piCI6kLVts/juTXuoaX6gEe37oY8XrpgepKFuwYr9qT Oz6xS6mueyXRdsYvJW5ouQ== Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 08:37:17 -0000 When it is diagnostics or management, using DIO or DAO is stresfull for the network. Reserving DIO and DAO for DODAG control only seems a good practice to me. There are other tools for diagnostic like: YANG. It would be good to put a bit more effort in a YANG model for RPL. Peter Michael Richardson schreef op 2018-02-19 19:52: > Rahul Jadhav wrote: > > Is there any specific thing that is achieved by sending ETX/Rank > ? > > It's awefully good for diagnostics. > > We really need a mgmt interface that either lets the DAGroot query > directly, > or lets' the leaves send the information. But if we send it from > leaf->root, > then we need to decide how often to do that, and this means appling > trickle > to it. > > So I prefer to have the root query this information; it's just another > P2MP > control flow. It would be nice to have some bit that tells the root if > the > new leaf is capable of the new interface. > > This would fit into our SMI (now YANG/NETCONF) requirements, btw. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Feb 20 01:21:23 2018 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 4C4291242F5 for ; Tue, 20 Feb 2018 01:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 pbikgA3PJ0Ms for ; Tue, 20 Feb 2018 01:21:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88B5124239 for ; Tue, 20 Feb 2018 01:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1659; q=dns/txt; s=iport; t=1519118480; x=1520328080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IledLg2grjzC+O/wy7pL2sbd2/BQUfAyNij2Rj3FFj4=; b=FSwzvbV5WQbMQvtTB0LhxmumQEgNEtUHdMtR/G41lLuuDppS2/gygzyA JCt+BjDoxCHPNcsfmZYq76SJu4/PPyVBLHSiZXenFIkLfehbHGP8ic10j +Px0FZg2nM2Av8ilsQvVdIZdKmcivlaD+uCPVw2MZ4V4Y/6Lg3uzzLw4P o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAgBP6Ita/5BdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCpwHggKBF4d/jkqCFgoYC4UYAoJeVRcBAgEBAQEBAQJ?= =?us-ascii?q?rKIUjAQEBBAEBJUcLDAQCAQgRBAEBAScHIQYLFAkIAgQOBQiKAgMVELIlOodBD?= =?us-ascii?q?YEyghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYULgiiBV4UWgmxEAQGBVYYYBZM?= =?us-ascii?q?fkGE1CQKQfYUClFCOTokkAhEZAYE7ASABN4FRcBU6gkOEdniMQ4EZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,538,1511827200"; d="scan'208";a="356335760" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 09:21:02 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1K9L2nk012087 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Feb 2018 09:21:02 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 03:21:01 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 20 Feb 2018 03:21:02 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" CC: Michael Richardson Thread-Topic: [Roll] Obtaining ranks at the DAGroot Thread-Index: AQHTqiYBYHjFv3lTjkutt4iFOIqsXqOtA0kA Date: Tue, 20 Feb 2018 09:20:38 +0000 Deferred-Delivery: Tue, 20 Feb 2018 09:19:44 +0000 Message-ID: References: <1518809265.1358.3.camel@uantwerpen.be> <14748.1519066368@obiwan.sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Obtaining ranks at the DAGroot X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 09:21:22 -0000 +1 -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: mardi 20 f=E9vrier 2018 09:37 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] Obtaining ranks at the DAGroot When it is diagnostics or management, using DIO or DAO is stresfull for the= network. Reserving DIO and DAO for DODAG control only seems a good practice to me. There are other tools for diagnostic like: YANG. It would be good to put a bit more effort in a YANG model for RPL. Peter Michael Richardson schreef op 2018-02-19 19:52: > Rahul Jadhav wrote: > > Is there any specific thing that is achieved by sending ETX/Rank=20 > ? >=20 > It's awefully good for diagnostics. >=20 > We really need a mgmt interface that either lets the DAGroot query=20 > directly, or lets' the leaves send the information. But if we send it=20 > from > leaf->root, > then we need to decide how often to do that, and this means appling=20 > trickle to it. >=20 > So I prefer to have the root query this information; it's just another=20 > P2MP control flow. It would be nice to have some bit that tells the=20 > root if the new leaf is capable of the new interface. >=20 > This would fit into our SMI (now YANG/NETCONF) requirements, btw. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Tue Feb 20 02:59:50 2018 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 6194D12711B for ; Tue, 20 Feb 2018 02:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=imt-atlantique.fr 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 EPcoZLwxYJwf for ; Tue, 20 Feb 2018 02:59:45 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F101270B4 for ; Tue, 20 Feb 2018 02:59:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 7255880DBE for ; Tue, 20 Feb 2018 11:59:43 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id kNR68TyrBNbm for ; Tue, 20 Feb 2018 11:59:41 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id BD85081566 for ; Tue, 20 Feb 2018 11:59:41 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr BD85081566 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1519124381; bh=85PXJH4Uye+bkQhBYGWrDdq1vhugVOieE8ocPH3g50M=; h=From:Message-Id:Date:To:Mime-Version; b=MbxxPUsriLrFFCvUArcSzIQOm35p+gEt6e390OMSeVhoABA5UrNS25vbl/IWWtGux ncoLA0WRK2ZKTYQtzQrJToz75DzQ0eruihSrngcWs6ZsuEMsEArsI8OHbD19NiWY+R U2++iudhIEAGW1JwzSpe1U17EKuUpVz2Iw+lvT3s= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id YdDzSc0V0GaJ for ; Tue, 20 Feb 2018 11:59:41 +0100 (CET) Received: from [IPv6:2001:660:7301:3728:9414:4386:6639:cdc1] (unknown [IPv6:2001:660:7301:3728:9414:4386:6639:cdc1]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 73791814E4 for ; Tue, 20 Feb 2018 11:59:41 +0100 (CET) From: "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="Apple-Mail=_3BAF596B-2314-429D-8474-65B354D6A873" Message-Id: <8E803AE8-AC86-4C08-8820-6DF27BE5F038@imt-atlantique.fr> Date: Tue, 20 Feb 2018 11:59:40 +0100 To: Routing Over Low power and Lossy networks Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Roll] Comments on [draft-richardson-6tisch-roll-enrollment-priority-00] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 10:59:49 -0000 --Apple-Mail=_3BAF596B-2314-429D-8474-65B354D6A873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Michael, I have some (maybe minor) comments on = draft-richardson-6tisch-roll-enrollment-priority-00 draft. Best, Georgios =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94 Georgios Z. Papadopoulos, Ph.D. Associate Professor, IMT Atlantique web: www.georgiospapadopoulos.com = twitter: @gzpapadopoulos = =E2=80=94=E2=80=94 Consider to submit @AdHoc-Now 2018 = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94 6lo Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Informational February 02, 2018 Expires: August 6, 2018 Enabling secure network enrollment in RPL networks draft-richardson-6tisch-roll-enrollment-priority-00 Abstract [I-D.richardson-6tisch-join-enhanced-beacon] defines a method by which a potential [I-D.ietf-6tisch-minimal-security] can announce itself as a available for new Pledges to Join a network. The announcement includes a priority for join. This document provides a mechanism by which a RPL DODAG root can disable join announcements, or adjust the base priority for join operation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Richardson Expires August 6, 2018 [Page 1] =0C Internet-Draft J-Pref DIO February 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC7554] describes the use of the time-slotted channel hopping (TSCH) mode of [ieee802154]. [I-D.ietf-6tisch-minimal-security] and [I-D.ietf-6tisch-dtsecurity-secure-join] describe mechanisms by which a new node (the "pledge)" can use a friendly router as a Join Proxy. [I-D.richardson-6tisch-join-enhanced-beacon] describes an extension to the 802.15.4 Enhanced Beacon that is used by a Join Proxy to announce its existence such that Pledges can find them. It has become clear that not every routing member of the mesh ought to announce itself as a Join Proxy. There are a variety of local reasons by which a 6LR might not want to provide the Join Proxy function. They include available battery power, already committed network bandwidth, and also total available memory available for Join proxy neighbor cache slots. There are other situations where the operator of the network would like to selective enable or disable the join process in a particular DODAG. As the join process involves permitting unencrypted traffic into the best effort part of a (TSCH) network, it would be better to have the join process off when no new nodes are expected. A network operator might also be able to recognize when certain parts of the network are overloaded and can not accomodate additional join traffic, and it would like to adjust the join priority among all nodes in the subtree of a congested link. [GP] It MUST be in a centralized manner by a network operator? A node = itself can not decide if it is or not overloaded (in terms of available = bandwidth) and, thus, we may have less additional control traffic in the = network? Richardson Expires August 6, 2018 [Page 2] =0C Internet-Draft J-Pref DIO February 2018 This document describes an RPL DIO option that can be used to announce a minimum join priority. 1.1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant STuPiD implementations. In addition, the terminology of [I-D.ietf-6tisch-terminology] and from [I-D.ietf-anima-voucher] are used. 2. Protocol Definition The following option is defined to transmission in the DIO issued by the DODAG root. It may also be added by a router on part of the sub- tree as a result of some (out of scope for this document) management function. [GP] When such DIO Option will be issued? What would be the trigger? 6LRs that see this DIO Option SHOULD increment the minimum priority if they observe congestion on the channel used for join traffic. (TODO: how much? Do we need to standardize this?) [GP] On the channel, I assume you mean the radio channel?=20 [GP] Shouldn=E2=80=99t be the link congestion, instead of radio channel? = I mean, a link between A and B can be congested, independently the radio = channel. A 6LR which would otherwise be willing to act as a Join Proxy, will examine the minimum priority field, and to that number, add any additional local consideration (such as upstream congestion). The resulting priority, if less than 0x7f should enable the Join Proxy function. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D TBD01|Opt Length =3D 1|R| min. priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ min.priority a 7 bit field which provides a base value for the Enhanced Beacon Join priority. A value of 0x7f (127) disables the Join Proxy function entirely. R a reserved bit that SHOULD be set to 0 by senders, and MUST be ignored by receivers. The reserved bit SHOULD be copied to options created. [GP] I assume this is the DIO Option field, i.e., DAGMC type? Richardson Expires August 6, 2018 [Page 3] =0C Internet-Draft J-Pref DIO February 2018 3. Security Considerations As per [RFC7416], RPL control frames either run over a secured layer 2, or use the [RFC6550] Secure DIO methods. This option can be placed into either a "clear" (layer-2 secured) DIO, or a layer-3 Secure DIO. As such this option will have both integrity and confidentiality mechanisms applied to it. A malicious node (that was part of the RPL control plane) could see these options and could, based upon the observed minimal join priority signal a confederate that it was a good time to send malicious join traffic. A malicious node (that was part of the RPL control plane) could also send DIOs with a different minimal join priority which would cause downstream mesh routers to change their Join Proxy behaviour. Lower minimal priorities would cause downstream nodes to accept more pledges than the network was expecting, and higher minimal priorities cause the join process to stall. The use of layer-2 or layer-3 security for RPL control messages prevents the above two attacks. 4. Privacy Considerations There are no new privacy issues caused by this extension. 5. IANA Considerations Allocate a new number TBD01 from Registry RPL Control Message Options. This entry should be called Minimum Join Priority. 6. Acknowledgements none so far. 7. References 7.1. Normative References [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", draft-ietf- 6tisch-minimal-security-04 (work in progress), October 2017. Richardson Expires August 6, 2018 [Page 4] =0C Internet-Draft J-Pref DIO February 2018 [I-D.richardson-6tisch-join-enhanced-beacon] Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational Element encapsulation of 6tisch Join Information", draft- richardson-6tisch-join-enhanced-beacon-03 (work in progress), January 2018. [ieee802154] IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- Rate Wireless Personal Area Networks (WPANs)", 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . 7.2. Informative References [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work in progress), November 2017. [I-D.ietf-6tisch-dtsecurity-secure-join] Richardson, M., "6tisch Secure Join protocol", draft-ietf- 6tisch-dtsecurity-secure-join-01 (work in progress), February 2017. Richardson Expires August 6, 2018 [Page 5] =0C Internet-Draft J-Pref DIO February 2018 [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-09 (work in progress), June 2017. [I-D.ietf-anima-voucher] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "Voucher Profile for Bootstrapping Protocols", draft-ietf- anima-voucher-07 (work in progress), January 2018. [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, . Appendix A. Change history version 00. Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires August 6, 2018 [Page 6] --Apple-Mail=_3BAF596B-2314-429D-8474-65B354D6A873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Michael,

I have some (maybe minor) comments on = draft-richardson-6tisch-roll-enrollment-priority-00 draft.

Best,
Georgios

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Georgios = Z. Papadopoulos, Ph.D.
Associate Professor, IMT = Atlantique

web:   www.georgiospapadopoulos.com
twitter:  @gzpapadopoulos
=E2=80=94=E2=80=94
Consider to submit = @AdHoc-Now 2018
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94


6lo Working Group                                          M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Informational                         February 02, 2018
Expires: August 6, 2018


           Enabling secure network enrollment in RPL networks
          draft-richardson-6tisch-roll-enrollment-priority-00

Abstract

   [I-D.richardson-6tisch-join-enhanced-beacon] defines a method by
   which a potential [I-D.ietf-6tisch-minimal-security] can announce
   itself as a available for new Pledges to Join a network.  The
   announcement includes a priority for join.  This document provides a
   mechanism by which a RPL DODAG root can disable join announcements,
   or adjust the base priority for join operation.

Status of This Memo

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

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

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

   This Internet-Draft will expire on August 6, 2018.

Copyright Notice

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

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




Richardson               Expires August 6, 2018                 [Page 1]
=0C
Internet-Draft                 J-Pref DIO                  February 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change history . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [RFC7554] describes the use of the time-slotted channel hopping
   (TSCH) mode of [ieee802154].  [I-D.ietf-6tisch-minimal-security] and
   [I-D.ietf-6tisch-dtsecurity-secure-join] describe mechanisms by which
   a new node (the "pledge)" can use a friendly router as a Join Proxy.
   [I-D.richardson-6tisch-join-enhanced-beacon] describes an extension
   to the 802.15.4 Enhanced Beacon that is used by a Join Proxy to
   announce its existence such that Pledges can find them.

   It has become clear that not every routing member of the mesh ought
   to announce itself as a Join Proxy.  There are a variety of local
   reasons by which a 6LR might not want to provide the Join Proxy
   function.  They include available battery power, already committed
   network bandwidth, and also total available memory available for Join
   proxy neighbor cache slots.

   There are other situations where the operator of the network would
   like to selective enable or disable the join process in a particular
   DODAG.

   As the join process involves permitting unencrypted traffic into the
   best effort part of a (TSCH) network, it would be better to have the
   join process off when no new nodes are expected.

   A network operator might also be able to recognize when certain parts
   of the network are overloaded and can not accomodate additional join
   traffic, and it would like to adjust the join priority among all
   nodes in the subtree of a congested link.

[GP] It MUST be in =
a centralized manner by a network operator? A node itself can not =
decide if it is or not overloaded (in terms of available bandwidth) and, =
thus, we may have less additional control traffic in the =
network?

Richardson               Expires August 6, 2018                 [Page 2]
=0C
Internet-Draft                 J-Pref DIO                  February 2018


   This document describes an RPL DIO option that can be used to
   announce a minimum join priority.

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant STuPiD
   implementations.

   In addition, the terminology of [I-D.ietf-6tisch-terminology] and
   from [I-D.ietf-anima-voucher] are used.

2.  Protocol Definition

   The following option is defined to transmission in the DIO issued by
   the DODAG root.  It may also be added by a router on part of the sub-
   tree as a result of some (out of scope for this document) management
   function.
[GP] =
When such DIO Option will be issued? What would be the =
trigger?

   =
6LRs that see this DIO Option SHOULD increment the minimum =
priority
   if they observe congestion on the channel used for join =
traffic.
   (TODO: how much?  Do we need to standardize this?)
[GP] On the channel, I assume you mean the radio channel? =

[GP] =
Shouldn=E2=80=99t be the link congestion, instead of radio channel? I =
mean, a link between A and B can be congested, independently the radio =
channel.


   A 6LR which would otherwise be willing to act as a Join Proxy, will
   examine the minimum priority field, and to that number, add any
   additional local consideration (such as upstream congestion).  The
   resulting priority, if less than 0x7f should enable the Join Proxy
   function.
       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type =3D TBD01|Opt Length =3D 1|R| min. priority  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   min.priority  a 7 bit field which provides a base value for the
      Enhanced Beacon Join priority.  A value of 0x7f (127) disables the
      Join Proxy function entirely.

   R  a reserved bit that SHOULD be set to 0 by senders, and MUST be
      ignored by receivers.  The reserved bit SHOULD be copied to
      options created.


[GP] I assume this =
is the DIO Option field, i.e., DAGMC type?








Richardson               Expires August 6, 2018                 [Page 3]
=0C
Internet-Draft                 J-Pref DIO                  February 2018


3.  Security Considerations

   As per [RFC7416], RPL control frames either run over a secured layer
   2, or use the [RFC6550] Secure DIO methods.  This option can be
   placed into either a "clear" (layer-2 secured) DIO, or a layer-3
   Secure DIO.  As such this option will have both integrity and
   confidentiality mechanisms applied to it.

   A malicious node (that was part of the RPL control plane) could see
   these options and could, based upon the observed minimal join
   priority signal a confederate that it was a good time to send
   malicious join traffic.

   A malicious node (that was part of the RPL control plane) could also
   send DIOs with a different minimal join priority which would cause
   downstream mesh routers to change their Join Proxy behaviour.  Lower
   minimal priorities would cause downstream nodes to accept more
   pledges than the network was expecting, and higher minimal priorities
   cause the join process to stall.

   The use of layer-2 or layer-3 security for RPL control messages
   prevents the above two attacks.

4.  Privacy Considerations

   There are no new privacy issues caused by this extension.

5.  IANA Considerations

   Allocate a new number TBD01 from Registry RPL Control Message
   Options.  This entry should be called Minimum Join Priority.

6.  Acknowledgements

   none so far.

7.  References

7.1.  Normative References

   [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Minimal Security Framework for 6TiSCH", draft-ietf-
              6tisch-minimal-security-04 (work in progress), October
              2017.






Richardson               Expires August 6, 2018                 [Page 4]
=0C
Internet-Draft                 J-Pref DIO                  February 2018


   [I-D.richardson-6tisch-join-enhanced-beacon]
              Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of 6tisch Join Information", draft-
              richardson-6tisch-join-enhanced-beacon-03 (work in
              progress), January 2018.

   [ieee802154]
              IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
              Rate Wireless Personal Area Networks (WPANs)", 2015,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
              <https://www.rfc-editor.org/info/rfc7416>.

   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
              Internet of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,
              <https://www.rfc-editor.org/info/rfc7554>.

7.2.  Informative References

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
              in progress), November 2017.

   [I-D.ietf-6tisch-dtsecurity-secure-join]
              Richardson, M., "6tisch Secure Join protocol", draft-ietf-
              6tisch-dtsecurity-secure-join-01 (work in progress),
              February 2017.




Richardson               Expires August 6, 2018                 [Page 5]
=0C
Internet-Draft                 J-Pref DIO                  February 2018


   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-terminology-09 (work in
              progress), June 2017.

   [I-D.ietf-anima-voucher]
              Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "Voucher Profile for Bootstrapping Protocols", draft-ietf-
              anima-voucher-07 (work in progress), January 2018.

   [RFC8137]  Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
              Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
              2017, <https://www.rfc-editor.org/info/rfc8137>.

Appendix A.  Change history

   version 00.

Author's Address

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca


























Richardson               Expires August 6, 2018                 [Page =
6]





= --Apple-Mail=_3BAF596B-2314-429D-8474-65B354D6A873-- From nobody Tue Feb 20 04:45:16 2018 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 1DCF3127599 for ; Tue, 20 Feb 2018 04:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyyBTUn16Iag for ; Tue, 20 Feb 2018 04:45:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436F7127522 for ; Tue, 20 Feb 2018 04:45:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DE35720091 for ; Tue, 20 Feb 2018 07:52:29 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5ABB380C60 for ; Tue, 20 Feb 2018 07:45:11 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <8E803AE8-AC86-4C08-8820-6DF27BE5F038@imt-atlantique.fr> References: <8E803AE8-AC86-4C08-8820-6DF27BE5F038@imt-atlantique.fr> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Comments on [draft-richardson-6tisch-roll-enrollment-priority-00] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 12:45:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Georgios Z. Papadopoulos wrote: > I have some (maybe minor) comments on > draft-richardson-6tisch-roll-enrollment-priority-00 draft. It would be great if you has used Usenet > quoting, and just left the parts= of the document which you wanted to comment on. I have reformatted for the list, without answering anything yet. > A network operator might also be able to recognize when certain parts > of the network are overloaded and can not accomodate additional join > traffic, and it would like to adjust the join priority among all > nodes in the subtree of a congested link. =20=20=20=20 GP> It MUST be in a centralized manner by a network operator?=C2=A0A no= de GP> itself can not decide if it is or not overloaded (in terms of GP> available bandwidth) and, thus, we may have less additional control GP> traffic in the network?=20 > The following option is defined to transmission in the DIO issued by > the DODAG root. It may also be added by a router on part of the sub- > tree as a result of some (out of scope for this document) management > function. =20=20=20=20 GP> When such DIO Option will be issued? What would be the trigger? > 6LRs that see this DIO Option SHOULD increment the minimum priority > if they observe congestion on the channel used for join traffic. > (TODO: how much? Do we need to standardize this?) =20=20=20=20 GP> On the channel, I assume you mean the radio channel?=20 GP> Shouldn=E2=80=99t be the link congestion, instead of radio channel?= I mean, a GP> link between A and B can be congested, independently the radio GP> channel.=20 > A 6LR which would otherwise be willing to act as a Join Proxy, will > examine the minimum priority field, and to that number, add any > additional local consideration (such as upstream congestion). The > resulting priority, if less than 0x7f should enable the Join Proxy > function. > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D TBD01|Opt Length =3D 1|R| min. priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > min.priority a 7 bit field which provides a base value for the > Enhanced Beacon Join priority. A value of 0x7f (127) disables the > Join Proxy function entirely. > R a reserved bit that SHOULD be set to 0 by senders, and MUST be > ignored by receivers. The reserved bit SHOULD be copied to > options created. GP> I assume this is the DIO Option field, i.e., DAGMC type? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqMGFYACgkQgItw+93Q 3WV6XQgArIrGCyBtS0yINhdIsW+yrkfdww9c/XfRVJlpY66rTBT6OfG6fOct0Dan xZtjDZxj3hgyh17HRgIWm51AX1XVddaWxRC4+oS7KpIwA2ndlGtBlS9vdo7EpuyH LjiDZyfRgTL9jfdiU7+TBySRiCAHvBK/bH1P6Rf0MbIOGwOpqjkEb92YDZK9LT+R RIkJEk+vwGl0r3Wi7ijJujCszJ13itv0ofYY9Xby6XIhM+FDv874oX+d/N8ViXbp Ok8xVVLMzEVCcfoJ4a2w9UgxuP3IaeCSRc7yI0AnrVGYSO1RqUFzTRV9jf6nicY4 /11kVPnouUCuC2lHK56KOpHXELxrtw== =tY9J -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 21 01:24:38 2018 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 4BC8A12E889; Wed, 21 Feb 2018 01:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zyskfGDoxxah; Wed, 21 Feb 2018 01:24:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0297120047; Wed, 21 Feb 2018 01:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7859; q=dns/txt; s=iport; t=1519205075; x=1520414675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n2sm2CxH25lXbJI/I8OAYriIEulCTidAoR4/XdbjlX4=; b=HrlZAglWrlWI8Sp8zvEO//L2/Sramva2v0Yuv3vSGTo9L9tNugsbSCkb ercS2uNh21ompXkkaSqyg5KK868V+mIMc0hGY+1AVaoMCmESAFI4y8Elj XLCWw9N/TfkQhfh03krzGuUawcBstgYay/UBMK/uTUk4QhLUNl5WHzEU+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQD2OY1a/4YNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAogyZCiiWNdoFbJ4EXkG2FXBSCAgolhQ8CGoJYVBg?= =?us-ascii?q?BAgEBAQEBAQJrKIUkBgwXVAIQAgEGFAIrAwICAjAUAwQKAgQOBYk/ZBCMZJ1?= =?us-ascii?q?0gieFAIN9ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhQ6CJ4FXghAMgnmDMAE?= =?us-ascii?q?BAgEBF4EeFToJFgiCWTGCNAWSVJFkCQKIJI1mgiBnhUKEFodkixmCcIluAhE?= =?us-ascii?q?ZAYE7AQ8QOYFRcBUZSwGCGAmEbXgBjHsBAQE?= X-IronPort-AV: E=Sophos;i="5.46,543,1511827200"; d="scan'208,217";a="361562910" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 09:24:34 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1L9OY90020511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2018 09:24:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Feb 2018 03:24:34 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Wed, 21 Feb 2018 03:24:34 -0600 From: "Pascal Thubert (pthubert)" To: ROLL WG CC: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacf Date: Wed, 21 Feb 2018 09:24:34 +0000 Message-ID: <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> In-Reply-To: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_0507EB1B3B424108A511EEE413CF0FE4ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 09:24:37 -0000 --_000_0507EB1B3B424108A511EEE413CF0FE4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwNCg0KVGhpcyBpcyBhIHNob3J0IGRyYWZ0LCBidXQgdGhlIHdvcmsgaXMgbXVjaCBu ZWVkZWQgdG8gY29tcGxldGUgdGhlIFJQTCBzdG9yeSBvbiBub24tUlBMLWF3YXJlIGxlYXZlcy4g VGhlIGRyYWZ0IGNvbmZvcm1zIHRvIHRoZSBsb25nLXN0YW5kaW5nIGV4cGVjdGF0aW9ucyBmcm9t IHRoZSA2VGlTQ0ggYXJjaGl0ZWN0dXJlLg0KDQpQbGVhc2UgaGF2ZSBhIHJlYWQgYW5kIHByb3Zp ZGUgZmVlZGJhY2sgaWYgcG9zc2libGUgYmVmb3JlIGN1dG9mZi4gVGhpcyB3aWxsIGFsbG93IG1l IHRvIHB1Ymxpc2ggYW4gdXBkYXRlLCBzbyB3ZSBjYW4gZGlzY3VzcyBhZG9wdGlvbiBpbiBMb25k b24uDQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCkTDqWJ1dCBkdSBtZXNzYWdlIHRyYW5zZsOp csOpIDoNCg0KRXhww6lkaXRldXI6IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiAyMSBmw6l2cmllciAyMDE4IMOgIDEwOjIw OjAzIFVUQysxDQpEZXN0aW5hdGFpcmU6IFBhc2NhbCBUaHViZXJ0IDxwdGh1YmVydEBjaXNjby5j b208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+DQpPYmpldDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDIudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0w Mi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgIGRyYWZ0 LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcw0KUmV2aXNpb246ICAgIDAyDQpUaXRsZTogICAg ICAgIFJvdXRpbmcgZm9yIFJQTCBMZWF2ZXMNCkRvY3VtZW50IGRhdGU6ICAgIDIwMTgtMDItMjEN Ckdyb3VwOiAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgIDEyDQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMi50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1s ZWF2ZXMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdGh1YmVydC1yb2xsLXVuYXdhcmUt bGVhdmVzLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMg0KDQpBYnN0cmFjdDoNCiAg VGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgUkZDIDY1NTAgYW5kIFJGQyA2Nzc1IHVuaWNhc3Qg cm91dGluZw0KICBzZXJ2aWNlIGluIGEgUlBMIGRvbWFpbiB0byA2TG9XUEFOIE5EIG5vZGVzIHRo YXQgZG8gbm90IHBhcnRpY2lwYXRlDQogIHRvIHRoZSByb3V0aW5nIHByb3RvY29sLg0KDQoNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4u DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_0507EB1B3B424108A511EEE413CF0FE4ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpE ZWFyIGFsbA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyBhIHNob3J0IGRyYWZ0LCBi dXQgdGhlIHdvcmsgaXMgbXVjaCBuZWVkZWQgdG8gY29tcGxldGUgdGhlIFJQTCBzdG9yeSBvbiBu b24tUlBMLWF3YXJlIGxlYXZlcy4gVGhlIGRyYWZ0IGNvbmZvcm1zIHRvIHRoZSBsb25nLXN0YW5k aW5nIGV4cGVjdGF0aW9ucyBmcm9tIHRoZSA2VGlTQ0ggYXJjaGl0ZWN0dXJlLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIGhhdmUgYSByZWFkIGFuZCBwcm92aWRlIGZlZWRi YWNrIGlmIHBvc3NpYmxlIGJlZm9yZSBjdXRvZmYuIFRoaXMgd2lsbCBhbGxvdyBtZSB0byBwdWJs aXNoIGFuIHVwZGF0ZSwgc28gd2UgY2FuIGRpc2N1c3MgYWRvcHRpb24gaW4gTG9uZG9uLjxicj4N Cjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K UmVnYXJkcywNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCkTDqWJ1dCBkdSBtZXNzYWdlIHRyYW5zZsOpcsOpJm5ic3A7Ojxicj4NCjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxiPkV4cMOpZGl0ZXVyOjwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IDIxIGbDqXZyaWVyIDIw MTggw6AgMTA6MjA6MDMgVVRDJiM0MzsxPGJyPg0KPGI+RGVzdGluYXRhaXJlOjwvYj4gUGFzY2Fs IFRodWJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0 QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+T2JqZXQ6PC9iPiA8Yj5OZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMi50eHQ8L2I+ PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxkaXY+PHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDIudHh0PC9zcGFuPjxicj4NCjxzcGFu PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQgYW5kIHBv c3RlZCB0byB0aGU8L3NwYW4+PGJyPg0KPHNwYW4+SUVURiByZXBvc2l0b3J5Ljwvc3Bhbj48YnI+ DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtdGh1YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzPC9zcGFuPjxicj4NCjxzcGFuPlJl dmlzaW9uOiAmbmJzcDsgJm5ic3A7MDI8L3NwYW4+PGJyPg0KPHNwYW4+VGl0bGU6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1JvdXRpbmcgZm9yIFJQTCBMZWF2ZXM8L3NwYW4+PGJyPg0KPHNw YW4+RG9jdW1lbnQgZGF0ZTogJm5ic3A7ICZuYnNwOzIwMTgtMDItMjE8L3NwYW4+PGJyPg0KPHNw YW4+R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lv bjwvc3Bhbj48YnI+DQo8c3Bhbj5QYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTI8 L3NwYW4+PGJyPg0KPHNwYW4+VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC1yb2xsLXVuYXdhcmUtbGVhdmVzLTAy LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRodWJlcnQt cm9sbC11bmF3YXJlLWxlYXZlcy0wMi50eHQ8L2E+PC9zcGFuPjxicj4NCjxzcGFuPlN0YXR1czog Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC1yb2xsLXVuYXdh cmUtbGVhdmVzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVy dC1yb2xsLXVuYXdhcmUtbGVhdmVzLzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+SHRtbGl6ZWQ6ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMt MDI8L2E+PC9zcGFuPjxicj4NCjxzcGFuPkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMiI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMt MDI8L2E+PC9zcGFuPjxicj4NCjxzcGFuPkRpZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10aHViZXJ0LXJvbGwtdW5h d2FyZS1sZWF2ZXMtMDI8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5B YnN0cmFjdDo8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9u IHVwZGF0ZXMgUkZDIDY1NTAgYW5kIFJGQyA2Nzc1IHVuaWNhc3Qgcm91dGluZzwvc3Bhbj48YnI+ DQo8c3Bhbj4mbmJzcDsmbmJzcDtzZXJ2aWNlIGluIGEgUlBMIGRvbWFpbiB0byA2TG9XUEFOIE5E IG5vZGVzIHRoYXQgZG8gbm90IHBhcnRpY2lwYXRlPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZu YnNwO3RvIHRoZSByb3V0aW5nIHByb3RvY29sLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJy Pg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJy Pg0KPHNwYW4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjwvc3Bhbj48YnI+DQo8c3Bhbj51bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZyI+DQp0b29scy5pZXRmLm9yZzwvYT4uPC9zcGFuPjxicj4NCjxzcGFu Pjwvc3Bhbj48YnI+DQo8c3Bhbj5UaGUgSUVURiBTZWNyZXRhcmlhdDwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_0507EB1B3B424108A511EEE413CF0FE4ciscocom_-- From nobody Wed Feb 21 14:56:04 2018 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 A466912AAB6; Wed, 21 Feb 2018 14:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYWzjnRZyMlX; Wed, 21 Feb 2018 14:55:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176B812422F; Wed, 21 Feb 2018 14:55:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A3E420091; Wed, 21 Feb 2018 18:03:18 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1A9A780B14; Wed, 21 Feb 2018 17:55:55 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: "6tisch\@ietf.org" <6tisch@ietf.org> In-Reply-To: <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 22:55:58 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > This is a short draft, but the work is much needed to complete the RPL > story on non-RPL-aware leaves. The draft conforms to the long-standing > expectations from the 6TiSCH architecture. 1) can you add a reference for "Routing Stretch"? 2) Alternatively, the 6LN may rely on its 6LR to perform routing and forwarding on its behalf. In the context of RPL, such a 6LN is -> if you want to give an example of such a node, I think that the window smash sensor (alarm system), or the kinetically powered light switch, are two good examples. {I wish I had links to real products that actually ran RPL.} section 3: s/ Upon the renewal of a registration, this specification changes the behavior or the 6LR. / Upon the renewal of a 6lowPAN ND registration, this specification changes the behavior of the 6LR. / The rest of that paragraph is ver hard to parse. section 4: should: This document specifies a new flag in the EARO option, the 'R' flag, used by the registering node to indicate that the 6LN that performs the registration is a router and that it handles its reachability. say: This document specifies a new flag in the EARO option, the 'R' flag, used by a 6LN, when registering, to indicate that this 6LN is a router and that it will handles its own reachability. (...By sending a DAO) The rest of the document has some difficult sentences too. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqN+PoACgkQgItw+93Q 3WUVKQf/QD0J1pHJqB1CT1wRvwXK7M23thKJbZOoKIXcg/gJL0T5fYh+Hm9cioxj riR7pRnJ7ONxEzd8Ar1KUSfNGP9qyAg5LvuyDG0nUtLwx1OaJyCooVqGL7JToP4f yPl+7Bo3v2PKO/jWlHgTNfVarqa5mWzlO7dGAj2qVVSKWwK/EHLWxtQX3Zzkdkmr u7r+itb45TM++evwvIPctvvb1zALcF0x8rE32+d9whF2PSmiavcdCLYNT6SaKWl4 EtitYV3ZYr/7J/ZPNYGLjxGCajn6kl1fs36MEZmSzEunw+b9IPTq3HXPm51OxI4K sI39dpb7kqDXnNALJdtkJruG8oVBtQ== =65mw -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 21 20:30:10 2018 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 E2574129C51 for ; Wed, 21 Feb 2018 20:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WG1TnTBmYMdv for ; Wed, 21 Feb 2018 20:30:07 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47D9127076 for ; Wed, 21 Feb 2018 20:30:06 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id t82so1136693wmt.5 for ; Wed, 21 Feb 2018 20:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=N6NIg/y6lOJcX2ozHgJJu2/v6Qm/8MmhPSguTJSOud4=; b=GRHzrchphocq629g57+9THTPyKQCwJ7Sl3P6RYpz6bJ/wun1Hnp2VzAVhZdw6DB4QB TztkGQ0aw+1671x2sVU6P95xXbnNM/aJJ/yP+GNgCJRxTsSskNhooayEIAoEvWQmP8Lb FLxMZKiXZVWIKj5Q9fMFhuWnyPZRVbnq/B6PmeCRDXotBFDae1zcR6Ha6a9/PczmCYF1 2mQ7uiioEgvjvRM1rIkz2MBzUZ+hI8Kp5KW/Ic7Azo4cqUZ4u0CXiQfHlffwSM3DYVH2 V9JYVi3liVQQWVKJ+sRUD0lAGtfAdaIseO6P+spsUjAliekOeN9zaXMQx4kvk3C5zlUg k6yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N6NIg/y6lOJcX2ozHgJJu2/v6Qm/8MmhPSguTJSOud4=; b=C+jCwgvmSTIaL1VQtK/XYAiRfwn9PzheZb2XLPH9DCID12jhUENQvSc+dUGj+ztu3P x3XrKT+MCLreBkvATL8pYNpr9J55QuTET6ZK9oxGdCYQ5+JVraT7OstL26oWry2jVSDD XRaMaIBj7qmdCPuSr2PZTZAa7IIiKl7gAgogeiiV1Ffsj/W6IJD3w9F3fYd+xgc4gVAa n79gkYed4MremJxMLrnHaSkedU7RwVN3Ru8fRjHp77YjJP+PUyGVSC5JeYuiobdKVK+M 6lwGsmO0UFbtn1btFwKvgPp+lKxy29tcL7AmWzAkpGtqjLx8uqTiYuhfcNDoLhEWhJF8 ZOkw== X-Gm-Message-State: APf1xPDf2I8SgwqGnTlXJKIThYEKAQhZG26dgN1ZuhANi11I/h0Ga8sF CcS8zqT5sjeSQkrPV7AmZ1psTtZRia3rH7DlIBG4mg== X-Google-Smtp-Source: AH8x2271+aOJSyAeGFoB4+QkIOfH3zdsBFJaXndueR1DtuYPGGDyXNRVHetbCbFpAQQpXoOaDEAcFXXWiOVkkbnPPcs= X-Received: by 10.80.179.89 with SMTP id r25mr7458093edd.228.1519273805265; Wed, 21 Feb 2018 20:30:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.205.77 with HTTP; Wed, 21 Feb 2018 20:30:04 -0800 (PST) From: Rahul Jadhav Date: Thu, 22 Feb 2018 10:00:04 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="94eb2c0c3ca07abf720565c57fba" Archived-At: Subject: [Roll] DCO performance report (draft-ietf-roll-efficient-npdao) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 04:30:09 -0000 --94eb2c0c3ca07abf720565c57fba Content-Type: text/plain; charset="UTF-8" Hello All, We would like to present the performance report of route invalidation optimization as mentioned in the draft for open review. https://github.com/nyrahul/IETF_npdao_optimize/blob/master/DCO_performance_report.md Any feedback is highly appreciated. Thanks, Rahul --94eb2c0c3ca07abf720565c57fba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

We would like to present the= performance report of route invalidation optimization as mentioned in the = draft for open review.


Any feedback is highly appreciated.

Thanks,
Rahul
--94eb2c0c3ca07abf720565c57fba-- From nobody Thu Feb 22 01:06:40 2018 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 688EE12E868; Thu, 22 Feb 2018 01:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HRvj9WDT3nTF; Thu, 22 Feb 2018 01:06:38 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF2012704A; Thu, 22 Feb 2018 01:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6747; q=dns/txt; s=iport; t=1519290398; x=1520499998; h=from:to:cc:subject:date:message-id:mime-version; bh=I2OD9hCRdIJiOJLoJISilaSRDJ2yYri9V2DCzlN74b0=; b=dRp/XIHCMmA29yaPgP76oX+g3th0t0VHOpntigiUtoQPQtW40AMBkt2w GUephVmDIdbEyGN9VkjkYuDMjYC5ZzVJz9gMU05yf/nu2aso7rHhTpDmf WLN5IhchF6AzBRpa9ElB7D7S7FEMkCyV65qTfeuIlJUwLh4BV743GuYt6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQC3h45a/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadWZwMo4DjXiDGJBwhV0UggIKhTSCflQYAQIBAQEBAQECax0?= =?us-ascii?q?LhVdMEgGBACYBBA4NiTdkrTuId4ITAQEBAQEBAQECAQEBAQEBAQEBAR6FEYIng?= =?us-ascii?q?VeBZ4gZhjQFpD0JApYDgimSJIscjGACERkBgTsBHzmBUXAVgn6EdYwvgRkBAQE?= X-IronPort-AV: E=Sophos;i="5.47,377,1515456000"; d="scan'208,217";a="357292061" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 09:06:37 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1M96b2u010436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2018 09:06:37 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Feb 2018 03:06:36 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Thu, 22 Feb 2018 03:06:36 -0600 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> CC: Routing Over Low power and Lossy networks Thread-Topic: A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJg== Date: Thu, 22 Feb 2018 09:06:25 +0000 Deferred-Delivery: Thu, 22 Feb 2018 09:06:17 +0000 Message-ID: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.13] Content-Type: multipart/alternative; boundary="_000_125576e1c5164d349282ee303f8cae3dXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 09:06:39 -0000 --_000_125576e1c5164d349282ee303f8cae3dXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all : ROLL has the concept of a leaf, that is a 6LN that is not aware of RPL but = needs routing handled for it. With RPL, and probably any other route-over protocol, there is a need to si= gnal either way, i.e. the node handles its routing (like a classical RPL no= de) or the node expects that the 6LR will manage the routing on its behalf = (like a RPL leaf). The bit is IGP-agnostic, and it applies to any protocol. draft-thubert-roll-unaware-leaves suggests a bit that indicates that the 6L= R that is capable to handle its routing should signal it, so the unaware le= af does not need to set it. Q: Should the bit be defined in rfc6775-update as opposed to a ROLL since i= t is IGP agnostic? Side question: Is it the right approach or should the leaf set the bit inst= ead? Cheers, Pascal --_000_125576e1c5164d349282ee303f8cae3dXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all :<= /p>

 

ROLL has the concept of a leaf, that is a 6LN that i= s not aware of RPL but needs routing handled for it.

 

With RPL, and probably any other route-over protocol= , there is a need to signal either way, i.e. the node handles its routing (= like a classical RPL node) or the node expects that the 6LR will manage the= routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and it applies to any protocol.=

 

draft-thubert-roll-unaware-leaves suggests a bit tha= t indicates that the 6LR that is capable to handle its routing should signa= l it, so the unaware leaf does not need to set it.

 

Q: Should the bit be defined in rfc6775-update as op= posed to a ROLL since it is IGP agnostic?

 

Side question: Is it the right approach or should th= e leaf set the bit instead?

 

Cheers,

 

Pascal

 

--_000_125576e1c5164d349282ee303f8cae3dXCHRCD001ciscocom_-- From nobody Thu Feb 22 07:47:26 2018 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 2A40812E3AE; Thu, 22 Feb 2018 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=imt-atlantique.fr 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 FuKuda72kfK7; Thu, 22 Feb 2018 07:47:17 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0876A12741D; Thu, 22 Feb 2018 07:47:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id A7C5681FF3; Thu, 22 Feb 2018 16:47:15 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id kwZ_e-3ROlVN; Thu, 22 Feb 2018 16:47:14 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id C540880042; Thu, 22 Feb 2018 16:47:14 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr C540880042 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1519314434; bh=hauyT2bl5kVqatfrWSbh7PkszF1M6BlrKqKj2ca25o0=; h=Mime-Version:From:Date:Message-Id:To; b=ipwVjSftkpdHU6dLQvIFmuL7BQrJLHyLzo9XUlPTm0L6/dNqnYI5whwUd9+QJSXRU WFp3I3YBSHvsvPEJCL3/H9N2sySB3QHK6UnSiFoYUKpCrAesMhJbeuhSB64/N1GmRD auoevJGr6AWktMJUAAMnivX8AZvRe/B6RqZt8WZI= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id kii3-ov4mgUk; Thu, 22 Feb 2018 16:47:14 +0100 (CET) Received: from [IPv6:2001:4ca0::f222:ccde:9e31:8068:bd5a] (unknown [IPv6:2001:4ca0:0:f222:ccde:9e31:8068:bd5a]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 732C282003; Thu, 22 Feb 2018 16:47:14 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_77E09F34-7E19-44E4-8FFB-E568C775FA34" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Georgios Z. Papadopoulos" In-Reply-To: <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> Date: Thu, 22 Feb 2018 16:47:13 +0100 Cc: "6tisch@ietf.org" <6tisch@ietf.org> Message-Id: <3DEB8A21-2DA4-4E92-8772-23AC68C28877@imt-atlantique.fr> References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 15:47:20 -0000 --Apple-Mail=_77E09F34-7E19-44E4-8FFB-E568C775FA34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Pascal, Please find my comments below. Georgios Section 1: */ RPL also leverages Routing Stretch to reduce further the amount of = control traffic and routing state that is required to operate the protocol. GP> The concept of Routing Stretch is not clear to me. */ RPL can only provide a best effort ratability,=20 connecting most of the LLN nodes, most of the time. =20 GP> Rephrase this part of the sentence */ When a routing protocol such as RPL is used to maintain = reachability within a Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act as routers and participate to the routing operations whereas others may be plain hosts. =20 GP> Typo: subnet, Some =E2=80=94> subnet, some */ With this specification, a 6LN may declare itself as a router in the 6LoWPAN ND exchange in order to declare that it will manage it own routing. GP> The end of the sentence may need a rephrase. Section 6.3: Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR generates a DAR/DAC message upon reception of a valid NS(EARO) message for a new registration. If the exchange succeeds, then the 6LR installs a Neighbor Cache Entry (NCE). */ At this stage, and upon each NS(EARO) received afterwards that maintain the NCE in the 6LR;=20 GP> I find this sentence as repetition with the previous paragraph. Section 6.4: */ Upon reception of a DAO message that creates or updates an existing RPL state,=20 GP> maybe indicate, from whom potentially the Root receives a DAO = message Section 6.5: */ Upon reception of a DAR message with the Owner Unique ID field is set to all ones, the 6LBR checks whether and entry exists for the and computes whether the TID in the DAR message is fresher than that in the entry as prescribed in [I-D.ietf-6lo-rfc6775-update]. GP> typo: and entry =E2=80=94> an entry */ If the entry exists but is not fresher, the 6LBR does not update = the entry, and answers with a Status "Success" in the DAC message. If te entry exists and the TID in the DAR message is fresher, the 6LBR updates the TID in the entry, and if the lifetime of the entry is extended by the Registration Lifetime in the DAR message, it also updates the lifetime of the entry. In that case, the 6LBR replies with a Status "Success" in the DAC message. GP> You could replace the =E2=80=9Cfresher=E2=80=9D with recent? > On Feb 21, 2018, at 10:24, Pascal Thubert (pthubert) = wrote: >=20 > Dear all >=20 > This is a short draft, but the work is much needed to complete the RPL = story on non-RPL-aware leaves. The draft conforms to the long-standing = expectations from the 6TiSCH architecture. >=20 > Please have a read and provide feedback if possible before cutoff. = This will allow me to publish an update, so we can discuss adoption in = London. >=20 >=20 > Regards, >=20 > Pascal >=20 > D=C3=A9but du message transf=C3=A9r=C3=A9 : >=20 >> Exp=C3=A9diteur: > >> Date: 21 f=C3=A9vrier 2018 =C3=A0 10:20:03 UTC+1 >> Destinataire: Pascal Thubert > >> Objet: New Version Notification for = draft-thubert-roll-unaware-leaves-02.txt >>=20 >>=20 >> A new version of I-D, draft-thubert-roll-unaware-leaves-02.txt >> has been successfully submitted by Pascal Thubert and posted to the >> IETF repository. >>=20 >> Name: draft-thubert-roll-unaware-leaves >> Revision: 02 >> Title: Routing for RPL Leaves >> Document date: 2018-02-21 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/internet-drafts/draft-thubert-roll-unaware-leaves-02.= txt = >> Status: = https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/ = >> Htmlized: = https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-02 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-thubert-roll-unaware-leaves-02= = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-unaware-leaves-02 = = >>=20 >> Abstract: >> This specification updates RFC 6550 and RFC 6775 unicast routing >> service in a RPL domain to 6LoWPAN ND nodes that do not participate >> to the routing protocol. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_77E09F34-7E19-44E4-8FFB-E568C775FA34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Pascal,

Please find my comments = below.

Georgios

Section 1:
*/=
 RPL also leverages Routing Stretch to reduce further the amount of =
control
traffic and routing state that is required to operate the protocol.

GP> The concept of Routing Stretch is not clear to =
me.
*/ =
RPL can only provide a best effort ratability,=20
   connecting most of the LLN nodes, most of the time.  
GP> =
Rephrase this part of the sentence

*/=
   When a routing protocol such as RPL is used to maintain reachability
   within a Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act
   as routers and participate to the routing operations whereas others
   may be plain hosts.  
GP> Typo: subnet, Some =E2=80=94> subnet, =
some
*/ =
With this specification, a 6LN may declare itself as a router in the
   6LoWPAN ND exchange in order to declare that it will manage it own
   routing.
GP> The end of the sentence may need a rephrase.

Section 6.3:
   Also =
as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR
   generates a DAR/DAC message upon reception of a valid NS(EARO)
   message for a new registration.  If the exchange succeeds, then the
   6LR installs a Neighbor Cache Entry (NCE).

*/ At this stage, and upon each NS(EARO) received afterwards that
   maintain the NCE in the 6LR; 
GP> I find =
this sentence as repetition with the previous paragraph.

Section 6.4:
*/ Upon reception of a DAO message that creates or =
updates an existing
   RPL state, 
GP> maybe indicate, from whom potentially the Root =
receives a DAO message

Section 6.5:
*/ Upon =
reception of a DAR message with the Owner Unique ID field is set
   to all ones, the 6LBR checks whether and entry exists for the and
   computes whether the TID in the DAR message is fresher than that in
   the entry as prescribed in [I-D.ietf-6lo-rfc6775-update].
GP> typo: =
and entry =E2=80=94> an entry
*/   If the =
entry exists but is not fresher, the 6LBR does not update the
   entry, and answers with a Status "Success" in the DAC message.


   If te entry exists and the TID in the DAR message is fresher, the
   6LBR updates the TID in the entry, and if the lifetime of the entry
   is extended by the Registration Lifetime in the DAR message, it also
   updates the lifetime of the entry.  In that case, the 6LBR replies
   with a Status "Success" in the DAC message.


GP> You =
could replace the =E2=80=9Cfresher=E2=80=9D with recent?



On = Feb 21, 2018, at 10:24, Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:

Dear all

This is a short draft, but the work is much needed to = complete the RPL story on non-RPL-aware leaves. The draft conforms to = the long-standing expectations from the 6TiSCH architecture.

Please have a read and provide feedback if possible = before cutoff. This will allow me to publish an update, so we can = discuss adoption in London.


Regards,

Pascal

D=C3=A9but du message transf=C3=A9r=C3=A9 :

Exp=C3=A9diteur: <internet-drafts@ietf.org>
Date: 21 f=C3=A9vrier 2018 =C3=A0 10:20:03 UTC+1
Destinataire: Pascal Thubert <pthubert@cisco.com>
Objet: New Version Notification for = draft-thubert-roll-unaware-leaves-02.txt


A new version of I-D, = draft-thubert-roll-unaware-leaves-02.txt
has been successfully submitted by Pascal Thubert and = posted to the
IETF repository.

Name:       =  draft-thubert-roll-unaware-leaves
Revision:    02
Title:        Routing for RPL = Leaves
Document date:    2018-02-21
Group:        Individual = Submission
Pages:        12
URL: =            https://www.ietf.org/internet-drafts/draft-thubert-roll-unaware= -leaves-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-lea= ves/
Htmlized:       https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves-0= 2
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-unawar= e-leaves-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-unaware-= leaves-02

Abstract:
  This specification updates RFC 6550 and RFC = 6775 unicast routing
  service in a RPL domain to 6LoWPAN ND nodes = that do not participate
  to the routing protocol.




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

The IETF Secretariat

_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

= --Apple-Mail=_77E09F34-7E19-44E4-8FFB-E568C775FA34-- From nobody Thu Feb 22 08:56:52 2018 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 ECA9E12D874; Thu, 22 Feb 2018 08:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IUcfAqxj5qC; Thu, 22 Feb 2018 08:56:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7736112D7F6; Thu, 22 Feb 2018 08:56:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F87820091; Thu, 22 Feb 2018 12:04:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C34D80BE5; Thu, 22 Feb 2018 11:56:44 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: "6lo\@ietf.org" <6lo@ietf.org> In-Reply-To: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 16:56:47 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > With RPL, and probably any other route-over protocol, there is a need > to signal either way, i.e. the node handles its routing (like a > classical RPL node) or the node expects that the 6LR will manage the > routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and > it applies to any protocol. > draft-thubert-roll-unaware-leaves suggests a bit that indicates that > the 6LR that is capable to handle its routing should signal it, so the > unaware leaf does not need to set it. This *is* a new change to existing devices. > Q: Should the bit be defined in rfc6775-update as opposed to a ROLL > since it is IGP agnostic? > Side question: Is it the right approach or should the leaf set the bit > instead? I think it depends upon whether the leaf is a legacy device. We can't just plug a Windows7 PC into an arbitrary 802.15.4 network, because there generally aren't drivers. So there really isn't a legacy question. We almost always are creating new code, in which case we can create code which sets a bit which says, "Please manage my routing for me". This is not a burden, because such leaf devices do not really exist yet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqO9kwACgkQgItw+93Q 3WUoMAf9HnyJhFrbpJoWocXKU56OMm8fDcL6AYghUdoGukBfnFvFOYqGKH3Jfr3B IOr+bvkvM38Fens7oyJz/9dsX6mSWIIiQSUSMzA3OnWbmocIqWW7xD8Nz6L9zoGp t4skYgHgPOU28Lu1Hkwf4YTO9fCl7EO4KQwJv1qH1dIPke0IrncZuzAlm840fC8I Gvr2TzrPG3I6YMLa0LpPtjBUy0DPx+xiofa6nJ2KhmPYUW5GeAS07ef/dOBcIHhb CNRx1QFCXpYNXDKeBJh6ghnyvzcIyZLdFK4otfxeXl691TsIsGpYfztiM3aM3LrY pP3U3/RqaArxlcgNOWxdXi+g4Wm28g== =2Mgx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 22 09:11:20 2018 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 6DC0212D878; Thu, 22 Feb 2018 09:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jFwBD5QIc1Gt; Thu, 22 Feb 2018 09:11:14 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F3A1275AB; Thu, 22 Feb 2018 09:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2062; q=dns/txt; s=iport; t=1519319474; x=1520529074; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zS6sPKXuzpAm6eJBv/z4dd/UuGwCFUjbtM4hmj4exMQ=; b=OAeCX2vhyDkpdPxlf+ZxjbyXvKIMNNCsHfqxKsPDGAeuyvmfVhFOQ7lZ XvLmVGaVvinO6T/B9918ZqmSG8Ka8AoIiwVJtmV4YMS4WqtdimcqV7enp zxB80uIy7kyVzGUsVVV1IWsbRqocGhV0CakIVYmbrFTKlcpP2yUxJhlJB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAACO+I5a/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPgVYoCo4DjXyCAoEWlk6CFgqCAYMzAoIuVBgBAgEBAQEBAQJ?= =?us-ascii?q?rHQuFIwEBAQMBeQwEAgEIEQQBAQEnBzIUCQgBAQQOBQiKEwitQoh2ghcBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhRmCJ4FXgWeDLoUHhhgFkyORHAkClgOCKYYoi3y?= =?us-ascii?q?LHIxhAhEZAYE7AR85gVFwFYJ9hHZ4jBaBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,378,1515456000"; d="scan'208";a="73939711" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 17:11:13 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1MHBD6L019859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2018 17:11:13 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Feb 2018 11:11:13 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Thu, 22 Feb 2018 11:11:12 -0600 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgAdvzEAAAw66hA= Date: Thu, 22 Feb 2018 17:10:44 +0000 Deferred-Delivery: Thu, 22 Feb 2018 17:10:22 +0000 Message-ID: <9276c0e92d11479c9127f6b656f071c9@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <28405.1519318604@obiwan.sandelman.ca> In-Reply-To: <28405.1519318604@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.196.151] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 17:11:15 -0000 Hello Michael I understand that you suggest to reverse the bit from my draft, so that it= is set by a leaf that does not support its own routing. I agree that this minimizes the changes to the existing. But also this mean= s that I should change RFC6775-update to specify that. I'm happy with that approach and will do it if the WG does not disagree. Wh= at do others think? Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: jeudi 22 f=E9vrier 2018 17:57 To: Routing Over Low power and Lossy networks Cc: 6lo@ietf.org Subject: Re: [Roll] A bit for ROLL Pascal Thubert (pthubert) wrote: > With RPL, and probably any other route-over protocol, there is a need > to signal either way, i.e. the node handles its routing (like a > classical RPL node) or the node expects that the 6LR will manage the > routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and > it applies to any protocol. > draft-thubert-roll-unaware-leaves suggests a bit that indicates that > the 6LR that is capable to handle its routing should signal it, so th= e > unaware leaf does not need to set it. This *is* a new change to existing devices. > Q: Should the bit be defined in rfc6775-update as opposed to a ROLL > since it is IGP agnostic? > Side question: Is it the right approach or should the leaf set the bi= t > instead? I think it depends upon whether the leaf is a legacy device. We can't just plug a Windows7 PC into an arbitrary 802.15.4 network, becaus= e there generally aren't drivers. So there really isn't a legacy question. We almost always are creating new code, in which case we can create code wh= ich sets a bit which says, "Please manage my routing for me". This is not a burden, because such leaf devices do not really exist yet. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Feb 22 15:00:35 2018 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 4378512711A; Thu, 22 Feb 2018 15:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zab-nJO7-rK; Thu, 22 Feb 2018 15:00:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20068126B6D; Thu, 22 Feb 2018 15:00:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E81C20091; Thu, 22 Feb 2018 18:07:52 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2BE0D80B14; Thu, 22 Feb 2018 18:00:25 -0500 (EST) From: Michael Richardson To: "6lo\@ietf.org" <6lo@ietf.org>, Routing Over Low power and Lossy networks In-Reply-To: <9276c0e92d11479c9127f6b656f071c9@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <28405.1519318604@obiwan.sandelman.ca> <9276c0e92d11479c9127f6b656f071c9@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] [6lo] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 23:00:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > I understand that you suggest to reverse the bit from my draft, so > that it is set by a leaf that does not support its own routing. Exactly. > I agree that this minimizes the changes to the existing. But also this > means that I should change RFC6775-update to specify that. > I'm happy with that approach and will do it if the WG does not > disagree. What do others think? > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richar= dson > Sent: jeudi 22 f=C3=A9vrier 2018 17:57 > To: Routing Over Low power and Lossy networks > Cc: 6lo@ietf.org > Subject: Re: [Roll] A bit for ROLL > Pascal Thubert (pthubert) wrote: >> With RPL, and probably any other route-over protocol, there is a need >> to signal either way, i.e. the node handles its routing (like a >> classical RPL node) or the node expects that the 6LR will manage the >> routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and >> it applies to any protocol. >> draft-thubert-roll-unaware-leaves suggests a bit that indicates that >> the 6LR that is capable to handle its routing should signal it, so t= he >> unaware leaf does not need to set it. > This *is* a new change to existing devices. >> Q: Should the bit be defined in rfc6775-update as opposed to a ROLL >> since it is IGP agnostic? >> Side question: Is it the right approach or should the leaf set the b= it >> instead? > I think it depends upon whether the leaf is a legacy device. > We can't just plug a Windows7 PC into an arbitrary 802.15.4 network, = because there generally aren't drivers. So there really isn't a legacy que= stion. > We almost always are creating new code, in which case we can create c= ode which sets a bit which says, "Please manage my routing for me". > This is not a burden, because such leaf devices do not really exist y= et. > -- > Michael Richardson , Sandelman Software Works = -=3D IPv6 IoT consulting =3D- =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqPS4gACgkQgItw+93Q 3WVzUggAkggnSMotmq3uzHKNryOOcQHHXW/IJt+dLmAJHlgA3F96HDr2s7f0sqac zgrokw9bY8gutUwNhd6E26XqQbLmE3Lb1qKFL0Lyf5veNeAYULgptpa1lhlFBfBL /0J7pqg13s7vZwONkBZw6y8/XFdrVUYWUQF94R3Igoxft8mYyTciL8DZIrWwNAcW flIAxsStcJ1wMC8p5VxCk9rMuSonF1iGwmt7Npd9VZqEyGHSo5/O13B4O7iGqNPP aIikhCN1DQIOwIxDnzL51FnidEl/jZOlVcN6fHjP7H5eMrFTA3qzNQqNpMut/Vk2 E5zNFBQEwUZRBrHzMbnnIxRo6WvUBA== =0b6H -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 22 15:30:16 2018 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 7EF6A12D775 for ; Thu, 22 Feb 2018 15:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kczi1bst3yXR for ; Thu, 22 Feb 2018 15:30:13 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D26127735 for ; Thu, 22 Feb 2018 15:30:13 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id w38so6226467ota.8 for ; Thu, 22 Feb 2018 15:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=IXIz0iySbXBkPgdTBuwUyjjrbAGFTEpQSn7SZf5evLU=; b=t+vzxJMk6mqiFxBWfCYynUkjLALED8f5NyLVrpJRszZnW4GXh0t/mnZTc627ZbcVeD RvsDjbzcsgJsvhxib0igMOcuL7Q4fsDHuMgOImIryl7RTLzrH4uuDL6AJruP9C3uEr2w 5h/A63C0n9kWPuyPWCgVgYZx+zC1GKNbnZt2GJeLJsqPa0ZajBddg56jBR0PiMfF5nqJ qZGqvIpjq8ZjAe91B5Cj1+/d1RsGarcGvW2J7Ko2xFthTbpsFtueNPWPNLA/Z4VpCoPc Grblv7A0lSRyhEUj1k1lyCkMdfHI6k+dmZ7bv3FV0+gt93g9OLbu7XsMw38+LDHUXTw0 p1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=IXIz0iySbXBkPgdTBuwUyjjrbAGFTEpQSn7SZf5evLU=; b=ZxJQBzcU89DslsoLA5Q97IwAWqN14NiikHbAO/N73sO5AMVsSCWDZhhPYn0bPgvWde m+BGsmleQBVk7ZRDH+Eyh0rPqQCM73CW2zVVTBfIxJXRPP6t48mf1T0aFylHTeGo6/e+ iLO8KJ4oi6e/dFi7s/ObIKUoXUK8Pq+JGzGJsYpGM8cYm3NTYv6L6MoT+iAHDJEpN1jK 1yE3ReeJBJKIb6zCoHA7hHSxmgmUD+JiM1267zX7+FMsWKteOlKtGLfyGrayev+0kOZk m+UEe4TPA11VtYPrr46wm6bre83K64NaJ6axF55GvsxrgjORveWYd6anpxZ7LI0n3Zdi YB6g== X-Gm-Message-State: APf1xPB/kRSsHH6NA0R+Feprku65+uh91c/Tvnj6VOxfZbAVpBTa4cU/ l569s9Gk2HFNX0dq3qbJ2s2JcvjlkMJW8/2Mz3g= X-Google-Smtp-Source: AG47ELsSAubf/oXCqEQahCG04rQwczI62Oz7iRnT3U4GyxLBUwwjXKSB/VBZmzypywxkZz7xJS5sbvg+b054xSIHn3E= X-Received: by 10.157.55.136 with SMTP id x8mr6204744otb.114.1519342211532; Thu, 22 Feb 2018 15:30:11 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 Feb 2018 15:30:10 -0800 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 22 Feb 2018 15:30:10 -0800 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary="94eb2c000cfecf8bb40565d56c8a" Archived-At: Subject: [Roll] Fwd: Last Call: (An Update to 6LoWPAN ND) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 23:30:15 -0000 --94eb2c000cfecf8bb40565d56c8a Content-Type: text/plain; charset="UTF-8" FYI... On February 20, 2018 at 1:13:19 PM, The IESG (iesg-secretary@ietf.org) wrote: The IESG has received a request from the IPv6 over Networks of Resource-constrained Nodes WG (6lo) to consider the following document: - 'An Update to 6LoWPAN ND' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ballot/ No IPR declarations have been submitted directly on this I-D. --94eb2c000cfecf8bb40565d56c8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FYI...

On Febru= ary 20, 2018 at 1:13:19 PM, The IESG (iesg-secretary@ietf.org) wrote:


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document:= - 'An
Update to 6LoWPAN ND'
<draft-ietf-6lo-rfc6775-update-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits f= inal
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 201= 8-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In = either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
clarify the role of the protocol as a registration technique,
simplify the registration operation in 6LoWPAN routers, as well as t= o
provide enhancements to the registration capabilities and mobility
detection for different network topologies including the backbone
routers performing proxy Neighbor Discovery in a low power network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/= ballot/


No IPR declarations have been submitted directly on this I-D.




--94eb2c000cfecf8bb40565d56c8a-- From nobody Thu Feb 22 22:33:07 2018 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 45541124B17 for ; Thu, 22 Feb 2018 22:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 P-ooh3uB1Yok for ; Thu, 22 Feb 2018 22:33:04 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77120124234 for ; Thu, 22 Feb 2018 22:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7133; q=dns/txt; s=iport; t=1519367584; x=1520577184; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=L+VMU4Dd++fMG0praBZ+Lk1Xw6d3jdxCKF9H1w40evg=; b=WPa8cc7vIi4Wfu25VdZ/hgDPXK589GYGbgTYOxcbaiNDXrqkItOHJULB IEi702qop1g8QDi5ZxH5Q6fLE1ZdvKTTBmEiq0OcmDROnnDH5QoVL0qyH +v9tBE18Le6TNov7mooCyBy2cjG9XmmlHQGnuLpH2P2lSMP83bMQwJRkV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAQDitI9a/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadWZwKINoiiWNfIFbgT2IAYhvhV6CFgoYAQqFEAIaghRUGAE?= =?us-ascii?q?CAQEBAQEBAmsohSQCBAEBIUsbAgEGAgQ3BAMCAgIfBgsUEQIEE4k/TAMVEI4jn?= =?us-ascii?q?XSCJ4c6DYEygh4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYUYgieBV4FmKQyCeIJ?= =?us-ascii?q?qRAEBAwGBUYMzMYI0BaQLNQkCiCeIW4ULgh+GKIt9ixyCcEiJKQIRGQGBOwEfO?= =?us-ascii?q?YFRcBU6KgGCCAEPgwmBbXgRjEgBAQE?= X-IronPort-AV: E=Sophos; i="5.47,382,1515456000"; d="scan'208,217"; a="74767909" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 06:33:03 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1N6X38B020277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Feb 2018 06:33:03 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 00:33:02 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 00:33:02 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Fwd: Last Call: (An Update to 6LoWPAN ND) to Proposed Standard Thread-Index: AQHTrDUdCFazGzeuVUG8c9WCC1DUr6Oxh+V2 Date: Fri, 23 Feb 2018 06:33:02 +0000 Message-ID: <88C94073-0504-450B-B6D7-55C5C2DBECED@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_88C940730504450BB6D755C5C2DBECEDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Fwd: Last Call: (An Update to 6LoWPAN ND) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 06:33:06 -0000 --_000_88C940730504450BB6D755C5C2DBECEDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWx2YXJvIDopDQoNClllcyBJIG0gYWxyZWFkeSBnZXR0aW5nIHJldmlld3MgYW5kIHNv bHZpbmcgaXNzdWVzLiBTbyBmYXIgc28gZ29vZCDwn5iKDQoNClRha2UgY2FyZSwNCg0KUGFzY2Fs DQoNCkxlIDIzIGbDqXZyLiAyMDE4IMOgIDAwOjMwLCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmll dGZAZ21haWwuY29tPG1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0K DQpGWUkuLi4NCg0KDQpPbiBGZWJydWFyeSAyMCwgMjAxOCBhdCAxOjEzOjE5IFBNLCBUaGUgSUVT RyAoaWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc8bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3Jn Pikgd3JvdGU6DQoNClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgSVB2 NiBvdmVyIE5ldHdvcmtzIG9mDQpSZXNvdXJjZS1jb25zdHJhaW5lZCBOb2RlcyBXRyAoNmxvKSB0 byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OiAtICdBbg0KVXBkYXRlIHRvIDZMb1dQ QU4gTkQnDQo8ZHJhZnQtaWV0Zi02bG8tcmZjNjc3NS11cGRhdGUtMTEudHh0PiBhcyBQcm9wb3Nl ZCBTdGFuZGFyZA0KDQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5l eHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwNCmNvbW1lbnRzIG9uIHRoaXMgYWN0aW9u LiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8 bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAxOC0wMy0wNi4gRXhjZXB0 aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQpzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmll c2dAaWV0Zi5vcmc+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBi ZWdpbm5pbmcgb2YNCnRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcu DQoNCkFic3RyYWN0DQoNCg0KVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgUkZDIDY3NzUgLSA2 TG9XUEFOIE5laWdoYm9yIERpc2NvdmVyeSwgdG8NCmNsYXJpZnkgdGhlIHJvbGUgb2YgdGhlIHBy b3RvY29sIGFzIGEgcmVnaXN0cmF0aW9uIHRlY2huaXF1ZSwNCnNpbXBsaWZ5IHRoZSByZWdpc3Ry YXRpb24gb3BlcmF0aW9uIGluIDZMb1dQQU4gcm91dGVycywgYXMgd2VsbCBhcyB0bw0KcHJvdmlk ZSBlbmhhbmNlbWVudHMgdG8gdGhlIHJlZ2lzdHJhdGlvbiBjYXBhYmlsaXRpZXMgYW5kIG1vYmls aXR5DQpkZXRlY3Rpb24gZm9yIGRpZmZlcmVudCBuZXR3b3JrIHRvcG9sb2dpZXMgaW5jbHVkaW5n IHRoZSBiYWNrYm9uZQ0Kcm91dGVycyBwZXJmb3JtaW5nIHByb3h5IE5laWdoYm9yIERpc2NvdmVy eSBpbiBhIGxvdyBwb3dlciBuZXR3b3JrLg0KDQoNCg0KDQpUaGUgZmlsZSBjYW4gYmUgb2J0YWlu ZWQgdmlhDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1y ZmM2Nzc1LXVwZGF0ZS8NCg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bG8tcmZjNjc3NS11cGRh dGUvYmFsbG90Lw0KDQoNCk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBk aXJlY3RseSBvbiB0aGlzIEktRC4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnPG1h aWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsDQo= --_000_88C940730504450BB6D755C5C2DBECEDciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBBbHZhcm8gOikNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcyBJIG0gYWxyZWFkeSBn ZXR0aW5nIHJldmlld3MgYW5kIHNvbHZpbmcgaXNzdWVzLiBTbyBmYXIgc28gZ29vZCDwn5iKJm5i c3A7PGJyPg0KPGJyPg0KPGRpdj4NCjxkaXY+VGFrZSBjYXJlLDwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UGFzY2FsPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KTGUgMjMgZsOpdnIu IDIwMTggw6AgMDA6MzAsIEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5h LmlldGZAZ21haWwuY29tIj5hcmV0YW5hLmlldGZAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQm bmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+ PHN0eWxlPmJvZHl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4fTwv c3R5bGU+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOnJnYmEoMCwwLDAsMS4wKTttYXJnaW46 MHB4O2xpbmUtaGVpZ2h0OmF1dG8iPg0KRllJLi4uPC9kaXY+DQo8YnI+DQo8cCBjbGFzcz0iYWly bWFpbF9vbiI+T24gRmVicnVhcnkgMjAsIDIwMTggYXQgMToxMzoxOSBQTSwgVGhlIElFU0cgKDxh IGhyZWY9Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyI+aWVzZy1zZWNyZXRhcnlAaWV0 Zi5vcmc8L2E+KSB3cm90ZTo8L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iY2xl YW5fYnEiPjxzcGFuPg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pjxicj4NClRoZSBJRVNHIGhh cyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgSVB2NiBvdmVyIE5ldHdvcmtzIG9mIDxicj4N ClJlc291cmNlLWNvbnN0cmFpbmVkIE5vZGVzIFdHICg2bG8pIHRvIGNvbnNpZGVyIHRoZSBmb2xs b3dpbmcgZG9jdW1lbnQ6IC0gJ0FuIDxicj4NClVwZGF0ZSB0byA2TG9XUEFOIE5EJyA8YnI+DQom bHQ7ZHJhZnQtaWV0Zi02bG8tcmZjNjc3NS11cGRhdGUtMTEudHh0Jmd0OyBhcyBQcm9wb3NlZCBT dGFuZGFyZCA8YnI+DQo8YnI+DQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4g dGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwgPGJyPg0KY29tbWVudHMgb24g dGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZSA8YnI+ DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFpbGlu ZyBsaXN0cyBieSAyMDE4LTAzLTA2LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUNCjxi cj4NCnNlbnQgdG8gPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8 L2E+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBiZWdpbm5pbmcg b2YNCjxicj4NCnRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuIDxi cj4NCjxicj4NCkFic3RyYWN0IDxicj4NCjxicj4NCjxicj4NClRoaXMgc3BlY2lmaWNhdGlvbiB1 cGRhdGVzIFJGQyA2Nzc1IC0gNkxvV1BBTiBOZWlnaGJvciBEaXNjb3ZlcnksIHRvIDxicj4NCmNs YXJpZnkgdGhlIHJvbGUgb2YgdGhlIHByb3RvY29sIGFzIGEgcmVnaXN0cmF0aW9uIHRlY2huaXF1 ZSwgPGJyPg0Kc2ltcGxpZnkgdGhlIHJlZ2lzdHJhdGlvbiBvcGVyYXRpb24gaW4gNkxvV1BBTiBy b3V0ZXJzLCBhcyB3ZWxsIGFzIHRvIDxicj4NCnByb3ZpZGUgZW5oYW5jZW1lbnRzIHRvIHRoZSBy ZWdpc3RyYXRpb24gY2FwYWJpbGl0aWVzIGFuZCBtb2JpbGl0eSA8YnI+DQpkZXRlY3Rpb24gZm9y IGRpZmZlcmVudCBuZXR3b3JrIHRvcG9sb2dpZXMgaW5jbHVkaW5nIHRoZSBiYWNrYm9uZSA8YnI+ DQpyb3V0ZXJzIHBlcmZvcm1pbmcgcHJveHkgTmVpZ2hib3IgRGlzY292ZXJ5IGluIGEgbG93IHBv d2VyIG5ldHdvcmsuIDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBmaWxlIGNhbiBi ZSBvYnRhaW5lZCB2aWEgPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi02bG8tcmZjNjc3NS11cGRhdGUvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1yZmM2Nzc1LXVwZGF0ZS88L2E+DQo8YnI+DQo8 YnI+DQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhIDxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNmxvLXJmYzY3NzUtdXBk YXRlL2JhbGxvdC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt NmxvLXJmYzY3NzUtdXBkYXRlL2JhbGxvdC88L2E+DQo8YnI+DQo8YnI+DQo8YnI+DQpObyBJUFIg ZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuIDxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9ibG9j a3F1b3RlPg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTE5MzQyMTk4ODI0ODIwOTkyIiBjbGFzcz0i Ymxvb3Bfc2lnbiI+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5Sb2xsIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwv YT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jv bGw8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_88C940730504450BB6D755C5C2DBECEDciscocom_-- From nobody Fri Feb 23 00:57:48 2018 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 4C282126BF0; Fri, 23 Feb 2018 00:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 TKCgBd6pbBxD; Fri, 23 Feb 2018 00:57:42 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7071243FE; Fri, 23 Feb 2018 00:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3654; q=dns/txt; s=iport; t=1519376262; x=1520585862; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vBQkf4s1qQLWe8xVO/k277P2Efb81YToTqOjEMxTJrc=; b=h0ltP95yEPsAgr+zgC/7mkYn0WpOdp2EywbWZFkGmTw9bAy+1BGyRbxG 9JejygmmSnZOvBPFGyeoQfhDsfKDvslDJHLiqw5Eo6YD4fIf8k2fHF9DU X3nd+DysI8/WyiMc88nq+S1ki42QaMYFyLn2/g2iSmq5t8DIsWxKl1h0R M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAQA1149a/4gNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCoNeiiWNfIICgRaWToIWCoIBgzICGoIYVBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUjAQEBAwEjEVEEAgEIEQQBAQECAiMDAgICMBQBCAgBAQQBEgi?= =?us-ascii?q?KEwisOYIniHmCHgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4QJgieBV4Fmgy2?= =?us-ascii?q?FBYMzgmUFmjOKDQkClgSCKIYoi32LHIxhAhEZAYE7AR85gVFwFYJ9hHZ4i0C?= =?us-ascii?q?BGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,382,1515456000"; d="scan'208";a="362514431" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 08:57:24 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1N8vORh021429 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 08:57:24 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 02:57:24 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 02:57:24 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6lo@ietf.org" <6lo@ietf.org>, Routing Over Low power and Lossy networks Thread-Topic: [6lo] [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgAdvzEAAAw66hAAAHiFAAAIMXww Date: Fri, 23 Feb 2018 08:56:57 +0000 Deferred-Delivery: Fri, 23 Feb 2018 08:56:25 +0000 Message-ID: <213688faf5a84934b7c4d75625da5dbd@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <28405.1519318604@obiwan.sandelman.ca> <9276c0e92d11479c9127f6b656f071c9@XCH-RCD-001.cisco.com> <27359.1519340424@obiwan.sandelman.ca> In-Reply-To: <27359.1519340424@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.164.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6lo] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 08:57:43 -0000 T0sgVGhlbiwgSSdsbCBpbmNvcnBvcmF0ZSBhbmQgcmVmcmVzaCBpbiBib3RoIGRyYWZ0Li4uDQoN ClRha2UgY2FyZSwNCg0KUGFzY2FsDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog NmxvIFttYWlsdG86NmxvLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJp Y2hhcmRzb24NClNlbnQ6IHZlbmRyZWRpIDIzIGbDqXZyaWVyIDIwMTggMDA6MDANClRvOiA2bG9A aWV0Zi5vcmc7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xs QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFs2bG9dIFtSb2xsXSBBIGJpdCBmb3IgUk9MTA0KDQoN ClBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQog ICAgPiBJIHVuZGVyc3RhbmQgdGhhdCAgeW91IHN1Z2dlc3QgdG8gcmV2ZXJzZSB0aGUgYml0IGZy b20gbXkgZHJhZnQsIHNvDQogICAgPiB0aGF0IGl0IGlzIHNldCBieSBhIGxlYWYgdGhhdCBkb2Vz IG5vdCBzdXBwb3J0IGl0cyBvd24gcm91dGluZy4NCg0KRXhhY3RseS4NCg0KICAgID4gSSBhZ3Jl ZSB0aGF0IHRoaXMgbWluaW1pemVzIHRoZSBjaGFuZ2VzIHRvIHRoZSBleGlzdGluZy4gQnV0IGFs c28gdGhpcw0KICAgID4gbWVhbnMgdGhhdCBJIHNob3VsZCBjaGFuZ2UgUkZDNjc3NS11cGRhdGUg dG8gc3BlY2lmeSB0aGF0Lg0KICAgID4gSSdtIGhhcHB5IHdpdGggdGhhdCBhcHByb2FjaCBhbmQg d2lsbCBkbyBpdCBpZiB0aGUgV0cgZG9lcyBub3QNCiAgICA+IGRpc2FncmVlLiBXaGF0IGRvIG90 aGVycyB0aGluaz8NCg0KDQoNCg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAg ICA+IEZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNaWNoYWVsIFJpY2hhcmRzb24NCiAgICA+IFNlbnQ6IGpldWRpIDIyIGbDqXZyaWVyIDIwMTgg MTc6NTcNCiAgICA+IFRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jr cyA8cm9sbEBpZXRmLm9yZz4NCiAgICA+IENjOiA2bG9AaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6 IFJlOiBbUm9sbF0gQSBiaXQgZm9yIFJPTEwNCg0KDQogICAgPiBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3RlOg0KICAgID4+IFdpdGggUlBMLCBhbmQg cHJvYmFibHkgYW55IG90aGVyIHJvdXRlLW92ZXIgcHJvdG9jb2wsIHRoZXJlIGlzIGEgbmVlZA0K ICAgID4+IHRvIHNpZ25hbCBlaXRoZXIgd2F5LCBpLmUuIHRoZSBub2RlIGhhbmRsZXMgaXRzIHJv dXRpbmcgKGxpa2UgYQ0KICAgID4+IGNsYXNzaWNhbCBSUEwgbm9kZSkgb3IgdGhlIG5vZGUgZXhw ZWN0cyB0aGF0IHRoZSA2TFIgd2lsbCBtYW5hZ2UgdGhlDQogICAgPj4gcm91dGluZyBvbiBpdHMg YmVoYWxmIChsaWtlIGEgUlBMIGxlYWYpLiBUaGUgYml0IGlzIElHUC1hZ25vc3RpYywgYW5kDQog ICAgPj4gaXQgYXBwbGllcyB0byBhbnkgcHJvdG9jb2wuDQoNCiAgICA+PiBkcmFmdC10aHViZXJ0 LXJvbGwtdW5hd2FyZS1sZWF2ZXMgc3VnZ2VzdHMgYSBiaXQgdGhhdCBpbmRpY2F0ZXMgdGhhdA0K ICAgID4+IHRoZSA2TFIgdGhhdCBpcyBjYXBhYmxlIHRvIGhhbmRsZSBpdHMgcm91dGluZyBzaG91 bGQgc2lnbmFsIGl0LCBzbyB0aGUNCiAgICA+PiB1bmF3YXJlIGxlYWYgZG9lcyBub3QgbmVlZCB0 byBzZXQgaXQuDQoNCiAgICA+IFRoaXMgKmlzKiBhIG5ldyBjaGFuZ2UgdG8gZXhpc3RpbmcgZGV2 aWNlcy4NCg0KICAgID4+IFE6IFNob3VsZCB0aGUgYml0IGJlIGRlZmluZWQgaW4gcmZjNjc3NS11 cGRhdGUgYXMgb3Bwb3NlZCB0byBhIFJPTEwNCiAgICA+PiBzaW5jZSBpdCBpcyBJR1AgYWdub3N0 aWM/DQoNCiAgICA+PiBTaWRlIHF1ZXN0aW9uOiBJcyBpdCB0aGUgcmlnaHQgYXBwcm9hY2ggb3Ig c2hvdWxkIHRoZSBsZWFmIHNldCB0aGUgYml0DQogICAgPj4gaW5zdGVhZD8NCg0KICAgID4gSSB0 aGluayBpdCBkZXBlbmRzIHVwb24gd2hldGhlciB0aGUgbGVhZiBpcyBhIGxlZ2FjeSBkZXZpY2Uu DQoNCiAgICA+IFdlIGNhbid0IGp1c3QgcGx1ZyBhIFdpbmRvd3M3IFBDIGludG8gYW4gYXJiaXRy YXJ5IDgwMi4xNS40IG5ldHdvcmssIGJlY2F1c2UgdGhlcmUgZ2VuZXJhbGx5IGFyZW4ndCBkcml2 ZXJzLiAgU28gdGhlcmUgcmVhbGx5IGlzbid0IGEgbGVnYWN5IHF1ZXN0aW9uLg0KDQogICAgPiBX ZSBhbG1vc3QgYWx3YXlzIGFyZSBjcmVhdGluZyBuZXcgY29kZSwgaW4gd2hpY2ggY2FzZSB3ZSBj YW4gY3JlYXRlIGNvZGUgd2hpY2ggc2V0cyBhIGJpdCB3aGljaCBzYXlzLCAiUGxlYXNlIG1hbmFn ZSBteSByb3V0aW5nIGZvciBtZSIuDQogICAgPiBUaGlzIGlzIG5vdCBhIGJ1cmRlbiwgYmVjYXVz ZSBzdWNoIGxlYWYgZGV2aWNlcyBkbyBub3QgcmVhbGx5IGV4aXN0IHlldC4NCg0KICAgID4gLS0N CiAgICA+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVs bWFuIFNvZnR3YXJlIFdvcmtzICAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQoNCg0KDQotLQ0K TWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29m dHdhcmUgV29ya3MgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg== From nobody Fri Feb 23 04:19:44 2018 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 188E512D93E; Fri, 23 Feb 2018 04:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gmSom5jCPcfJ; Fri, 23 Feb 2018 04:19:34 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC9D1242F5; Fri, 23 Feb 2018 04:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3248; q=dns/txt; s=iport; t=1519388374; x=1520597974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EN4+SFjkQ7208968krR0/honNxwib+dPKyRA4vUisvg=; b=CgBIn0pRkb+q8W4ZTImgGSe9CFVu38S4PUjXw61BkPDqVoyogrLPUDRq 8SZBP/zx91KM6QRBwcWUgggshtHzbAYCXIfMxp4x/5fwJu7XuU/ShhWZP ALA6YOCKBxcaIJb4AyVkDdrUvDR5HQjkyTXE/HG6lM6ssrw3ReCntjfhr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQCkBpBa/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMYFWKAqOA418ggKBFpZRghYKggGDMgKCNVQYAQIBAQEBAQE?= =?us-ascii?q?CayiFIwEBAQMBJxM9AgULAgEINhAyJQIEDgUIihMIrgI6iHmCHgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2FGIIngVeBZoMtix0FpEIJApYFgiiSJoscjGICERkBgTs?= =?us-ascii?q?BHzmBUXAVgn2CVBwZgW14izeBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,383,1515456000"; d="scan'208";a="74334120" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 12:19:27 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w1NCJRLW030106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 12:19:27 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 06:19:26 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 06:19:27 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "Routing Over Low power and Lossy networks" CC: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacfgAFHRoCAAd4mgA== Date: Fri, 23 Feb 2018 12:19:16 +0000 Deferred-Delivery: Fri, 23 Feb 2018 10:02:48 +0000 Message-ID: References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <10405.1519253755@obiwan.sandelman.ca> In-Reply-To: <10405.1519253755@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6tisch] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 12:19:37 -0000 Hello Michael >=20 > 1) can you add a reference for "Routing Stretch"? [PT>] done, pointing on RFC 6687 > 2) Alternatively, the 6LN may rely on its 6LR to perform routing and > forwarding on its behalf. In the context of RPL, such a 6LN is >=20 > -> if you want to give an example of such a node, I think that the win= dow > smash sensor (alarm system), or the kinetically powered light switc= h, > are two good examples. > {I wish I had links to real products that actually ran RPL.} [PT>] done > section 3: > s/ Upon the renewal of a registration, this specification changes th= e > behavior or the 6LR. > / Upon the renewal of a 6lowPAN ND registration, this specification > changes the > behavior of the 6LR. / >=20 > The rest of that paragraph is ver hard to parse. >=20 [PT>] reworded as follows: " Upon the renewal of a 6lowPAN ND registration, this specification changes the behavior of the 6LR as follows. If the 'R' flag is set, the 6LR injects a DAO targeting the Registered Address, and refrains from sending a DAR message.=20 the DAR/DAC exchange that refreshes the state in the 6LBR happens instea= d=20 between the RPL Root and the 6LBR. In that flow, the RPL Root acts as a proxy on behalf of the 6LR upon the reception of the DAO propagation initiated at the 6LR. " > section 4: > should: > This document specifies a new flag in the EARO option, the 'R' flag, > used by the registering node to indicate that the 6LN that performs > the registration is a router and that it handles its reachability. >=20 > say: > This document specifies a new flag in the EARO option, the 'R' flag, > used by a 6LN, when registering, to indicate that this 6LN > is a router and that it will handles its own reachability. >=20 [PT>] Moved to the RFC 6775 update draft and updated as follows " This document makes use of the 'R' flag in the EARO option, used by a 6LN, when registering, to indicate that this 6LN is a leaf, not aware = of the RPL operation in the network, and thus does not participate to it. The behavior defined in this specification whereby the 6LR that processe= s the registration advertises the Registered Address in DAO messages and bypas= ses the DAR/DAC process for the renewal of a registration, is only triggere= d by an NS(EARO) that has the 'R' flag set. A RPL leaf SHOULD set the 'R' fla= g. =20 If the 'R' flag is not set, then the Registering Node is expected to be = a RPL router that handles the reachability of the Registered Address by itself= . This document also specifies a keep-alive EDAR message that the RPL Root= may use to maintain an existing state in the 6LBR upon receiving DAO message= s.=20 The EDAR message may only act as a refresher and can only update the Lif= etime and the TID of the state in the 6LBR. A RPL router SHOULD NOT set the '= R' flag. " > (...By sending a DAO) >=20 > The rest of the document has some difficult sentences too. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Fri Feb 23 05:45:33 2018 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 E96C11242EA; Fri, 23 Feb 2018 05:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 i3fxnHKQqKkf; Fri, 23 Feb 2018 05:45:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DAA124239; Fri, 23 Feb 2018 05:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8700; q=dns/txt; s=iport; t=1519393529; x=1520603129; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8bYlNsGXI37JAN19RKRH2C0hwxLvBAvgsRIWvW+bYXc=; b=QO5YDqMI1P7jDrtNM1S7t+j04+BeOtBNCwEE4LrXNn6DDtZabJHZX+jy FYej4/JpPjH6AX8vlhtXyiss0YtH3ZJii6ETOvTQdy/8zWc+U0gHTGaQD WG+bsNFEC/N5okJMP5KPKctcc22NVD7BhP+WpcAhRBFIzRCxr7308KSJw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQByGZBa/5tdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCoNeiiWNfIICexuWUYIWCoUzAhqCG1QYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQQjEUADAhACAQgRBAEBAwIjAwICAjAUAQgIAgQOBQiKG6t?= =?us-ascii?q?zgieIeIIeAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPhAmCJ4FXgWaCdzaFBYM?= =?us-ascii?q?zgmUFmjOKDwkCjC+JVoIohimLfYscjGICERkBgTsBHzmBUXAVgn2CVBwZgW1?= =?us-ascii?q?4izeBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,383,1515456000"; d="scan'208";a="352680310" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 13:45:28 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1NDjSYa029556 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 13:45:28 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 07:45:28 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 07:45:28 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [Roll] New Version Notification for draft-thubert-roll-unaware-leaves-02.txt Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacfgAJh04CAAPSx0A== Date: Fri, 23 Feb 2018 13:45:16 +0000 Deferred-Delivery: Fri, 23 Feb 2018 13:44:46 +0000 Message-ID: <485b1a006f824b8997ad11fd2fd006da@XCH-RCD-001.cisco.com> References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <3DEB8A21-2DA4-4E92-8772-23AC68C28877@imt-atlantique.fr> In-Reply-To: <3DEB8A21-2DA4-4E92-8772-23AC68C28877@imt-atlantique.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 13:45:32 -0000 SGVsbG8gR2Vvcmdpb3MNCg0KVGhhbmtzIGEgYnVuY2ggZm9yIHlvdXIgY29tbWVudHMsIHZlcnkg aGVscGZ1bCENCg0KUGxlYXNlIHNlZSBiZWxvdzoNCg0KRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnaW9zIFouIFBhcGFkb3BvdWxvcw0K U2VudDogamV1ZGkgMjIgZsOpdnJpZXIgMjAxOCAxNjo0Nw0KVG86IFJvdXRpbmcgT3ZlciBMb3cg cG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KQ2M6IDZ0aXNjaEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtSb2xsXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXRodWJlcnQtcm9sbC11bmF3YXJlLWxlYXZlcy0wMi50eHQNCg0KSGVsbG8gUGFzY2FsLA0K DQpQbGVhc2UgZmluZCBteSBjb21tZW50cyBiZWxvdy4NCg0KR2Vvcmdpb3MNCg0KDQpTZWN0aW9u IDE6DQoqLyBSUEwgYWxzbyBsZXZlcmFnZXMgUm91dGluZyBTdHJldGNoIHRvIHJlZHVjZSBmdXJ0 aGVyIHRoZSBhbW91bnQgb2YgY29udHJvbA0KdHJhZmZpYyBhbmQgcm91dGluZyBzdGF0ZSB0aGF0 IGlzIHJlcXVpcmVkIHRvIG9wZXJhdGUgdGhlIHByb3RvY29sLg0KDQpHUD4gVGhlIGNvbmNlcHQg b2YgUm91dGluZyBTdHJldGNoIGlzIG5vdCBjbGVhciB0byBtZS4NCltQVD5dIEkgYWRkZWQgYSBw b2ludGVyIHRvIFJGQyA2Njg3LCB0aGVyZeKAmXMgYSBsb3Qgb2YgaW5mb3JtYXRpb24gaW4gdGhl cmUuIEFsc28gYWRkaW5nIGEgc2VudGVuY2UuDQpUaGUgdGV4dCBub3cgcmVhZHMNCuKAnA0KICAg UlBMIGlzIGEgRGlzdGFuY2UtVmVjdG9yIHByb3RvY29sLCB3aGljaCwgY29tcGFyZWQgdG8gbGlu ay1zdGF0ZSBwcm90b2NvbHMsDQogICBsaW1pdHMgdGhlIGFtb3VudCBvZiB0b3BvbG9naWNhbCBr bm93bGVkZ2UgdGhhdCBuZWVkcyB0byBiZSBpbnN0YWxsZWQgYW5kIA0KICAgbWFpbnRhaW5lZCBp biBlYWNoIG5vZGUuIEluIG9yZGVyIHRvIG9wZXJhdGUgaW4gY29uc3RyYWluZWQgbmV0d29ya3Ms DQogICBSUEwgYWxsb3dzIGEgUm91dGluZyBTdHJldGNoIChzZWUgPHhyZWYgdGFyZ2V0PSJSRkM2 Njg3Ii8+KSwgd2hlcmVieSByb3V0aW5nDQogICBpcyBvbmx5IHBlcmZvcm1lZCBhbG9uZyBhIERP REFHIGFzIG9wcG9zZWQgdG8gc3RyYWlnaHQgYWxvbmcgYSBzaG9ydGVzdCBwYXRoDQogICBiZXR3 ZWVuIDIgcGVlcnMsIHdoYXRldmVyIHRoYXQgd291bGQgbWVhbiBpbiBhIGdpdmVuIExMTi4NCiAg IFRoaXMgdHJhZGVzIHRoZSBxdWFsaXR5IG9mIHBlZXItdG8tcGVlciAoUDJQKSBwYXRocyBmb3Ig YSB2YXN0bHkgcmVkdWNlZA0KICAgYW1vdW50IG9mIGNvbnRyb2wgdHJhZmZpYyBhbmQgcm91dGlu ZyBzdGF0ZSB0aGF0IHdvdWxkIGJlIHJlcXVpcmVkIHRvDQogICAgb3BlcmF0ZSBhIGFueS10by1h bnkgc2hvcnRlc3QgcGF0aCBwcm90b2NvbC4g4oCcDQoNCioqKioqKioqKioqKioqKg0KDQoqLyBS UEwgY2FuIG9ubHkgcHJvdmlkZSBhIGJlc3QgZWZmb3J0IHJhdGFiaWxpdHksIA0KICAgY29ubmVj dGluZyBtb3N0IG9mIHRoZSBMTE4gbm9kZXMsIG1vc3Qgb2YgdGhlIHRpbWUuIMKgDQpHUD4gUmVw aHJhc2UgdGhpcyBwYXJ0IG9mIHRoZSBzZW50ZW5jZQ0KW1BUPl0gRG9uZS4gVGhlIHRleHQgbm93 IHJlYWRzDQrigJwNCiAgIA0KICAgUlBMIGlzIGRlc2lnbmVkIHRvIGFkYXB0IHRvIGZ1enp5IGNv bm5lY3Rpdml0eSwgd2hlcmVieSB0aGUgcGh5c2ljYWwgdG9wb2xvZ3kNCiAgIGNhbm5vdCBiZSBl eHBlY3RlZCB0byByZWFjaCBhIHN0YWJsZSBzdGF0ZSwgd2l0aCBhIGxhenkgY29udHJvbCB0aGF0 IGNyZWF0ZXMNCiAgIHJvdXRlcyBwcm9hY3RpdmVseSBidXQgb25seSBmaXhlcyB0aGVtIHdoZW4g dGhleSBhcmUgdXNlZCBieSBhY3R1YWwgdHJhZmZpYy4NCiAgIEl0IHJlc3VsdHMgdGhhdCBSUEwg cHJvdmlkZXMgcmVhY2hhYmlsaXR5IGZvciBtb3N0IG9mIHRoZSBMTE4gbm9kZXMsIG1vc3Qgb2YN CiAgIHRoZSB0aW1lLCBidXQgZG9lcyBub3QgcmVhbGx5IGNvbnZlcmdlIGluIHRoZSBjbGFzc2lj YWwgc2Vuc2UuDQoiDQoNCiovICAgV2hlbiBhIHJvdXRpbmcgcHJvdG9jb2wgc3VjaCBhcyBSUEwg aXMgdXNlZCB0byBtYWludGFpbiByZWFjaGFiaWxpdHkNCiAgIHdpdGhpbiBhIE5vbi1Ccm9hZGNh c3QgTXVsdGktQWNjZXNzIChOQk1BKSBzdWJuZXQsIFNvbWUgbm9kZXMgbWF5IGFjdA0KICAgYXMg cm91dGVycyBhbmQgcGFydGljaXBhdGUgdG8gdGhlIHJvdXRpbmcgb3BlcmF0aW9ucyB3aGVyZWFz IG90aGVycw0KICAgbWF5IGJlIHBsYWluIGhvc3RzLiDCoA0KR1A+IFR5cG86IHN1Ym5ldCwgU29t ZSDigJQ+IHN1Ym5ldCwgc29tZQ0KW1BUPl0gRG9uZS4NCg0KKioqKioqKioqKioqKioqKioqKioN Cg0KKi8gV2l0aCB0aGlzIHNwZWNpZmljYXRpb24sIGEgNkxOIG1heSBkZWNsYXJlIGl0c2VsZiBh cyBhIHJvdXRlciBpbiB0aGUNCiAgIDZMb1dQQU4gTkQgZXhjaGFuZ2UgaW4gb3JkZXIgdG8gZGVj bGFyZSB0aGF0IGl0IHdpbGwgbWFuYWdlIGl0IG93bg0KICAgcm91dGluZy4NCkdQPiBUaGUgZW5k IG9mIHRoZSBzZW50ZW5jZSBtYXkgbmVlZCBhIHJlcGhyYXNlLg0KDQpbUFQ+XSBDaGFuZ2VkIHRv Og0KDQoiDQogICBXaXRoIHRoaXMgc3BlY2lmaWNhdGlvbiwgYSA2TE4gdGhhdCBvcGVyYXRlcyBh cyBhIExlYWYgdXNlcyB0aGUgJ1InIGZsYWcgDQogICB0byBkZWNsYXJlIGl0c2VsZiBhcyBzdWNo IGFuZCB0aGUgNkxSIHRoYXQgYWNjZXB0cyB0aGUgcmVnaXN0cmF0aW9uIHdpbGwNCiAgIGluamVj dCByb3V0aW5nIGluZm9ybWF0aW9uIG9uIGJlaGFsZiBvZiB0aGUgNkxOIGluIHRoZSBSUEwgZG9t YWluLg0KIg0KDQoqKioqKioqKioqKioqKioqKioqKg0KDQpTZWN0aW9uIDYuMzoNCiAgIEFsc28g YXMgcHJlc2NyaWJlZCBieSBbSS1ELmlldGYtNmxvLXJmYzY3NzUtdXBkYXRlXSwgdGhlIDZMUg0K ICAgZ2VuZXJhdGVzIGEgREFSL0RBQyBtZXNzYWdlIHVwb24gcmVjZXB0aW9uIG9mIGEgdmFsaWQg TlMoRUFSTykNCiAgIG1lc3NhZ2UgZm9yIGEgbmV3IHJlZ2lzdHJhdGlvbi4gIElmIHRoZSBleGNo YW5nZSBzdWNjZWVkcywgdGhlbiB0aGUNCiAgIDZMUiBpbnN0YWxscyBhIE5laWdoYm9yIENhY2hl IEVudHJ5IChOQ0UpLg0KDQoqLyBBdCB0aGlzIHN0YWdlLCBhbmQgdXBvbiBlYWNoIE5TKEVBUk8p IHJlY2VpdmVkIGFmdGVyd2FyZHMgdGhhdA0KICAgbWFpbnRhaW4gdGhlIE5DRSBpbiB0aGUgNkxS O8KgDQpHUD4gSSBmaW5kIHRoaXMgc2VudGVuY2UgYXMgcmVwZXRpdGlvbiB3aXRoIHRoZSBwcmV2 aW91cyBwYXJhZ3JhcGguDQoNCg0KDQpbUFQ+XSBSZXdvcmRlZDsgdGhlIHBvaW50IGlzIHRoYXQg dGhlcmUgaXMgdGhlIGZpcnN0IHJlZ2lzdHJhdGlvbiB3aXRoIGEgREFSIERBQyBleGNoYW5nZSBh bmQgdGhlbiB0aGUgb3RoZXJzIHdpdGhvdXQgaXQNCg0KIg0KICAgQWxzbyBhcyBwcmVzY3JpYmVk IGJ5IDx4cmVmIHRhcmdldD0iSS1ELmlldGYtNmxvLXJmYzY3NzUtdXBkYXRlIi8+LA0KICAgdGhl IDZMUiBnZW5lcmF0ZXMgYSBEQVIgbWVzc2FnZSB1cG9uIHJlY2VwdGlvbiBvZiBhIHZhbGlkIE5T KEVBUk8pDQogICBtZXNzYWdlIGZvciB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgbmV3IElQdjYgQWRk cmVzcyBieSBhIDZMTi4gSWYgdGhlIER1cGxpY2F0ZQ0KICAgQWRkcmVzcyBleGNoYW5nZSBzdWNj ZWVkcywgdGhlbiB0aGUgNkxSIGluc3RhbGxzIGEgTmVpZ2hib3IgQ2FjaGUgRW50cnkgKE5DRSku DQogICBJZiB0aGUgJ1InIGZsYWcgd2FzIHNldCBpbiB0aGUgRUFSTyBvZiB0aGUgTlMgbWVzc2Fn ZSwgYW5kIHRoaXMgNkxSIGNhbg0KICAgbWFuYWdlIHRoZSByZWFjaGFiaWxpdHkgb2YgUmVnaXN0 ZXJlZCBBZGRyZXNzLCB0aGVuIHRoZSA2TFIgc2V0cyB0aGUgJ1InIGZsYWcNCiAgIGluIHRoZSBB Uk8gb2YgdGhlIHJlc3BvbnNlIE5BIG1lc3NhZ2UuICANCiAgIEZyb20gdGhlbiBvbiwgdGhlIDZM TiBwZXJpb2RpY2FsbHkgc2VuZHMgYSBuZXcgTlMoRUFSTykgdG8gcmVmcmVzaCB0aGUgTkNFDQog ICBzdGF0ZSBiZWZvcmUgdGhlIGxpZmV0aW1lIGluZGljYXRlZCBpbiB0aGUgRUFSTyBleHBpcmVz LCB3aXRoIFRJRCB0aGF0IGlzDQogICBpbmNyZW1lbnRlZCBlYWNoIHRpbWUgdGlsbCBpdCB3cmFw cyBpbiBhIGxvbGxpcG9wIGZhc2hpb24uIEFzIGxvbmcgYXMgdGhlICdSJw0KICAgZmxhZyBpcyBz ZXQgYW5kIHRoaXMgcm91dGVyIGNhbiBzdGlsbCBtYW5hZ2UgdGhlIHJlYWNoYWJpbGl0eSBvZiBS ZWdpc3RlcmVkDQogICBBZGRyZXNzLCB0aGUgNkxSIGtlZXBzIHNldHRpbmcgdGhlICdSJyBmbGFn IGluIHRoZSBBUk8gb2YgdGhlIHJlc3BvbnNlIE5BDQogICBtZXNzYWdlLCBidXQgdGhlIGV4Y2hh bmdlIG9mIER1cGxpY2F0ZSBBZGRyZXNzIG1lc3NhZ2VzIGlzIHNraXBwZWQuDQogIA0KICAgVXBv biBhIHN1Y2Nlc3NmdWwgTlMvTkEoRUFSTykgZXhjaGFuZ2U6IGlmIHRoZSAnUicgZmxhZyB3YXMg c2V0IGluIHRoZSANCiAgIEVBUk8gb2YgdGhlIE5TIG1lc3NhZ2UsIHRoZW4gdGhlIDZMUiBTSE9V TEQgaW5qZWN0IHRoZSBSZWdpc3RlcmVkIEFkZHJlc3MgaW4NCiAgIFJQTCBieSBzZW5kaW5nIGEg REFPIG1lc3NhZ2Ugb24gYmVoYWxmIG9mIHRoZSA2TE47IGVsc2UgdGhlIDZMUiBTSE9VTEQNCiAg IHJlZnJhaW4gZnJvbSBpbmplY3RpbmcgdGhlIHJlZ2lzdGVyZWQgYWRkcmVzcyBpbnRvIFJQTC4g ICAgDQogIg0KDQoqKioqKioqKioqKioqKioqKioqKg0KDQoNClNlY3Rpb24gNi40Og0KKi8gVXBv biByZWNlcHRpb24gb2YgYSBEQU8gbWVzc2FnZSB0aGF0IGNyZWF0ZXMgb3IgdXBkYXRlcyBhbiBl eGlzdGluZw0KICAgUlBMIHN0YXRlLMKgDQpHUD4gbWF5YmUgaW5kaWNhdGUsIGZyb20gd2hvbSBw b3RlbnRpYWxseSB0aGUgUm9vdCByZWNlaXZlcyBhIERBTyBtZXNzYWdlDQoNCg0KDQpbUFQ+XSBB ZGRlZCBiZWZvcmU6DQoiDQogICBJbiBSUEwgU3RvcmluZyBNb2RlIG9mIE9wZXJhdGlvbiAoTU9Q KSwgdGhlIERBTyBtZXNzYWdlIGlzIHByb3BhZ2F0ZWQgZnJvbQ0KICAgY2hpbGQgdG8gcGFyZW50 IGFsbCB0aGUgd2F5IHRvIHRoZSBSb290IGFsb25nIHRoZSBET0RBRywgcG9wdWxhdGluZyByb3V0 aW5nDQogICBzdGF0ZSBhcyBpdCBnb2VzLiBJbiBOb24tU3RvcmluZyBNb2RlLCBUaGUgREFPIG1l c3NhZ2UgaXMgc2VudCBkaXJlY3RseSB0byB0aGUNCiAgIHJvdXRlLg0KIg0KDQoNCioqKioqKioq KioqKioqKioqKioqDQoNCg0KDQpTZWN0aW9uIDYuNToNCiovIFVwb24gcmVjZXB0aW9uIG9mIGEg REFSIG1lc3NhZ2Ugd2l0aCB0aGUgT3duZXIgVW5pcXVlIElEIGZpZWxkIGlzIHNldA0KICAgdG8g YWxsIG9uZXMsIHRoZSA2TEJSIGNoZWNrcyB3aGV0aGVyIGFuZCBlbnRyeSBleGlzdHMgZm9yIHRo ZSBhbmQNCiAgIGNvbXB1dGVzIHdoZXRoZXIgdGhlIFRJRCBpbiB0aGUgREFSIG1lc3NhZ2UgaXMg ZnJlc2hlciB0aGFuIHRoYXQgaW4NCiAgIHRoZSBlbnRyeSBhcyBwcmVzY3JpYmVkIGluIFtJLUQu aWV0Zi02bG8tcmZjNjc3NS11cGRhdGVdLg0KR1A+IHR5cG86IGFuZCBlbnRyeSDigJQ+IGFuIGVu dHJ5DQoNCltQVD5dIERvbmUuDQoNCioqKioqKioqKioqKioqKioqKioqDQoNCg0KKi8gICBJZiB0 aGUgZW50cnkgZXhpc3RzIGJ1dCBpcyBub3QgZnJlc2hlciwgdGhlIDZMQlIgZG9lcyBub3QgdXBk YXRlIHRoZQ0KICAgZW50cnksIGFuZCBhbnN3ZXJzIHdpdGggYSBTdGF0dXMgIlN1Y2Nlc3MiIGlu IHRoZSBEQUMgbWVzc2FnZS4NCg0KDQogICBJZiB0ZSBlbnRyeSBleGlzdHMgYW5kIHRoZSBUSUQg aW4gdGhlIERBUiBtZXNzYWdlIGlzIGZyZXNoZXIsIHRoZQ0KICAgNkxCUiB1cGRhdGVzIHRoZSBU SUQgaW4gdGhlIGVudHJ5LCBhbmQgaWYgdGhlIGxpZmV0aW1lIG9mIHRoZSBlbnRyeQ0KICAgaXMg ZXh0ZW5kZWQgYnkgdGhlIFJlZ2lzdHJhdGlvbiBMaWZldGltZSBpbiB0aGUgREFSIG1lc3NhZ2Us IGl0IGFsc28NCiAgIHVwZGF0ZXMgdGhlIGxpZmV0aW1lIG9mIHRoZSBlbnRyeS4gIEluIHRoYXQg Y2FzZSwgdGhlIDZMQlIgcmVwbGllcw0KICAgd2l0aCBhIFN0YXR1cyAiU3VjY2VzcyIgaW4gdGhl IERBQyBtZXNzYWdlLg0KDQpHUD4gWW91IGNvdWxkIHJlcGxhY2UgdGhlIOKAnGZyZXNoZXLigJ0g d2l0aCByZWNlbnQ/DQoNCg0KW1BUPl0gQWN0dWFsbHkgIkZyZXNoIiBpcyBkZWZpbmVkIGluIFJQ TCBhbmQgcmVwZWF0ZWQgaW4gc2VjdGlvbiA0LjIuMS4gICJDb21wYXJpbmcgVElEIHZhbHVlcyIg b2YgUkZDIDY3NzUgdXBkYXRlLg0KSSBhZGRlZCBhIHBvaW50ZXIgdG8gdGhhdC4NCg0KVGhhbmtz IGFnYWluIGZvciBhbGwhDQoNClBhc2NhbA0KDQo= From nobody Fri Feb 23 08:19:09 2018 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 2B3291271DF for ; Fri, 23 Feb 2018 08:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 s7i0u9-G9ix5 for ; Fri, 23 Feb 2018 08:19:05 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0658126DFB for ; Fri, 23 Feb 2018 08:19:05 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id e7so10358139ioj.1 for ; Fri, 23 Feb 2018 08:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vnBV6JD/nAdG6G41yi79JTM5D7imTwGi058f2hzaXaE=; b=uImQt5X+0g66RufScyJCVcJ/f3QF8jM5ePhB0HiXXuSVbM7G3pwglkONNIs13ZTuUP u5FwUcZEKJoAvRuFUzZwTMDlti3Q8/irXn3K88KbwQeqCHbsQe+50ezxtcdnle7PDVe4 ld/TlGqEiHh53FNlJqURkyaL2ScWl4XxYm2tef0vjjSLVVs+4WrdLHlSBKwffJTPU9Pw 6kXEJ1FJ8oVx7kLIxPg1L+lYPoDfEjaQ3oUl/qrI46AYoCBECi91w1f9fsTkxQa8rgph COyMKVUTgpLVWN6ZGBhgPKv5RH0MU4ekjHC4k+bXO38bbkXLMuFl0yTs7jPH3QhdD8sa pTng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vnBV6JD/nAdG6G41yi79JTM5D7imTwGi058f2hzaXaE=; b=RElcMfzpfoI7VmuDwBa+iP9qft+GbiR939aVAVXBf3QiMAYzam0nOoyUDucgUwptw8 ZDDywOPAdV6XGdMBGjak25VhCq1xUrtJ5KcmYys133OK+lStumGD1nDxdlOwUxoXR0ln 49QyxQ4dDJhTwwtCOqqn63JvRexHUt1eoWWYIXBvOAam/unqt1+I8pMUTWxHEtjb44j7 DNgPzpy1Le1h7xLTKkH0f/oWe91lsiXgiMonba4+2GTHuXUVjbeGa0Er14YskeBJ1f/r nMdRiti5UemmWWp4Easf8sZXpqr16agxahAZwaeN5VcFIw1daskTxzNu1Dg00SR0z8N0 vMhA== X-Gm-Message-State: APf1xPBFevuXMJ51oLxfERS8xOmL7MjRZwe2ULl+nOloW+/smRhx4kIw 2MKBNI48xVSoGYq79ujJ/qtT1/mfeeWWhrnAYuIddg== X-Google-Smtp-Source: AG47ELuISjT19ZU0IkDLKmFPl34/vP3Bqp6SZsPj1YIbuYCtYeOG4cUzIfldAzqkjfwrRP321UrasRMYyr5aM2geH5s= X-Received: by 10.107.24.70 with SMTP id 67mr2310672ioy.15.1519402744715; Fri, 23 Feb 2018 08:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.196.154 with HTTP; Fri, 23 Feb 2018 08:19:04 -0800 (PST) From: Ines Robles Date: Fri, 23 Feb 2018 18:19:04 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="94eb2c05a40edea0db0565e38485" Archived-At: Subject: [Roll] IETF 101 - Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 16:19:07 -0000 --94eb2c05a40edea0db0565e38485 Content-Type: text/plain; charset="UTF-8" Dear all, Please find the preliminary agenda for the IETF 101. https://datatracker.ietf.org/meeting/101/materials/agenda-101-roll.txt Comments welcome, Thank you! Ines + Peter --94eb2c05a40edea0db0565e38485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the preliminary a= genda for the IETF 101.


=
Comments welcome,

Thank you!
=
Ines + Peter
--94eb2c05a40edea0db0565e38485-- From nobody Fri Feb 23 10:56:02 2018 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 C2BD9126DEE; Fri, 23 Feb 2018 10:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wELMzJ65y21Z; Fri, 23 Feb 2018 10:55:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987A9126C2F; Fri, 23 Feb 2018 10:55:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A535C20090; Fri, 23 Feb 2018 14:03:23 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBDD080C90; Fri, 23 Feb 2018 13:55:53 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: "Routing Over Low power and Lossy networks" , "6tisch\@ietf.org" <6tisch@ietf.org> In-Reply-To: References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <10405.1519253755@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] [6tisch] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 18:55:56 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > If the 'R' flag is not set, then the Registering Node is expected to be a RPL > router that handles the reachability of the Registered Address by itself. > This document also specifies a keep-alive EDAR message that the RPL Root may > use to maintain an existing state in the 6LBR upon receiving DAO messages. > The EDAR message may only act as a refresher and can only update the Lifetime > and the TID of the state in the 6LBR. A RPL router SHOULD NOT set the 'R' flag. Can we also say that a 6LR, upon seeing a ND *without* the EARO option, should assume it's like the R flag is set? Or is such a node just non-operable? (Clearly, such a node can't move from DODAG to DODAG...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqQY7kACgkQgItw+93Q 3WW9pwf/VER5um62CfkaAI7ctg7myb7bZJJwx/beU58jSMjdxRlzlHYRi/PhxmT8 QuwPzgHBBLvRQ83aXHZVhSC8+gbSNOe5sxZ1Yyr06IFC4jiA/+t0iDgQHu64Z0HE ITbo3khzWvEGrrQ/tO+P32yvuu9DmvgYv4q9rMrOH0zNFW7Qd51H+Oa3ibtFGryY 2YeqqK+olC+baSu+oQT1CvvxX2q3QJQpsqn5YVexVd9S5il0ROVCQmr2X5mjQszr E6E7ViDHHFZPu0qqeUemdl1TkxYjLMGwi+W9QZftgwEccWaiLvEbdSn8/ulwxMGL ZXU6kSSGZWNPnlXkzVt3T3Dwt6uu/g== =K/us -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 24 00:04:57 2018 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 49AEC120725; Sat, 24 Feb 2018 00:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgrDRo0HQ5yC; Sat, 24 Feb 2018 00:04:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093D2120227; Sat, 24 Feb 2018 00:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1O84nwW022047; Sat, 24 Feb 2018 09:04:49 +0100 (CET) Received: from client-0185.vpn.uni-bremen.de (client-0185.vpn.uni-bremen.de [134.102.107.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zpLGn28yPzDXfy; Sat, 24 Feb 2018 09:04:49 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 541152286.7983201-f1308fd5ec8e7df7e8f3107e90d61144 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <3CDE2DF0-000B-4012-996F-C1B7B9C81145@tzi.org> Date: Sat, 24 Feb 2018 00:04:48 -0800 To: lo <6lo@ietf.org>, tisch <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF101: "FINAL" AGENDA X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Feb 2018 08:04:55 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF101. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. SUIT is now on top of CORE (!??). (Also, ICE has moved.) The painful ones this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. traveling to OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC, CORE vs. SECDISPATCH. All times are actually in GMT (UTC+0000, DST only starts in London on March 25). (You can always get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Blenheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Richm_Chl_Tow ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Buckingham SEC *** suit Software Updates for Internet of Things = WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Viscount SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Blenheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Palace C ART ice Interactive Connectivity Establishment = WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Blenheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Blenheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Blenheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Sandringham INT homenet Home Networking WG Blenheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG 1150-1320 Afternoon Session I Blenheim RTG detnet Deterministic Networking WG - 1150 - = 1430 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG (UTC+01:00 times) From nobody Mon Feb 26 00:36:20 2018 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 685A912D777; Mon, 26 Feb 2018 00:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSXF523clhwD; Mon, 26 Feb 2018 00:36:17 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1196312D775; Mon, 26 Feb 2018 00:36:16 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud9.xs4all.net with ESMTPA id qEGbeA4EewC4EqEGbe9kGb; Mon, 26 Feb 2018 09:36:14 +0100 Received: from AMontpellier-654-1-186-134.w92-145.abo.wanadoo.fr ([92.145.165.134]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 26 Feb 2018 09:36:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 26 Feb 2018 09:36:13 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: 6lo@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfM/SbYBKswvZhkjhp7DqTeErgi+LtXPrv58qi+fvz0iXWPHtOwbTJK17rNEqOXkl7dePCgJUebx053ey84t4x8KAlgZJhNXEMiJHVqCILchgbr6Sx5vq 4FoYk3l8p/ODaqXrLbiB5tL80JQGYqHF74Pi8bbN+PW/ND6sGjNpvovMHDWFe9Ugy26UmAqozbxQoYe8wdrK9nRim3x+f0J7mSKb1P2t4DsuCwZlnjo/4H5G Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 08:36:19 -0000 > > Side question: Is it the right approach or should the leaf set the bit > instead? > I don't understand how a node, 6LN, that is not aware of RPL can nevertheless set a bit related to RPL. I expect the 6LR to do all handling. Or do I misunderstand the context? Peter From nobody Mon Feb 26 01:24:38 2018 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 7BA01126CE8; Mon, 26 Feb 2018 01:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 rQeGnyYkJICF; Mon, 26 Feb 2018 01:24:31 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46651204DA; Mon, 26 Feb 2018 01:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1302; q=dns/txt; s=iport; t=1519637070; x=1520846670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zdb8uibzO9g5IrjkRCUr7fFPDljMSO2BIOU3xgEkwNg=; b=jwgIkuerMP8OXutizI8aS5/ks8oCslSChmp1/WwGWMXQJAmlt9LSdqN4 Wb9GqpYyrsxGpd/SwfAfllGrCibotU4wUjJWIOSZ6A1FHd5jz+0b1aCjj JzAhGxX80gMRE01HdZuu0H9QvRuy4bMyYp1ppOVxIb1uPYyDTLiA1Sl9W 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAgB00ZNa/5hdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAog1SYHoICgRaWBYIWChgLhRACGoIgVRcBAgEBAQE?= =?us-ascii?q?BAQJrKIUkAQEDAQEBIRE6CwULAgEIGgImAgICJQsVEAEBBA4FhQgIEKsSgie?= =?us-ascii?q?IY4IUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4YzgVeBZimDBIMuAQGEfjG?= =?us-ascii?q?CNAWhYQkClB6CBoVminSJZ4thAhEZAYEuASABNYFRcBU6KgGCGIRad4xfAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.47,396,1515456000"; d="scan'208";a="353605434" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 09:24:29 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1Q9OTZx025802 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 09:24:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 03:24:29 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 03:24:29 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" CC: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgDVbqOA//+o5ys= Date: Mon, 26 Feb 2018 09:24:29 +0000 Message-ID: References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 09:24:32 -0000 SGVsbG8gUGV0ZXINCg0KVGhlIGJpdCBpcyBhZ25vc3RpYyB0byB3aGljaCB0ZWNobmlxdWUsIHNh eSBSUEwgYnV0IGFsc28gYW55IHJvdXRpbmcgcHJvdG9jb2wgb3IgTkQgcHJveHkgaXMgdXNlZCBp biB0aGUgcGFydGljdWxhciBlbnZpcm9ubWVudC4gDQoNClRoZSBiaXQgc2F5cyBJ4oCZbSBhIHBs YWluIGhvc3QsIHBsZWFzZSBlbnN1cmUgcmVhY2hhYmlsaXR5IGZvciB0aGUgYWRkcmVzcyBJ4oCZ bSByZWdpc3RlcmluZy4NCg0KVGhlIGJpdCBpcyBjaG9zZW4gaW4gdGhhdCBkaXJlY3Rpb24gZm9y IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBSUEwuDQoNCkEgcGxhaW4gaG9zdCB0aGF0IGNv bmZvcm1zIHJmYzY3NzUgdXBkYXRlIHdpbGwgYWx3YXlzIHNldCBib3RoIHRoZSBSIGFuZCBUIGJp dHMuDQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQo+IExlIDI2IGbDqXZyLiAyMDE4IMOgIDA5OjM2 LCBwZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQHhzNGFsbC5ubD4gYSDDqWNyaXQgOg0KPiAN Cj4gDQo+PiBTaWRlIHF1ZXN0aW9uOiBJcyBpdCB0aGUgcmlnaHQgYXBwcm9hY2ggb3Igc2hvdWxk IHRoZSBsZWFmIHNldCB0aGUgYml0DQo+PiBpbnN0ZWFkPw0KPiANCj4gSSBkb24ndCB1bmRlcnN0 YW5kIGhvdyBhIG5vZGUsIDZMTiwgdGhhdCBpcyBub3QgYXdhcmUgb2YgUlBMIGNhbiBuZXZlcnRo ZWxlc3Mgc2V0IGEgYml0IHJlbGF0ZWQgdG8gUlBMLg0KPiBJIGV4cGVjdCB0aGUgNkxSIHRvIGRv IGFsbCBoYW5kbGluZy4NCj4gDQo+IE9yIGRvIEkgbWlzdW5kZXJzdGFuZCB0aGUgY29udGV4dD8N Cj4gDQo+IFBldGVyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Mon Feb 26 01:37:10 2018 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 85181126D3F; Mon, 26 Feb 2018 01:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT-RfrEv1Kb0; Mon, 26 Feb 2018 01:37:04 -0800 (PST) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E18126CF6; Mon, 26 Feb 2018 01:37:03 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud9.xs4all.net with ESMTPA id qFDPeAZxKwC4EqFDPeA4NN; Mon, 26 Feb 2018 10:37:00 +0100 Received: from AMontpellier-654-1-186-134.w92-145.abo.wanadoo.fr ([92.145.165.134]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 26 Feb 2018 10:36:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 26 Feb 2018 10:36:59 +0100 From: peter van der Stok To: "Pascal Thubert (pthubert)" Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks , 6lo@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com>, Message-ID: <6f9d6a6489ccb44b9609661bc3589890@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKNdJ3vw1hDXuDC+mE30hG1/FWOKfjd1W1HpRhSSRo064w8ZC7bhYvsfnt+HVHpDLnEU1gmDJPLqzE1Tb9B2hoiJebyBYXpafWEuOtGPoaR7u1L/EXuH kPxDzzYifSjHPanGpCvKC4QDJVjiO32OFx2joWmO1iByMmHojgSAJkOTr+S+eYrCOpRUUSXVtyNIbqkDqjGaMY14BjR0Fc+SeEb8c9fIKiKkPArYsdAHMtP/ KJ+qLS+vVscuT3DW/ZkKnRLHoTbxOv/Z670K/0o67/o= Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 09:37:05 -0000 HI Pascal, the bit definition sounds like a 6LO subject. Handling the bit for RPL like a Roll subject. makes sense? (did I understand correctly?) Peter Pascal Thubert (pthubert) schreef op 2018-02-26 10:24: > Hello Peter > > The bit is agnostic to which technique, say RPL but also any routing > protocol or ND proxy is used in the particular environment. > > The bit says I’m a plain host, please ensure reachability for the > address I’m registering. > > The bit is chosen in that direction for backward compatibility with > RPL. > > A plain host that conforms rfc6775 update will always set both the R > and T bits. > > Regards, > > Pascal > >> Le 26 févr. 2018 à 09:36, peter van der Stok a >> écrit : >> >> >>> Side question: Is it the right approach or should the leaf set the >>> bit >>> instead? >> >> I don't understand how a node, 6LN, that is not aware of RPL can >> nevertheless set a bit related to RPL. >> I expect the 6LR to do all handling. >> >> Or do I misunderstand the context? >> >> Peter >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From nobody Mon Feb 26 01:41:36 2018 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 BF83412D777; Mon, 26 Feb 2018 01:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_UnlXq9x0Ds; Mon, 26 Feb 2018 01:41:29 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6970E126DD9; Mon, 26 Feb 2018 01:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1Q9fMow021188; Mon, 26 Feb 2018 10:41:22 +0100 (CET) Received: from client-0204.vpn.uni-bremen.de (client-0204.vpn.uni-bremen.de [134.102.107.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqcKG1WmbzDWRW; Mon, 26 Feb 2018 10:41:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> Date: Mon, 26 Feb 2018 10:41:21 +0100 Cc: "6lo@ietf.org" <6lo@ietf.org> X-Mao-Original-Outgoing-Id: 541330879.865888-ea3651bd16c2f9c0b296a07e15bf1098 Content-Transfer-Encoding: quoted-printable Message-Id: <40A3B5A7-2268-4A49-9108-4E76DD8C5036@tzi.org> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 09:41:31 -0000 On Feb 22, 2018, at 10:06, Pascal Thubert (pthubert) = wrote: >=20 > ROLL has the concept of a leaf, that is a 6LN that is not aware of RPL = but needs routing handled for it. This terminology is confusing. In RPL, a Leaf Node is a RPL router that does not forward (RFC 6550 = Section 8.5). We also have hosts (as in, not routers). Are you talking about the latter? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 26 09:10:36 2018 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 4F4C3124BFA; Mon, 26 Feb 2018 09:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ecWDBv3PXBhv; Mon, 26 Feb 2018 09:10:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BDD1205F0; Mon, 26 Feb 2018 09:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1462; q=dns/txt; s=iport; t=1519665030; x=1520874630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eqa/g6vbsbTWFMVxNekt5JNkzDlqYrFw0si77vd4WOY=; b=gQnJTqjkrqyGonF5uml9JdrL2FzN6sp0XaMOO9SSHCOsmTq1h6tWMfId Dl0VgomZGlegxT01gmJ9SY1XGagnV3fNS+G2NHKmKMEl0m5aV4yLJMRrG G6Aww+BBMlTXBQIFvrJ5wODWhUy8TWrMAQrhgfXevoSfq1Scrq0L31p7C k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQB1PpRa/5tdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCo1sjX6CAoEWlgWCFgqCAYMyAoJFVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAQN3AgwEAgEIEQQBAQEnBzIUCQgCBA4FCIUIrVuIbIIUAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHYdCgVeBZoMthQWGDgWReI9pCQKUFYIPkFq?= =?us-ascii?q?JZ4thAhEZAYEuAR44gVFwFYJ9gkMcFoFld4tEgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="360623218" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 17:10:29 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1QHATYM022052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 17:10:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 11:10:28 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 11:10:28 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacfgAFHRoCAAd4mgIABA3OAgAQ0OmA= Date: Mon, 26 Feb 2018 17:09:58 +0000 Deferred-Delivery: Mon, 26 Feb 2018 17:09:29 +0000 Message-ID: References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <10405.1519253755@obiwan.sandelman.ca> <13406.1519412153@obiwan.sandelman.ca> In-Reply-To: <13406.1519412153@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6tisch] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 17:10:31 -0000 That's true too Michael, but it is not ours pec, just the normal ND over tr= ansit links. Cheers, Pascal > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: vendredi 23 f=E9vrier 2018 19:56 > To: Pascal Thubert (pthubert) > Cc: Routing Over Low power and Lossy networks ; > 6tisch@ietf.org > Subject: Re: [6tisch] [Roll] Fwd: New Version Notification for draft-thub= ert- > roll-unaware-leaves-02.txt >=20 >=20 > Pascal Thubert (pthubert) wrote: > > If the 'R' flag is not set, then the Registering Node is expected t= o be a RPL > > router that handles the reachability of the Registered Address by i= tself. > > This document also specifies a keep-alive EDAR message that the RPL > Root may > > use to maintain an existing state in the 6LBR upon receiving DAO > messages. > > The EDAR message may only act as a refresher and can only update th= e > Lifetime > > and the TID of the state in the 6LBR. A RPL router SHOULD NOT set = the > 'R' flag. >=20 > Can we also say that a 6LR, upon seeing a ND *without* the EARO option, > should assume it's like the R flag is set? Or is such a node just non-op= erable? > (Clearly, such a node can't move from DODAG to DODAG...) >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Feb 26 09:18:19 2018 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 60BDD12D77D; Mon, 26 Feb 2018 09:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZHfyJwZfCcz1; Mon, 26 Feb 2018 09:17:30 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE82126D0C; Mon, 26 Feb 2018 09:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3042; q=dns/txt; s=iport; t=1519665450; x=1520875050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=91VlzLebintIn35+BnBMXUwLhZpKaO13LGz0BjmkYvw=; b=mcUbSLO/TxilPda3fjh9vt6eXfVEriVSmGvfyRen2Fm24t39tWHT12V5 //zl2vyZty6Iygxmpxj75Zm23MfFiqHbQTVDmZ0kZLYl0AEzDGGve7Rkc FTA5uuKQ7PGCMmYPqk9O/ETTwPJD+TrL0cCh2xuyG5s0b8W0ey822HyGD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQBsQJRa/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCoNKiiKNfoICgRaWBYIWChgLhRACGoIrVBgBAgEBAQE?= =?us-ascii?q?BAQJrHQuFIwEBAQEDAQEhEToLDAQCAQgRBAEBAwIjAwICAiULFAEICAEBBA4FC?= =?us-ascii?q?IUIEKs5gieIbIIUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4YzgVeBZoMtgy4?= =?us-ascii?q?BAQOBUjOCdoJlBaFhCQKHN4xegg+FZop0iWeCaoh3AhEZAYEuAR44gVFwFTqCQ?= =?us-ascii?q?4JDHIF7dxGLM4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="360875186" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 17:17:29 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w1QHHTkw008579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 17:17:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 11:17:28 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 11:17:28 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" CC: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgDVbqOA//+o5yuAAGgTgP//5eyg Date: Mon, 26 Feb 2018 17:16:59 +0000 Deferred-Delivery: Mon, 26 Feb 2018 17:16:07 +0000 Message-ID: References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com>, <6f9d6a6489ccb44b9609661bc3589890@xs4all.nl> In-Reply-To: <6f9d6a6489ccb44b9609661bc3589890@xs4all.nl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 17:17:32 -0000 WW91IGRvLCBQZXRlcjsgDQoNCml0IHdhcyBhZGRlZCB0byBSRkMgNjc3NSB1cGRhdGUgcGVyIG91 ciBkaXNjdXNzaW9uLg0KTXkgbGVhZiBkcmFmdCBhdCBST0xMIGp1c3Qgc2F5cyB0aGF0IGxlYXZl cyBzZXQgdGhlIGJpdCBhbmQgcm91dGVycyBkbyBub3QuIEJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0 aGUgYml0IG1vdmVkIHRvIDZsbyB0byBtYWtlIGl0IGdlbmVyaWMuDQoNCkFsbCBkcmFmdHMgYXJl IHB1Ymxpc2hlZCBhbmQgYWxpZ25lZCB0byB0aGF0LCBpbmNsdWRpbmc6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bG8tYmFja2JvbmUtcm91dGVyLTA2DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bG8tcmZjNjc3NS11cGRhdGUtMTQNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtdW5hd2FyZS1sZWF2 ZXMtMDMNCg0KV2UgY2FuIHN0aWxsIGNoYW5nZSBpdCBidXQgdGhhdCBkaXJlY3Rpb24gc2VlbXMg dG8gYmUgbWFraW5nIHRoZSBtb3N0IHNlbnNlLg0KDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHBldGVyIHZhbiBkZXIg U3RvayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0NCj4gU2VudDogbHVuZGkgMjYgZsOpdnJp ZXIgMjAxOCAxMDozNw0KPiBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRA Y2lzY28uY29tPg0KPiBDYzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IFJvdXRpbmcgT3Zl ciBMb3cgcG93ZXIgYW5kIExvc3N5DQo+IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPjsgNmxvQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gQSBiaXQgZm9yIFJPTEwNCj4gDQo+IEhJIFBh c2NhbCwNCj4gDQo+IHRoZSBiaXQgZGVmaW5pdGlvbiBzb3VuZHMgbGlrZSBhIDZMTyBzdWJqZWN0 Lg0KPiBIYW5kbGluZyB0aGUgYml0IGZvciBSUEwgbGlrZSBhIFJvbGwgc3ViamVjdC4NCj4gDQo+ IG1ha2VzIHNlbnNlPyAoZGlkIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHk/KQ0KPiANCj4gUGV0ZXIN Cj4gDQo+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgc2NocmVlZiBvcCAyMDE4LTAyLTI2IDEw OjI0Og0KPiA+IEhlbGxvIFBldGVyDQo+ID4NCj4gPiBUaGUgYml0IGlzIGFnbm9zdGljIHRvIHdo aWNoIHRlY2huaXF1ZSwgc2F5IFJQTCBidXQgYWxzbyBhbnkgcm91dGluZw0KPiA+IHByb3RvY29s IG9yIE5EIHByb3h5IGlzIHVzZWQgaW4gdGhlIHBhcnRpY3VsYXIgZW52aXJvbm1lbnQuDQo+ID4N Cj4gPiBUaGUgYml0IHNheXMgSeKAmW0gYSBwbGFpbiBob3N0LCBwbGVhc2UgZW5zdXJlIHJlYWNo YWJpbGl0eSBmb3IgdGhlDQo+ID4gYWRkcmVzcyBJ4oCZbSByZWdpc3RlcmluZy4NCj4gPg0KPiA+ IFRoZSBiaXQgaXMgY2hvc2VuIGluIHRoYXQgZGlyZWN0aW9uIGZvciBiYWNrd2FyZCBjb21wYXRp YmlsaXR5IHdpdGgNCj4gPiBSUEwuDQo+ID4NCj4gPiBBIHBsYWluIGhvc3QgdGhhdCBjb25mb3Jt cyByZmM2Nzc1IHVwZGF0ZSB3aWxsIGFsd2F5cyBzZXQgYm90aCB0aGUgUg0KPiA+IGFuZCBUIGJp dHMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPj4gTGUgMjYg ZsOpdnIuIDIwMTggw6AgMDk6MzYsIHBldGVyIHZhbiBkZXIgU3RvayA8c3Rva2NvbnNAeHM0YWxs Lm5sPiBhDQo+ID4+IMOpY3JpdCA6DQo+ID4+DQo+ID4+DQo+ID4+PiBTaWRlIHF1ZXN0aW9uOiBJ cyBpdCB0aGUgcmlnaHQgYXBwcm9hY2ggb3Igc2hvdWxkIHRoZSBsZWFmIHNldCB0aGUNCj4gPj4+ IGJpdCBpbnN0ZWFkPw0KPiA+Pg0KPiA+PiBJIGRvbid0IHVuZGVyc3RhbmQgaG93IGEgbm9kZSwg NkxOLCB0aGF0IGlzIG5vdCBhd2FyZSBvZiBSUEwgY2FuDQo+ID4+IG5ldmVydGhlbGVzcyBzZXQg YSBiaXQgcmVsYXRlZCB0byBSUEwuDQo+ID4+IEkgZXhwZWN0IHRoZSA2TFIgdG8gZG8gYWxsIGhh bmRsaW5nLg0KPiA+Pg0KPiA+PiBPciBkbyBJIG1pc3VuZGVyc3RhbmQgdGhlIGNvbnRleHQ/DQo+ ID4+DQo+ID4+IFBldGVyDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4+IFJvbGxAaWV0 Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Mon Feb 26 09:22:35 2018 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 C111012025C; Mon, 26 Feb 2018 09:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cEHKul8_0rQt; Mon, 26 Feb 2018 09:22:31 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41118126D0C; Mon, 26 Feb 2018 09:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1786; q=dns/txt; s=iport; t=1519665751; x=1520875351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mn/ZGjVOJa9AWKbK5qKx1Wwwo61KauLNU12Lw6rC/Cs=; b=iyE/4VdR+5RfnjDo8wkYkK6zKw0v86jdhp2oxk+DFSudyGryejLMWlAS kIGTdMkRLy34yvrniPK56l/taLDSJLft3qfbUpuRoOwfhXlrt1WlVw84d BaQvZjWlxNNRpWyU3v0dMwaR7v5KS5d0Puci+nZmSVMoznJeL9ilu5MQf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAQA3QpRa/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCoNKiiKNfoICgRaWBYIWChgLhRACGoIrVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAQMBASEROgsMBAIBBgIOAwQBAQECAiMDAgICJQsUAQgIAQEEA?= =?us-ascii?q?Q0FCIUIEI1JnW6CJ4htghQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhjOBV4F?= =?us-ascii?q?mgh+BDoMuAQGBVYMpgmUFoWEJApQVkmmVSAIRGQGBLgEeOIFRcBU6gkOEWneLR?= =?us-ascii?q?IEXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="76215688" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 17:22:29 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1QHMTf7008181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 17:22:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 11:22:28 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 11:22:28 -0600 From: "Pascal Thubert (pthubert)" To: Carsten Bormann , Routing Over Low power and Lossy networks CC: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgDXtPqAAANMJMA= Date: Mon, 26 Feb 2018 17:22:00 +0000 Deferred-Delivery: Mon, 26 Feb 2018 17:21:20 +0000 Message-ID: <0fcac22de4bb491f8fcbd70d1af9009f@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <40A3B5A7-2268-4A49-9108-4E76DD8C5036@tzi.org> In-Reply-To: <40A3B5A7-2268-4A49-9108-4E76DD8C5036@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6lo] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 17:22:33 -0000 WWVzIENhcnN0ZW4sDQoNCkkgYWdyZWUgdGhlcmUncyBhIGNvbmZ1c2lvbiB0aGF0IHdlIG5lZWQg dG8gY2xlYW4gdXAgb24gdGhlIFJPTEwgc2lkZS4gTXkgZGVmaW5pdGlvbiBvZiBsZWFmIGVjaG9l cyB5b3VycyBmcm9tIFJGQyA2NTUwLiBBIGxlYWYgc3RpbGwgdW5kZXJzdGFuZHMgUlBMLg0KQnV0 IG92ZXIgdGltZSBwZW9wbGUgc3RhcnRlZCB1c2luZyB0aGUgdGVybSBhcyBhIHBsYWluIGhvc3Qg YXR0YWNoZWQgdG8gYSBSUEwgcm91dGVyIGJ1dCB0aGF0IGRvZXMgbm90IGtub3cgYWJvdXQgUlBM IGF0IGFsbC4NClRoaXMgaXMgd2h5IGluIG15IGRyYWZ0IEkgY2FsbGVkIHRoZW0gInVuYXdhcmUg bGVhdmVzIiBidXQgaW4gZmFjdCB0aGV5IGFyZSBwbGFpbiBob3N0cy4gSSdkIGJlIGhhcHB5IHdp dGggYSBiZXR0ZXIgdGVybS4NCg0KVGFrZSBjYXJlLA0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IDZsbyBbbWFpbHRvOjZsby1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IGx1bmRpIDI2IGbDqXZy aWVyIDIwMTggMTA6NDENCj4gVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzIDxyb2xsQGlldGYub3JnPg0KPiBDYzogNmxvQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbNmxvXSBbUm9sbF0gQSBiaXQgZm9yIFJPTEwNCj4gDQo+IE9uIEZlYiAyMiwgMjAxOCwgYXQg MTA6MDYsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCj4g d3JvdGU6DQo+ID4NCj4gPiBST0xMIGhhcyB0aGUgY29uY2VwdCBvZiBhIGxlYWYsIHRoYXQgaXMg YSA2TE4gdGhhdCBpcyBub3QgYXdhcmUgb2YgUlBMIGJ1dA0KPiBuZWVkcyByb3V0aW5nIGhhbmRs ZWQgZm9yIGl0Lg0KPiANCj4gVGhpcyB0ZXJtaW5vbG9neSBpcyBjb25mdXNpbmcuDQo+IA0KPiBJ biBSUEwsIGEgTGVhZiBOb2RlIGlzIGEgUlBMIHJvdXRlciB0aGF0IGRvZXMgbm90IGZvcndhcmQg KFJGQyA2NTUwIFNlY3Rpb24NCj4gOC41KS4NCj4gDQo+IFdlIGFsc28gaGF2ZSBob3N0cyAoYXMg aW4sIG5vdCByb3V0ZXJzKS4NCj4gDQo+IEFyZSB5b3UgdGFsa2luZyBhYm91dCB0aGUgbGF0dGVy Pw0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gNmxvIG1haWxpbmcgbGlzdA0KPiA2bG9AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG8NCg== From nobody Mon Feb 26 09:49:10 2018 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 29024126D0C; Mon, 26 Feb 2018 09:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogf0f2WMGhEM; Mon, 26 Feb 2018 09:49:07 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6001205F0; Mon, 26 Feb 2018 09:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1QHmx49019910; Mon, 26 Feb 2018 18:48:59 +0100 (CET) Received: from client-0046.vpn.uni-bremen.de (client-0046.vpn.uni-bremen.de [134.102.107.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqq7v1LpwzDWcJ; Mon, 26 Feb 2018 18:48:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <0fcac22de4bb491f8fcbd70d1af9009f@XCH-RCD-001.cisco.com> Date: Mon, 26 Feb 2018 18:48:58 +0100 Cc: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> X-Mao-Original-Outgoing-Id: 541360136.763034-7bddc7c8a8a3bfeee770a710ddeca25f Content-Transfer-Encoding: quoted-printable Message-Id: <50D68568-96AC-4EF9-82D2-66F16CB938C1@tzi.org> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <40A3B5A7-2268-4A49-9108-4E76DD8C5036@tzi.org> <0fcac22de4bb491f8fcbd70d1af9009f@XCH-RCD-001.cisco.com> To: Pascal Thubert X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Roll] [6lo] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 17:49:08 -0000 On Feb 26, 2018, at 18:22, Pascal Thubert (pthubert) = wrote: >=20 > Yes Carsten, >=20 > I agree there's a confusion that we need to clean up on the ROLL side. = My definition of leaf echoes yours from RFC 6550. A leaf still = understands RPL. > But over time people started using the term as a plain host attached = to a RPL router but that does not know about RPL at all. They should read RFC 6550 then :-) (Maybe calling them =E2=80=9Cleaves=E2=80=9D in RFC6550 wasn=E2=80=99t = so bright, but that=E2=80=99s water under the bridge.) > This is why in my draft I called them "unaware leaves" but in fact = they are plain hosts. I=E2=80=99d be happy with a better term. I think =E2=80=9Chost=E2=80=9D is the best term we have for non-router = nodes in the IETF. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 26 10:03:40 2018 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 EA83F127275; Mon, 26 Feb 2018 10:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xdvxsqE4J9Ol; Mon, 26 Feb 2018 10:03:30 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D7F12025C; Mon, 26 Feb 2018 10:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1519668210; x=1520877810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mfMXjCW8xkUeQd9h8uaTLYF8nn91hoqoM0lKPYpRmu4=; b=UDeVui/vCRbI+HvBef5h0djpEVzERLialREYKdXAVlJPRMgJF8soZR79 /IvH3i6sOAoMXCGELoKkdui2v/femnMOF14PN26I6VxSqYb0dS33OhvqN UoCeWdmw7TbNb1L3WsUoLLvZ4wUqjghLDX4wBL1cRpPyW2yxDcMk01XoG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAQC1SpRa/40NJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCoNKiiKNfoICgRaWBYIWCoUzAhqCK1QYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQEDIxFFDAQCAQYCDgMEAQEBAgIjAwICAjAUAQgIAQEEDgU?= =?us-ascii?q?IhQiNYp1ugieIbYIUAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPhjOBV4Fmgh+?= =?us-ascii?q?BDoUFgymCZQWhYQkClBWCD4lLhw+VSAIRGQGBLgEeOIFRcBWCfYRad4tEgRc?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="363812724" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 18:03:29 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1QI3T4Z007993 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 18:03:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 12:03:29 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 12:03:29 -0600 From: "Pascal Thubert (pthubert)" To: Carsten Bormann CC: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] [Roll] A bit for ROLL Thread-Index: AdOruWv+hpS+/ptwRrObKgZlgYxMJgDXtPqAAANMJMAADbt+AAAMK3Kw Date: Mon, 26 Feb 2018 18:03:04 +0000 Deferred-Delivery: Mon, 26 Feb 2018 18:02:24 +0000 Message-ID: <13367ab89f9540b6aba0294d554a1fe9@XCH-RCD-001.cisco.com> References: <125576e1c5164d349282ee303f8cae3d@XCH-RCD-001.cisco.com> <40A3B5A7-2268-4A49-9108-4E76DD8C5036@tzi.org> <0fcac22de4bb491f8fcbd70d1af9009f@XCH-RCD-001.cisco.com> <50D68568-96AC-4EF9-82D2-66F16CB938C1@tzi.org> In-Reply-To: <50D68568-96AC-4EF9-82D2-66F16CB938C1@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6lo] A bit for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 18:03:34 -0000 VGhhdCB3b3VsZCBiZSB0aGUgZWFzeSBvbmUgZm9yIHN1cmUgYnV0IHdlJ2QgbG9zZSB0aGUgZmFj dCB0aGF0IHRoZSBub2RlIGF0dGFjaGVzIHRvIGEgUlBMIG5ldHdvcmssIGV2ZW4gaWYgaXQgZG9l cyBub3Qga25vdy4NCkNoZWVycywNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NCj4gU2Vu dDogbHVuZGkgMjYgZsOpdnJpZXIgMjAxOCAxODo0OQ0KPiBUbzogUGFzY2FsIFRodWJlcnQgKHB0 aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KPiBDYzogUm91dGluZyBPdmVyIExvdyBwb3dl ciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+Ow0KPiA2bG9AaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFs2bG9dIFtSb2xsXSBBIGJpdCBmb3IgUk9MTA0KPiANCj4gT24gRmViIDI2 LCAyMDE4LCBhdCAxODoyMiwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lz Y28uY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IFllcyBDYXJzdGVuLA0KPiA+DQo+ID4gSSBhZ3Jl ZSB0aGVyZSdzIGEgY29uZnVzaW9uIHRoYXQgd2UgbmVlZCB0byBjbGVhbiB1cCBvbiB0aGUgUk9M TCBzaWRlLiBNeQ0KPiBkZWZpbml0aW9uIG9mIGxlYWYgZWNob2VzIHlvdXJzIGZyb20gUkZDIDY1 NTAuIEEgbGVhZiBzdGlsbCB1bmRlcnN0YW5kcyBSUEwuDQo+ID4gQnV0IG92ZXIgdGltZSBwZW9w bGUgc3RhcnRlZCB1c2luZyB0aGUgdGVybSBhcyBhIHBsYWluIGhvc3QgYXR0YWNoZWQgdG8gYQ0K PiBSUEwgcm91dGVyIGJ1dCB0aGF0IGRvZXMgbm90IGtub3cgYWJvdXQgUlBMIGF0IGFsbC4NCj4g DQo+IFRoZXkgc2hvdWxkIHJlYWQgUkZDIDY1NTAgdGhlbiA6LSkNCj4gKE1heWJlIGNhbGxpbmcg dGhlbSDigJxsZWF2ZXPigJ0gaW4gUkZDNjU1MCB3YXNu4oCZdCBzbyBicmlnaHQsIGJ1dCB0aGF0 4oCZcyB3YXRlcg0KPiB1bmRlciB0aGUgYnJpZGdlLikNCj4gDQo+ID4gVGhpcyBpcyB3aHkgaW4g bXkgZHJhZnQgSSBjYWxsZWQgdGhlbSAidW5hd2FyZSBsZWF2ZXMiIGJ1dCBpbiBmYWN0IHRoZXkg YXJlDQo+IHBsYWluIGhvc3RzLiBJ4oCZZCBiZSBoYXBweSB3aXRoIGEgYmV0dGVyIHRlcm0uDQo+ IA0KPiBJIHRoaW5rIOKAnGhvc3TigJ0gaXMgdGhlIGJlc3QgdGVybSB3ZSBoYXZlIGZvciBub24t cm91dGVyIG5vZGVzIGluIHRoZSBJRVRGLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Mon Feb 26 10:04:38 2018 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 03E9012704A; Mon, 26 Feb 2018 10:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7y6yv9Y64Nzo; Mon, 26 Feb 2018 10:04:31 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176F712025C; Mon, 26 Feb 2018 10:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2210; q=dns/txt; s=iport; t=1519668270; x=1520877870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NSNb8Lwcvm3usuioMcFm6KbAlc32s36kumFc4Skwblo=; b=Gp2aL2H/nWvyUFcGKnx7H4B9ZPxaLaROc8neWS4/wKhn+nX8INIS4Xuw O8cExezVNkxicPdf6LfyMxULxGO1/RudMRoobqnixtWyFlKEQDes9xLhN rWs2smz7BhomxUaXBt7ZHnQ0iwAbFXTg7whE5OjJF1yfCNKveeEVsg+iK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQC1SpRa/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCo1sjX6CAoEWlgWCFgqCAYMyAoJFVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAQMnUAIMBAIBCBEBAwEBAScHMhQDBggCBA4FCIUIrT06iG2?= =?us-ascii?q?CFAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2HQoFXgWaDLYUFhg4FkXiPaQkClBW?= =?us-ascii?q?SaZVIAhEZAYEuAR44gVFwFYJ9gnWBZXeLRIEXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="359001268" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 18:04:29 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1QI4TZ3011939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 18:04:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 12:04:29 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 12:04:29 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "Routing Over Low power and Lossy networks" CC: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacfgAFHRoCAByUM8A== Date: Mon, 26 Feb 2018 18:04:02 +0000 Deferred-Delivery: Mon, 26 Feb 2018 18:04:00 +0000 Message-ID: References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <10405.1519253755@obiwan.sandelman.ca> In-Reply-To: <10405.1519253755@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6tisch] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 18:04:33 -0000 Hello Michael: I published 03 addressing what I could :) Pascal > -----Original Message----- > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: mercredi 21 f=E9vrier 2018 23:56 > To: Routing Over Low power and Lossy networks > Cc: 6tisch@ietf.org > Subject: Re: [6tisch] [Roll] Fwd: New Version Notification for draft-thub= ert- > roll-unaware-leaves-02.txt >=20 >=20 > Pascal Thubert (pthubert) wrote: > > This is a short draft, but the work is much needed to complete the = RPL > > story on non-RPL-aware leaves. The draft conforms to the long-stand= ing > > expectations from the 6TiSCH architecture. >=20 > 1) can you add a reference for "Routing Stretch"? > 2) Alternatively, the 6LN may rely on its 6LR to perform routing and > forwarding on its behalf. In the context of RPL, such a 6LN is >=20 > -> if you want to give an example of such a node, I think that the win= dow > smash sensor (alarm system), or the kinetically powered light switc= h, > are two good examples. > {I wish I had links to real products that actually ran RPL.} >=20 > section 3: > s/ Upon the renewal of a registration, this specification changes th= e > behavior or the 6LR. > / Upon the renewal of a 6lowPAN ND registration, this specification > changes the > behavior of the 6LR. / >=20 > The rest of that paragraph is ver hard to parse. >=20 > section 4: > should: > This document specifies a new flag in the EARO option, the 'R' flag, > used by the registering node to indicate that the 6LN that performs > the registration is a router and that it handles its reachability. >=20 > say: > This document specifies a new flag in the EARO option, the 'R' flag, > used by a 6LN, when registering, to indicate that this 6LN > is a router and that it will handles its own reachability. >=20 > (...By sending a DAO) >=20 > The rest of the document has some difficult sentences too. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Feb 26 14:04:17 2018 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 D3BD7126C2F; Mon, 26 Feb 2018 14:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 9LbmliJUdRqy; Mon, 26 Feb 2018 14:04:14 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758F7126DFB; Mon, 26 Feb 2018 14:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1519682654; bh=Wabs0IsT5DvqJQfiu7czUtpnt/1WJvAuyCxl CbFruZI=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=sFTQy+3HcS/ayoyvvUsRrvlpax4r/pvlU AzNf1j5zpOVywz/PfwtNMJFC4khgwtSbQPp1fufPz1r3goOOlhht0vCi2xVqd6ZOq+d f6xfH1J/upITRO8YT1lMZ+WmPSp8VJT7o4IW5crkei3E2pyH8nJpp9UwGASESxbcQd8 C5cqZ03CEUxImXl9li60Y5rUh0ISc/4ZuKaWVd47su6bYK0yC36qtsPpxg2NBw662Fb J4xRz7g/VA8VpfHa3cnrP33yNmEQJUYK+r3TaqLd7PznZKQKgSHpkUKc1z2HeNXmia7 /WubCWgkA2yo2AFYCLePDEFmn63wbLBPo2ttPsGjA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=qgJ0X8PTWaLEnrzFZGj+i/s6HM1vKibKeb3qbjkp5ojet1I75f/QA4H9KJskIm/K/G5nBMY3TLLJlJEMnn+b3tdhg5R7Vd3KwE3C81spfKl+eAC/fhfNCCTvT0te0IC4PG4OJAqEagYc88KAsriWkpNFYoluCb+uT7JeUTrpUKZrOZDI+SVwstMi7BwosRX0eA5cL5EpdxhWFD0leN0UrVuQo9A0oqyiSI8WYiSkp9A3LdkbaFs8L0TExDSUkGnrbx5QjSd1WNgYkyeLkE+JyehHXOs3UL80JuZRf7czcw0AJbGAGMQ0CBPvW9F6IB8bBXSlVk31VR+fOFEhqS1hKg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1eqQsW-0008gh-SD; Mon, 26 Feb 2018 17:04:13 -0500 To: Abdussalam Baryun , roll , draft-ietf-roll-aodv-rpl@ietf.org References: From: Charlie Perkins Message-ID: Date: Mon, 26 Feb 2018 14:04:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------195935222C06FD4FFA5949A6" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953fdc43234240913d16a57c4b80efeae3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] Comments for AODV-RPL protocol [Issue #184] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 26 Feb 2018 22:04:17 -0000 This is a multi-part message in MIME format. --------------195935222C06FD4FFA5949A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Abdussalam, Thanks for your comments and suggestions.  Please find some follow-up comments below. On 1/5/2018 12:04 PM, Abdussalam Baryun wrote: > Hi WG, > > The abstract needs to delete any indication that this is a routing > protocol. IMHO, this is a route discovery for the RPL protocol. > To me AODV-RPL is a variation on RPL.  But I am curious to know more about the distinction between a routing protocol and a route discovery mechanism that uses routing protocol control messages. > The discovery of route is part of the routing protocol so we have a > different routing which is AODV-RPL routing protocol. The draft needs > to mention if this AODV-RPL can work with RPL or not in the same network. > Yes, AODV-RPL should interoperate quite well with RPL in the same network.  If there is some case that presents difficulty please let us know and we will analyze it further. > IMO, the draft needs to describe the neighbor discovery combined with > AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and > 18.6 in rfc6550. Or the draft shows the difference from RFC6650 > discovery. Please refer to sections in RFC6550 RPL. > I don't really know what to make of this, until after I can better understand the difference between a routing protocol and a route discovery mechanism that uses routing protocol control messages. > AODV-RPL instance are another type of RPL-Instances, so why you write > the AODV instance. > > Please note that this will conflict with MANET routing instances. > Please delete AODV instance. This draft needs to have only RPL > instances or this AODV-RPL instance defined as RPL instance. > I looked for the strings "AODV instance" and "AODV-RPL instance" but did not find.  Could you point to the particular occurrence so that I can understand the conflict? > Delete the writing words 'AODV routing' from the draft, and delete > AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV > is already well known. > Thanks for acknowledging the work on AODV.  I am hoping AODVv2 completes Last Call soon.  However, I searched for "AODV routing" but did not find.  Could you point to the particular occurrence so that I can understand the confusion? > IMO the operation mode is not used correctly, we need to identify the > protocol not by the MoP, we will use them all then, it should be > reserved for network operations not for protocols. > I am O.K. with recasting the new messages so that they do not use another MoP.  That is a very easy change to make.  I will await to see if others agree. > IMHO, the Message format of dio is not correct needs to have type then > the length format as shown in the dio format specification rfc6550. Looking at Figure 14 in RFC 6550, I do not see a length field.   The DIO shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 of RFC 6550.   Did you have something else in mind about this? > > IMO, this protocol Sequence number is not different than the sequence > number of destination mentioned in RFC6550. You must include the DTSN > in this draft. If you thinks I am wrong please mention why here and > then it should be clear what is the different than RPL in the draft? > I will get back to you on this point. > Security section needs to include rfc6552/rfc6553 > RFC 6552 is about the Objective Function Zero, which isn't directly related to security.  RFC 6553 is about putting RPL control information in Data-Plane packets, which we do not use for AODV-RPL.  However that is an interesting idea worth discussion, albeit not necessarily in the security section.  I would be very curious to find out if RFC 6553 has attracted much implementation. > I suggest to delete future work section. > It's not normative, and fairly reflects some useful discussion that we have had.  Do you think it is confusing for the rest of the document? Regards, Charlie P. --------------195935222C06FD4FFA5949A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Abdussalam,

Thanks for your comments and suggestions.  Please find some follow-up comments below.


On 1/5/2018 12:04 PM, Abdussalam Baryun wrote:
Hi WG,

The abstract needs to delete any indication that this is a routing protocol. IMHO, this is a route discovery for the RPL protocol.


To me AODV-RPL is a variation on RPL.  But I am curious to know more about the distinction between a routing protocol and a route discovery mechanism that uses routing protocol control messages.


The discovery of route is part of the routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to mention if this AODV-RPL can work with RPL or not in the same network.


Yes, AODV-RPL should interoperate quite well with RPL in the same network.  If there is some case that presents difficulty please let us know and we will analyze it further.

IMO, the draft needs to describe the neighbor discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or the draft shows the difference from RFC6650 discovery. Please refer to sections in RFC6550 RPL.


I don't really know what to make of this, until after I can better understand the difference between a routing protocol and a route discovery mechanism that uses routing protocol control messages.

 

AODV-RPL instance are another type of RPL-Instances, so why you write the AODV instance.




Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL instances or this AODV-RPL instance defined as RPL instance.


I looked for the strings "AODV instance" and "AODV-RPL instance" but did not find.  Could you point to the particular occurrence so that I can understand the conflict?


Delete the writing words 'AODV routing' from the draft, and delete AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV is already well known.


Thanks for acknowledging the work on AODV.  I am hoping AODVv2 completes Last Call soon.  However, I searched for "AODV routing" but did not find.  Could you point to the particular occurrence so that I can understand the confusion?


IMO the operation mode is not used correctly, we need to identify the protocol not by the MoP, we will use them all then, it should be reserved for network operations not for protocols.


I am O.K. with recasting the new messages so that they do not use another MoP.  That is a very easy change to make.  I will await to see if others agree.

IMHO, the Message format of dio is not correct needs to have type then the length format as shown in the dio format specification rfc6550.

Looking at Figure 14 in RFC 6550, I do not see a length field.   The DIO shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 of RFC 6550.   Did you have something else in mind about this?



IMO, this protocol Sequence number is not different than the sequence number of destination mentioned in RFC6550. You must include the DTSN in this draft. If you thinks I am wrong please mention why here and then it should be clear what is the different than RPL in the draft?


I will get back to you on this point.


Security section needs to include rfc6552/rfc6553


RFC 6552 is about the Objective Function Zero, which isn't directly related to security.  RFC 6553 is about putting RPL control information in Data-Plane packets, which we do not use for AODV-RPL.  However that is an interesting idea worth discussion, albeit not necessarily in the security section.  I would be very curious to find out if RFC 6553 has attracted much implementation.


I suggest to delete future work section.


It's not normative, and fairly reflects some useful discussion that we have had.  Do you think it is confusing for the rest of the document?

Regards,
Charlie P.

--------------195935222C06FD4FFA5949A6-- From nobody Mon Feb 26 17:00:01 2018 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 B348112DA01 for ; Mon, 26 Feb 2018 17:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 aP-_AYqf25ep for ; Mon, 26 Feb 2018 16:59:58 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5176124BAC for ; Mon, 26 Feb 2018 16:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1519693197; bh=IKGHIhA5fQf8SyIdFSbg2qISSLXJlIJi8H7p cmrvr+U=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=g6NVQph3XEiJl5ng8/Tagg2h9grk9U0qi VyseVmMTUz9p+5p50PyJc6lx7aVaofRY3hOxvAzulzcXRY3oqO+qX3NnbXTTYRDItFv lkL5sU1Xvqq4+gv7wdvAPiq9rZ8FznZlci8ZQ58tyc/RYEN+kN+hwuLojgspWSy7+SQ a3RqKeIURMZqkP/vPcBRfhzxa93pnTetchfqlkMniEpCaQMwW3n+pl6W3cFU+N1ZpXT wPIgfLuBnoBKKXK2BEZUj/cEV0h/bdm7ehheZdGSXuMubWl0GnOo6otsdkBQ6U0RnSL ShXD7CmIzQGbVY4Ui/vSluIYKxNlaKZQP7FK2X2Ug== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=raHq/GZzRSt/XDppLBt5Cj7eT7AoDstFX+34VHEqeoCcIrqiK4kEBxewA8Zh57wvvp1riiI0HCqQAEVdXczSN1DgK8DO2POw2URIbvUTG/uo+NEkSMAi9hB5BAcOTCuZsQlqd2s7rBgUY1zPQQjuYm5f1wW4uoM2fKawhUwV6nmNBqPtueiOX9bty1Bt+se0a3vf3MiWv/uqBYlHCkMcMwRPbIlTc1/BYnE1sZ/TiV6pPvmEui18FWWdg3RJa8v21oC9J9IdGQphDrnfkX/7/KUUaWYFCkgi7qmdwjj8JNT8uHBdej5cJa3G+wiMqFp9YCPVFq57JiAKbxGL6FELRA==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1eqTcZ-0001Nw-FP; Mon, 26 Feb 2018 19:59:55 -0500 To: Rahul Jadhav , "Liubing (Remy)" Cc: "Zhangmingui (Martin)" , Routing Over Low power and Lossy networks References: From: Charlie Perkins Message-ID: <4522ddc7-2e99-a576-676b-1891af44f42d@earthlink.net> Date: Mon, 26 Feb 2018 16:59:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8BDD115CBDACD35940007565" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95f5382fc341280db2f6fce242ba7a73cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 01:00:01 -0000 This is a multi-part message in MIME format. --------------8BDD115CBDACD35940007565 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Rahul, Follow-up below to your comments... On 1/5/2018 3:42 AM, Rahul Jadhav wrote: > > [Remy] I think we have a misunderstanding here. “Bidirectional” talks > about the reachability, while “symmetric” talks about the upward and > downward routes. The “asymmetric” here signifies the upward and > downward routes between the OrigNode and the TargNode are different, > while "bidirectional" means control messages can be received in two > directions. Both RPL and AODV-RPL use bidirectional links. > > > [RJ] I m not very clear of this text. AODV-RPL cannot depend on > bidirectional links to establish asymmetric paths. We state in the draft that the protocol is applicable to networks that have bidirectional but asymmetric links.  We can put in black hole detection if that is preferred.  It is well-known how to do this, and AODV does do it, but the cost is a small bit of overhead and stateful operation. > > > [Remy] The upstream destination is the OrigNode, which is the root > of the DODAG. An intermediate node only needs to maintain a route > entry to the OrigNode, including the information of the next hop > on the upstream route. The next hop is actually the node’s > preferred parent in this DODAG. > > > [RJ] I understand that from the routing table perspective only the > OrigNode entry has to be established. My point was in context to > identifying/probing adjoining next hop through which this route would > be established. For this probing you need to maintain a table which > will have all adjoining peers. I think the protocol will work even without maintaining such a neighbor table.  Even when the table is maintained, it is always possible for the information in it to grow stale. > > [Remy] The node doesn’t have to probe all its neighbor. Don’t > forget that AODV-RPL is an extension of RPL, and the RREP and RREQ > are two new DIO options. Thus the DIO transmission, local repair > and many other mechanisms to maintain the state are the same as > RPL.  Therefore, the control overhead will stay the same. > > > [RJ] I understand that the DIO transmission, and other factors remain > the same. Adding RREP/RREQ on top of existing DIO messaging does not > achieve asymmetric paths. When OrigNode sends a DIO, its received by > another node downstream and the path is established upstream. This is > the mechanism RPL follows. Also AODV-RPL follows the same signalling > mechanism and this is where the problem starts with the asymmetric > path claim. But, AODV-RPL *does* allow establishment of asymmetric peer-to-peer paths, as advertised.  I agree that the signaling mechanism is not radically different, and I consider that a good thing.  But it is different. > > [RJ]: No. Probing cannot be done the same way. In case of RPL, DIO is > sent downstream and the downstream nodes use DIO metrics and messaging > signal qualities to establish upstream path. This is ok in case of RPL > because RPL says that it depends upon bidirectional connectivity (not > necessarily symmetric but still bidirectional for e.g. power levels in > both direction might vary but the messaging still works) for it to work. > Now for AODV-RPL's asymmetric claim to work, the upstream and > downstream paths between the same pair of nodes can be different. For > asymmetric links, AODV-RPL cannot depend upon RPL's style of DIO > messaging. Can you be more specific about where the AODV-RPL mechanism fails? Maybe an example would be helpful. Regards, Charlie P. --------------8BDD115CBDACD35940007565 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Rahul,

Follow-up below to your comments...


On 1/5/2018 3:42 AM, Rahul Jadhav wrote:

[Remy] I think we have a misunderstanding here. “Bidirectional” talks about the reachability, while “symmetric” talks about the upward and downward routes. The “asymmetric” here signifies the upward and downward routes between the OrigNode and the TargNode are different, while "bidirectional" means control messages can be received in two directions. Both RPL and AODV-RPL use bidirectional links.


[RJ] I m not very clear of this text. AODV-RPL cannot depend on bidirectional links to establish asymmetric paths.

We state in the draft that the protocol is applicable to networks that have bidirectional but asymmetric links.  We can put in black hole detection if that is preferred.  It is well-known how to do this, and AODV does do it, but the cost is a small bit of overhead and stateful operation.



[Remy] The upstream destination is the OrigNode, which is the root of the DODAG. An intermediate node only needs to maintain a route entry to the OrigNode, including the information of the next hop on the upstream route. The next hop is actually the node’s preferred parent in this DODAG.


[RJ] I understand that from the routing table perspective only the OrigNode entry has to be established. My point was in context to identifying/probing adjoining next hop through which this route would be established. For this probing you need to maintain a table which will have all adjoining peers.

I think the protocol will work even without maintaining such a neighbor table.  Even when the table is maintained, it is always possible for the information in it to grow stale.


[Remy] The node doesn’t have to probe all its neighbor. Don’t forget that AODV-RPL is an extension of RPL, and the RREP and RREQ are two new DIO options. Thus the DIO transmission, local repair and many other mechanisms to maintain the state are the same as RPL.  Therefore, the control overhead will stay the same.


[RJ] I understand that the DIO transmission, and other factors remain the same. Adding RREP/RREQ on top of existing DIO messaging does not achieve asymmetric paths. When OrigNode sends a DIO, its received by another node downstream and the path is established upstream. This is the mechanism RPL follows. Also AODV-RPL follows the same signalling mechanism and this is where the problem starts with the asymmetric path claim.

But, AODV-RPL *does* allow establishment of asymmetric peer-to-peer paths, as advertised.  I agree that the signaling mechanism is not radically different, and I consider that a good thing.  But it is different.

 

[RJ]: No. Probing cannot be done the same way. In case of RPL, DIO is sent downstream and the downstream nodes use DIO metrics and messaging signal qualities to establish upstream path. This is ok in case of RPL because RPL says that it depends upon bidirectional connectivity (not necessarily symmetric but still bidirectional for e.g. power levels in both direction might vary but the messaging still works) for it to work. 
Now for AODV-RPL's asymmetric claim to work, the upstream and downstream paths between the same pair of nodes can be different. For asymmetric links, AODV-RPL cannot depend upon RPL's style of DIO messaging.

Can you be more specific about where the AODV-RPL mechanism fails?  Maybe an example would be helpful.



Regards,
Charlie P.
--------------8BDD115CBDACD35940007565-- From nobody Mon Feb 26 17:21:11 2018 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 80D6F12DA22; Mon, 26 Feb 2018 17:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 FepLMDUVowtS; Mon, 26 Feb 2018 17:21:06 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571ED12DA25; Mon, 26 Feb 2018 17:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1519694466; bh=24WB/xqZlPmlFRGr4zMN1eHPK0of4aqp1wrH opJ4Kiw=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=aImyl+h2WD9G9dVdAN7payogGOVJdE4Qj hWVgOJeATsu3H3nOlA6A2baT5kbtUpMZRHaS5kvsmJMpYPqQy9nt2Cx/0/Fg8a9I1og /kB6byZ8/U4lPeEgANS8BKe1uoAQkjS6eTCzBfq8DvwgLhLQRKhI9tqMsfDsJU+wQ7G l4R4WRv8EX9FnDPngUNZLXvL7/4X2963AemYz6DNvUsY8j8j9xy0UMB+5e/k2pYFzRF hOzBlaztPaIVgrUvQ3enfXVifBi5FqiUMK+INyoVjdj4BuZSh4QmfqrqONcbULYPXmz BSH8w7CfI7vDEFe2Fh2qoCWbQJhyMgkv1srg0WwWw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=l1GA9xk4shL0+kmEY3xZ/zN5yns4Iui9y+VwiYVvmjQP9/1Jx+4ZnJNDUbjEn1eJQfHd3hPY89KcSH7cGG0f7w82Z0cjMCm15TeYfl1+cQK9mOBGM+ZpPV7BB+IgDJSTohbRGF0prgThxT9W8st3olKE6DQgupem6dkF5tBiR1QEa35ttLWOYzE1BBvm6BVJG0/wcIr+YAOym5Lx2qpMtoZUj1KqENmJQQcipUEJLZNjnEg8z4UXgB41FqAdEXHRrPPk9mFIhk0ApgVBgQq3NkH/t19MW/iUItYoxzqauIwxS515OaYE9Z4EbA7HIAHzN4Wbbtroa2O1NQ8EuBNRFw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1eqTx2-000Am8-Iz; Mon, 26 Feb 2018 20:21:04 -0500 To: Abdussalam Baryun , roll , draft-ietf-roll-aodv-rpl@ietf.org References: From: Charlie Perkins Message-ID: <8eec0bae-6416-2fec-76bb-486fa17ec656@earthlink.net> Date: Mon, 26 Feb 2018 17:21:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A1B7AB75B35150ECCF620625" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c9592af28a4d899ecb1c330b8738adff81a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [Roll] Typo!! X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 01:21:08 -0000 This is a multi-part message in MIME format. --------------A1B7AB75B35150ECCF620625 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello folks, Sorry about that...  below, where I had "Figure 15", I meant to say "Figure 14". Regards, Charlie P. On 2/26/2018 2:04 PM, Charlie Perkins wrote: > > Hello Abdussalam, > > Thanks for your comments and suggestions.  Please find some follow-up > comments below. > > > On 1/5/2018 12:04 PM, Abdussalam Baryun wrote: >> Hi WG, >> >> The abstract needs to delete any indication that this is a routing >> protocol. IMHO, this is a route discovery for the RPL protocol. >> > > To me AODV-RPL is a variation on RPL.  But I am curious to know more > about the distinction between a routing protocol and a route discovery > mechanism that uses routing protocol control messages. > > >> The discovery of route is part of the routing protocol so we have a >> different routing which is AODV-RPL routing protocol. The draft needs >> to mention if this AODV-RPL can work with RPL or not in the same network. >> > > Yes, AODV-RPL should interoperate quite well with RPL in the same > network.  If there is some case that presents difficulty please let us > know and we will analyze it further. > >> IMO, the draft needs to describe the neighbor discovery combined with >> AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and >> 18.6 in rfc6550. Or the draft shows the difference from RFC6650 >> discovery. Please refer to sections in RFC6550 RPL. >> > > I don't really know what to make of this, until after I can better > understand the difference between a routing protocol and a route > discovery mechanism that uses routing protocol control messages. > >> AODV-RPL instance are another type of RPL-Instances, so why you write >> the AODV instance. >> > > > >> Please note that this will conflict with MANET routing instances. >> Please delete AODV instance. This draft needs to have only RPL >> instances or this AODV-RPL instance defined as RPL instance. >> > > I looked for the strings "AODV instance" and "AODV-RPL instance" but > did not find.  Could you point to the particular occurrence so that I > can understand the conflict? > > >> Delete the writing words 'AODV routing' from the draft, and delete >> AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV >> is already well known. >> > > Thanks for acknowledging the work on AODV.  I am hoping AODVv2 > completes Last Call soon.  However, I searched for "AODV routing" but > did not find.  Could you point to the particular occurrence so that I > can understand the confusion? > > >> IMO the operation mode is not used correctly, we need to identify the >> protocol not by the MoP, we will use them all then, it should be >> reserved for network operations not for protocols. >> > > I am O.K. with recasting the new messages so that they do not use > another MoP.  That is a very easy change to make.  I will await to see > if others agree. > >> IMHO, the Message format of dio is not correct needs to have type >> then the length format as shown in the dio format specification rfc6550. > > Looking at Figure 14 in RFC 6550, I do not see a length field. The DIO > shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 > of RFC 6550.   Did you have something else in mind about this? > > >> >> IMO, this protocol Sequence number is not different than the sequence >> number of destination mentioned in RFC6550. You must include the DTSN >> in this draft. If you thinks I am wrong please mention why here and >> then it should be clear what is the different than RPL in the draft? >> > > I will get back to you on this point. > > >> Security section needs to include rfc6552/rfc6553 >> > > RFC 6552 is about the Objective Function Zero, which isn't directly > related to security.  RFC 6553 is about putting RPL control > information in Data-Plane packets, which we do not use for AODV-RPL.  > However that is an interesting idea worth discussion, albeit not > necessarily in the security section.  I would be very curious to find > out if RFC 6553 has attracted much implementation. > > >> I suggest to delete future work section. >> > > It's not normative, and fairly reflects some useful discussion that we > have had.  Do you think it is confusing for the rest of the document? > > Regards, > Charlie P. > --------------A1B7AB75B35150ECCF620625 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello folks,

Sorry about that...  below, where I had "Figure 15", I meant to say "Figure 14".

Regards,
Charlie P.


On 2/26/2018 2:04 PM, Charlie Perkins wrote:

Hello Abdussalam,

Thanks for your comments and suggestions.  Please find some follow-up comments below.


On 1/5/2018 12:04 PM, Abdussalam Baryun wrote:
Hi WG,

The abstract needs to delete any indication that this is a routing protocol. IMHO, this is a route discovery for the RPL protocol.


To me AODV-RPL is a variation on RPL.  But I am curious to know more about the distinction between a routing protocol and a route discovery mechanism that uses routing protocol control messages.


The discovery of route is part of the routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to mention if this AODV-RPL can work with RPL or not in the same network.


Yes, AODV-RPL should interoperate quite well with RPL in the same network.  If there is some case that presents difficulty please let us know and we will analyze it further.

IMO, the draft needs to describe the neighbor discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or the draft shows the difference from RFC6650 discovery. Please refer to sections in RFC6550 RPL.


I don't really know what to make of this, until after I can better understand the difference between a routing protocol and a route discovery mechanism that uses routing protocol control messages.

 

AODV-RPL instance are another type of RPL-Instances, so why you write the AODV instance.




Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL instances or this AODV-RPL instance defined as RPL instance.


I looked for the strings "AODV instance" and "AODV-RPL instance" but did not find.  Could you point to the particular occurrence so that I can understand the conflict?


Delete the writing words 'AODV routing' from the draft, and delete AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV is already well known.


Thanks for acknowledging the work on AODV.  I am hoping AODVv2 completes Last Call soon.  However, I searched for "AODV routing" but did not find.  Could you point to the particular occurrence so that I can understand the confusion?


IMO the operation mode is not used correctly, we need to identify the protocol not by the MoP, we will use them all then, it should be reserved for network operations not for protocols.


I am O.K. with recasting the new messages so that they do not use another MoP.  That is a very easy change to make.  I will await to see if others agree.

IMHO, the Message format of dio is not correct needs to have type then the length format as shown in the dio format specification rfc6550.

Looking at Figure 14 in RFC 6550, I do not see a length field.   The DIO shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 of RFC 6550.   Did you have something else in mind about this?



IMO, this protocol Sequence number is not different than the sequence number of destination mentioned in RFC6550. You must include the DTSN in this draft. If you thinks I am wrong please mention why here and then it should be clear what is the different than RPL in the draft?


I will get back to you on this point.


Security section needs to include rfc6552/rfc6553


RFC 6552 is about the Objective Function Zero, which isn't directly related to security.  RFC 6553 is about putting RPL control information in Data-Plane packets, which we do not use for AODV-RPL.  However that is an interesting idea worth discussion, albeit not necessarily in the security section.  I would be very curious to find out if RFC 6553 has attracted much implementation.


I suggest to delete future work section.


It's not normative, and fairly reflects some useful discussion that we have had.  Do you think it is confusing for the rest of the document?

Regards,
Charlie P.


--------------A1B7AB75B35150ECCF620625-- From nobody Tue Feb 27 13:02:53 2018 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 9ACEF12D94C; Tue, 27 Feb 2018 13:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 Vtw-M68phVX7; Tue, 27 Feb 2018 13:02:49 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9AD12D951; Tue, 27 Feb 2018 13:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1519765369; bh=U0i3LtzzHhwt7lr3LgsROj5lclk4hj2LU40C PR2cs7Q=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=HapLgLKAgFOWify519jgl7qEL/7BRs+3f AxmxlWmisw1hE2qbgtNCERNPPldw7fBaViPtWeTeHn9n4m2+41ksSa0DLGQ7avcSlUN BvuzTs1dWW9n3I0FQLgN21ntO/mmFt5Tfdr9dxxnco5T7+IfRihvlI0sRvTQ8NF6Vgt eK1+Iubjwk8ickJOwCSP08CGG3oMG/q34Aymfg/sV0La8Qm5Ac0bdJNeDnvfbHS/aG+ x71pfSYKYCESsPNkUk9dsz6ApqP/lrvzO/FwYWkB+MbAUG2B0PN94ZFqkT8LlUIbK24 /RoIv91SZws7r1pged3OcmmiG9UfuGEFLOiYUPLcQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=f2+iS7tGzMcXKWY7NJKSwFfAlsLapuBa8fihqRkRG0ylMmsmuz2ncdQtNNpm2dqgz3kP9vHnIi88FUlWfZz4BBG2zEx/dXdJZKofem0oMqjoYGJ6GbqPhdLhM7BE9rRMyyfXDii2PDEdt/Pm26Ul9HadkImQ6cMDXYQYcG0A3mMbv/F14ea0J6zSAKyNQCXhSRhP6mpQbTfSlvAkBOB88KoMMTsIUK1bJp1GRISnrc/pcVyUGWny2sKNQ7vj6CTmo5SrZwD5URuyYZ62XiwsKkGZE6V9lrlOzPmKMuRDbkqZVoVyUzvebk1oVEt14AzwC+OXDLJlrn9BkUdIp9Lc9Q==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1eqmOd-0009xX-2G; Tue, 27 Feb 2018 16:02:47 -0500 To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Cc: peter van der Stok , draft-ietf-roll-aodv-rpl@ietf.org References: <25c2ea6bb3b44cd69d4e93c57e7a5c20@XCH-RCD-001.cisco.com> From: Charlie Perkins Message-ID: Date: Tue, 27 Feb 2018 13:02:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <25c2ea6bb3b44cd69d4e93c57e7a5c20@XCH-RCD-001.cisco.com> Content-Type: multipart/alternative; boundary="------------A9EC00716D233CEBF9FE9660" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95ce5b9ed936102eb86cac79af48a7c45e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 21:02:52 -0000 This is a multi-part message in MIME format. --------------A9EC00716D233CEBF9FE9660 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Pascal, Thanks for the comments!  Please find some follow-up below. On 12/1/2017 7:35 AM, Pascal Thubert (pthubert) wrote: > > Deal all : > > Overall I do not think that the document is ready for the next stage > yet. Comparing to draft-perkins-manet-aodvv2 > I find > the protocol description quite thin and I do not see the inheritance > that I expected. E.g. I expected a more direct mapping, like, same > behavior, different message formats, this maps to that,  all this ins > inherited, or something. Can we do something to provide a better > alignment? > AODVv2 has a number of useful features that could be imported into AODV-RPL.  As mentioned in another email, we could widen the applicability to include unidirectional links by specifying AODVv2's black hole detection mechanism.  But this would take a while.  If the WG is O.K. with that, I am also O.K. - I am author of AODVv2, and I do not see any technical barriers.  If you have particular features of interest, please do not hesitate to suggest.  Recent revisions specify nicer handling for multi-gateway solutions, multiple metrics, and so on. > I do not see lessons learned from experimental RFC6997; Do we have > any? In some aspects I even see a (fixable) regression, e.g. the use > of target option. > We don't have text for that comparison.  I hope that it is not a requirement.  Perhaps one valuable lesson learned is that no one has pointed out how RFC 6997 methods are damaging to implement, so that the general idea is not dangerous.  But this is speculation on my part. I don't see any reason why we cannot specify the target option for use within AODV-RPL.  It could be that this will not be completed before the submission deadline for IETF 101, but we will work on it. > Also, I’m wondering: Do we have implementations? > > Please find more  comments below: > > *5**.  > RREQ Message* > > I suggest you use a Target option for carry the target and limit your > new potion carry the sequence numbers. RFC 6997 does that already. > This allows you to do many things, including looking up more than one > target with a single RREQ, building more than one RREQ DODAGs for > mostly the price of one. Why should we lose that feature? > I can only say that the issue was not raised before.  I do not have any objection to including the feature. > In order to establish the upstream route from TargNode to OrigNode, > > OrigNode multicasts the RREQ-Instance message (see Figure 4) to its > > one-hop neighbours.  In order to enable intermediate nodes R_i to > > associate a future RREP message to an incoming RREQ message, the > > InstanceID of RREQ-Instance MUST assign an odd number. > > RFC 6997 uses local intances for P2P routes. In fact we defined local > instances in RPL RFC 6550 for that specific purpose. The advantage is > that the instance number is managed locally by the source. The concept > of direction is also already included in a local instance. > We do have the instance number managed locally by the source, so I think this is O.K. >    When an intermediate node R_i receives a RREQ message in storing >    mode, it MUST store the OrigNode's InstanceID (RREQ-Instance) along >    with the other routing information needed to establish the route back >    to the OrigNode.  This will enable R_i to determine that a future >    RREP message (containing a paired InstanceID for the TargNode) must >    be transmitted back to the OrigNode's IP address. > > Information of lifetime is important here. How long should that > transient state be maintained? What happens when a node cannot hold > that information because it is temporarily saturated? > I agree it will be a good idea to specify a lifetime for this purpose. > RFC6997 has metrics that provide a boundary of how ‘far’ a lookup can > get, e.g. the maximum acceptable cost for a route. This avoids a > flooding throughout a larger network. What do we have here? > This is also a good idea. > > 6. > RREP Message > > Same as the RRAQ, please split to use a target option. This saves you > the logic of the T bit, just do not place the target option. > O.K.  Thanks for the suggestion. >     R determines whether its information is sufficiently recent by >    comparing the value it has stored for the Sequence Number of TargNode >    against the DestSeqno in the incoming RREQ message. > > > How is the comparison done? You need to explain how you handle > wrapping Sequence Number. See RPL > 7.2.  Sequence > Counter Operation > Will do. > >    In order to reduce the need for the TargNode IPv6 Address to be >    included with the RREP message, the InstanceID of the RREP-Instance >    is paired, whenever possible, with the InstanceID from the RREQ >    message, which is always an odd number.  The pairing is accomplished >    by adding one to the InstanceID from the RREQ message and using that, >    whenever possible, as the InstanceID for the RREP message. > > This forces the need for a globally unique instance ID. Really a > debatable idea and limits the applicability way below what RFC 6997 > can do. > I really do not think that it forces a globally unique instance ID. It can occasionally (?rarely?) be limited by what local instance ID numbers have already been used by the target node, though. > How does the instance ID get assigned? > Can't OrigNode just pick whatever ID it wants? Regards, Charlie P. --------------A9EC00716D233CEBF9FE9660 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Pascal,

Thanks for the comments!  Please find some follow-up below.


On 12/1/2017 7:35 AM, Pascal Thubert (pthubert) wrote:

Deal all :

 

Overall I do not think that the document is ready for the next stage yet. Comparing to draft-perkins-manet-aodvv2 I find the protocol description quite thin and I do not see the inheritance that I expected. E.g. I expected a more direct mapping, like, same behavior, different message formats, this maps to that,  all this ins inherited, or something. Can we do something to provide a better alignment?



AODVv2 has a number of useful features that could be imported into AODV-RPL.  As mentioned in another email, we could widen the applicability to include unidirectional links by specifying AODVv2's black hole detection mechanism.  But this would take a while.  If the WG is O.K. with that, I am also O.K. - I am author of AODVv2, and I do not see any technical barriers.  If you have particular features of interest, please do not hesitate to suggest.  Recent revisions specify nicer handling for multi-gateway solutions, multiple metrics, and so on.


 

 

I do not see lessons learned from experimental RFC6997; Do we have any? In some aspects I even see a (fixable) regression, e.g. the use of target option.


We don't have text for that comparison.  I hope that it is not a requirement.  Perhaps one valuable lesson learned is that no one has pointed out how RFC 6997 methods are damaging to implement, so that the general idea is not dangerous.  But this is speculation on my part.

I don't see any reason why we cannot specify the target option for use within AODV-RPL.  It could be that this will not be completed before the submission deadline for IETF 101, but we will work on it.


 

Also, I’m wondering: Do we have implementations?

 

Please find more  comments below:

 

5.  RREQ Message

I suggest you use a Target option for carry the target and limit your new potion carry the sequence numbers. RFC 6997 does that already. This allows you to do many things, including looking up more than one target with a single RREQ, building more than one RREQ DODAGs for mostly the price of one. Why should we lose that feature?


I can only say that the issue was not raised before.  I do not have any objection to including the feature.


 

 

   In order to establish the upstream route from TargNode to OrigNode,

   OrigNode multicasts the RREQ-Instance message (see Figure 4) to its

   one-hop neighbours.  In order to enable intermediate nodes R_i to

   associate a future RREP message to an incoming RREQ message, the

   InstanceID of RREQ-Instance MUST assign an odd number.

 

RFC 6997 uses local intances for P2P routes. In fact we defined local instances in RPL RFC 6550 for that specific purpose. The advantage is that the instance number is managed locally by the source. The concept of direction is also already included in a local instance.


We do have the instance number managed locally by the source, so I think this is O.K.


 

 

   When an intermediate node R_i receives a RREQ message in storing
   mode, it MUST store the OrigNode's InstanceID (RREQ-Instance) along
   with the other routing information needed to establish the route back
   to the OrigNode.  This will enable R_i to determine that a future
   RREP message (containing a paired InstanceID for the TargNode) must
   be transmitted back to the OrigNode's IP address.

 

Information of lifetime is important here. How long should that transient state be maintained? What happens when a node cannot hold that information because it is temporarily saturated?


I agree it will be a good idea to specify a lifetime for this purpose.

RFC6997 has metrics that provide a boundary of how ‘far’ a lookup can get, e.g. the maximum acceptable cost for a route. This avoids a flooding throughout a larger network. What do we have here?


This is also a good idea.

 

 

6.  RREP Message

Same as the RRAQ, please split to use a target option. This saves you the logic of the T bit, just do not place the target option.


O.K.  Thanks for the suggestion.

 

 

    R determines whether its information is sufficiently recent by
   comparing the value it has stored for the Sequence Number of TargNode
   against the DestSeqno in the incoming RREQ message.

 

How is the comparison done? You need to explain how you handle wrapping Sequence Number. See RPL  7.2.  Sequence Counter Operation


Will do. 

 

 

 

   In order to reduce the need for the TargNode IPv6 Address to be
   included with the RREP message, the InstanceID of the RREP-Instance
   is paired, whenever possible, with the InstanceID from the RREQ
   message, which is always an odd number.  The pairing is accomplished
   by adding one to the InstanceID from the RREQ message and using that,
   whenever possible, as the InstanceID for the RREP message. 

 

This forces the need for a globally unique instance ID. Really a debatable idea and limits the applicability way below what RFC 6997 can do.


I really do not think that it forces a globally unique instance ID.  It can occasionally (?rarely?) be limited by what local instance ID numbers have already been used by the target node, though.


How does the instance ID get assigned?


Can't OrigNode just pick whatever ID it wants?

Regards,
Charlie P.

--------------A9EC00716D233CEBF9FE9660-- From nobody Tue Feb 27 15:16:54 2018 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E799B12EAE8; Tue, 27 Feb 2018 15:11:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: roll@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307590.5200.2225518973060960803.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:15 -0800 Archived-At: Subject: [Roll] roll - Requested sessions have been scheduled for IETF 101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:21 -0000 Dear Ines Robles, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. roll Session 1 (2:00:00) Friday, Morning Session I 0930-1130 Room Name: Viscount size: 175 --------------------------------------------- roll Session 2 (2:00:00) Thursday, Morning Session I 0930-1200 Room Name: Park Suite size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: anima manet 6tisch core ace Second Priority: rtgarea 6lo 6man lwig cbor t2trg Third Priority: rtgwg intarea lpwan People who must be present: Michael Richardson Peter Van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: Meetecho Support --------------------------------------------------------- From nobody Wed Feb 28 22:34:37 2018 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 1A9621267BB; Wed, 28 Feb 2018 22:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_jvDAalMJzR; Wed, 28 Feb 2018 22:34:33 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1081241F8; Wed, 28 Feb 2018 22:34:33 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E7D34FAE05E1F; Thu, 1 Mar 2018 06:34:29 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Mar 2018 06:34:30 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Thu, 1 Mar 2018 14:34:26 +0800 From: "Liubing (Remy)" To: Routing Over Low power and Lossy networks , "draft-ietf-roll-aodv-rpl@ietf.org" Thread-Topic: [Roll] Comments for AODV-RPL protocol [Issue #184] Thread-Index: AQHTr04bfDVhyYzxf02Ud8Ztj+d15qO6q0yw Date: Thu, 1 Mar 2018 06:34:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2EDD3B08DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Comments for AODV-RPL protocol [Issue #184] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 06:34:36 -0000 --_000_BB09947B5326FE42BA3918FA28765C2EDD3B08DGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWJkdXNzYWxhbSBhbmQgQ2hhcmxpZSwNCg0KUGxlYXNlIGZpbmQgbXkgY29tbWVudHMg aW5saW5lLg0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2hhcmxpZSBQZXJraW5zDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNywgMjAx OCA2OjA0IEFNDQpUbzogQWJkdXNzYWxhbSBCYXJ5dW4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwu Y29tPjsgcm9sbCA8cm9sbEBpZXRmLm9yZz47IGRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtSb2xsXSBDb21tZW50cyBmb3IgQU9EVi1SUEwgcHJvdG9jb2wg W0lzc3VlICMxODRdDQoNCg0KSGVsbG8gQWJkdXNzYWxhbSwNCg0KVGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gIFBsZWFzZSBmaW5kIHNvbWUgZm9sbG93LXVwIGNvbW1l bnRzIGJlbG93Lg0KDQpPbiAxLzUvMjAxOCAxMjowNCBQTSwgQWJkdXNzYWxhbSBCYXJ5dW4gd3Jv dGU6DQpIaSBXRywNCg0KDQpUaGUgYWJzdHJhY3QgbmVlZHMgdG8gZGVsZXRlIGFueSBpbmRpY2F0 aW9uIHRoYXQgdGhpcyBpcyBhIHJvdXRpbmcgcHJvdG9jb2wuIElNSE8sIHRoaXMgaXMgYSByb3V0 ZSBkaXNjb3ZlcnkgZm9yIHRoZSBSUEwgcHJvdG9jb2wuDQoNClRvIG1lIEFPRFYtUlBMIGlzIGEg dmFyaWF0aW9uIG9uIFJQTC4gIEJ1dCBJIGFtIGN1cmlvdXMgdG8ga25vdyBtb3JlIGFib3V0IHRo ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcm91dGluZyBwcm90b2NvbCBhbmQgYSByb3V0ZSBkaXNj b3ZlcnkgbWVjaGFuaXNtIHRoYXQgdXNlcyByb3V0aW5nIHByb3RvY29sIGNvbnRyb2wgbWVzc2Fn ZXMuDQoNCg0KDQoNClRoZSBkaXNjb3Zlcnkgb2Ygcm91dGUgaXMgcGFydCBvZiB0aGUgcm91dGlu ZyBwcm90b2NvbCBzbyB3ZSBoYXZlIGEgZGlmZmVyZW50IHJvdXRpbmcgd2hpY2ggaXMgQU9EVi1S UEwgcm91dGluZyBwcm90b2NvbC4gVGhlIGRyYWZ0IG5lZWRzIHRvIG1lbnRpb24gaWYgdGhpcyBB T0RWLVJQTCBjYW4gd29yayB3aXRoIFJQTCBvciBub3QgaW4gdGhlIHNhbWUgbmV0d29yay4NCg0K WWVzLCBBT0RWLVJQTCBzaG91bGQgaW50ZXJvcGVyYXRlIHF1aXRlIHdlbGwgd2l0aCBSUEwgaW4g dGhlIHNhbWUgbmV0d29yay4gIElmIHRoZXJlIGlzIHNvbWUgY2FzZSB0aGF0IHByZXNlbnRzIGRp ZmZpY3VsdHkgcGxlYXNlIGxldCB1cyBrbm93IGFuZCB3ZSB3aWxsIGFuYWx5emUgaXQgZnVydGhl ci4NCltSZW15XSBTaW5jZSBBT0RWLVJQTCBkZWZpbmVzIG5ldyBSUEwgY29udHJvbCBtZXNzYWdl IG9wdGlvbiBpbiB0aGUgZnJhbWV3b3JrIG9mIGNvcmUgUlBMLiBUaGUgdHdvIHByb3RvY29scyBz aG91bGQgd29yayB3ZWxsIGluIHRoZSBzYW1lIG5ldHdvcmsuDQoNCg0KSU1PLCB0aGUgZHJhZnQg bmVlZHMgdG8gZGVzY3JpYmUgdGhlIG5laWdoYm9yIGRpc2NvdmVyeSBjb21iaW5lZCB3aXRoIEFP RFYtUlBMIHJvdXRlIGRpc2NvdmVyeS4gQWxzbyBuZWVkcyB0byByZWZlciB0byBzZWN0aW9ucyAx OC40LjEgYW5kIDE4LjYgaW4gcmZjNjU1MC4gT3IgdGhlIGRyYWZ0IHNob3dzIHRoZSBkaWZmZXJl bmNlIGZyb20gUkZDNjY1MCBkaXNjb3ZlcnkuIFBsZWFzZSByZWZlciB0byBzZWN0aW9ucyBpbiBS RkM2NTUwIFJQTC4NCg0KSSBkb24ndCByZWFsbHkga25vdyB3aGF0IHRvIG1ha2Ugb2YgdGhpcywg dW50aWwgYWZ0ZXIgSSBjYW4gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBhIHJvdXRpbmcgcHJvdG9jb2wgYW5kIGEgcm91dGUgZGlzY292ZXJ5IG1lY2hhbmlzbSB0aGF0 IHVzZXMgcm91dGluZyBwcm90b2NvbCBjb250cm9sIG1lc3NhZ2VzLg0KDQoNCg0KDQoNCkFPRFYt UlBMIGluc3RhbmNlIGFyZSBhbm90aGVyIHR5cGUgb2YgUlBMLUluc3RhbmNlcywgc28gd2h5IHlv dSB3cml0ZSB0aGUgQU9EViBpbnN0YW5jZS4NCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRo aXMgd2lsbCBjb25mbGljdCB3aXRoIE1BTkVUIHJvdXRpbmcgaW5zdGFuY2VzLiBQbGVhc2UgZGVs ZXRlIEFPRFYgaW5zdGFuY2UuIFRoaXMgZHJhZnQgbmVlZHMgdG8gaGF2ZSBvbmx5IFJQTCBpbnN0 YW5jZXMgb3IgdGhpcyBBT0RWLVJQTCBpbnN0YW5jZSBkZWZpbmVkIGFzIFJQTCBpbnN0YW5jZS4N Cg0KSSBsb29rZWQgZm9yIHRoZSBzdHJpbmdzICJBT0RWIGluc3RhbmNlIiBhbmQgIkFPRFYtUlBM IGluc3RhbmNlIiBidXQgZGlkIG5vdCBmaW5kLiAgQ291bGQgeW91IHBvaW50IHRvIHRoZSBwYXJ0 aWN1bGFyIG9jY3VycmVuY2Ugc28gdGhhdCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBjb25mbGljdD8N CltSZW15XSBJbiB0aGUgdmVyc2lvbiB0aGF0IHdlIGFyZSBnb2luZyB0byBzdWJtaXQsIHdlIHdp bGwgY2xlYXJseSBzYXkgaW4gdGhlIHRlcm1pbm9sb2d5IHRoYXQgQU9EVi1SUEwgaW5zdGFuY2Ug KFJSRVEtSW5zdGFuY2UgYW5kIFJSRVAtSW5zdGFuY2UpIGFyZSBSUEwgaW5zdGFuY2VzLg0KDQoN Cg0KDQoNCkRlbGV0ZSB0aGUgd3JpdGluZyB3b3JkcyAnQU9EViByb3V0aW5nJyBmcm9tIHRoZSBk cmFmdCwgYW5kIGRlbGV0ZSBBT0RWIHJlZmVyZW5jZSBhcyB0aGUgSVB2NC1SRkMgbWVudGlvbmVk IChjYW4gYmUgY29uZnVzaW5nKS4gVGhlIEFPRFYgaXMgYWxyZWFkeSB3ZWxsIGtub3duLg0KDQpU aGFua3MgZm9yIGFja25vd2xlZGdpbmcgdGhlIHdvcmsgb24gQU9EVi4gIEkgYW0gaG9waW5nIEFP RFZ2MiBjb21wbGV0ZXMgTGFzdCBDYWxsIHNvb24uICBIb3dldmVyLCBJIHNlYXJjaGVkIGZvciAi QU9EViByb3V0aW5nIiBidXQgZGlkIG5vdCBmaW5kLiAgQ291bGQgeW91IHBvaW50IHRvIHRoZSBw YXJ0aWN1bGFyIG9jY3VycmVuY2Ugc28gdGhhdCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBjb25mdXNp b24/DQoNCg0KDQoNCklNTyB0aGUgb3BlcmF0aW9uIG1vZGUgaXMgbm90IHVzZWQgY29ycmVjdGx5 LCB3ZSBuZWVkIHRvIGlkZW50aWZ5IHRoZSBwcm90b2NvbCBub3QgYnkgdGhlIE1vUCwgd2Ugd2ls bCB1c2UgdGhlbSBhbGwgdGhlbiwgaXQgc2hvdWxkIGJlIHJlc2VydmVkIGZvciBuZXR3b3JrIG9w ZXJhdGlvbnMgbm90IGZvciBwcm90b2NvbHMuDQoNCkkgYW0gTy5LLiB3aXRoIHJlY2FzdGluZyB0 aGUgbmV3IG1lc3NhZ2VzIHNvIHRoYXQgdGhleSBkbyBub3QgdXNlIGFub3RoZXIgTW9QLiAgVGhh dCBpcyBhIHZlcnkgZWFzeSBjaGFuZ2UgdG8gbWFrZS4gIEkgd2lsbCBhd2FpdCB0byBzZWUgaWYg b3RoZXJzIGFncmVlLg0KW1JlbXldIEl0IHNob3VsZCBiZSBpbmRpY2F0ZWQgdGhhdCBSRkM2OTk3 IFAyUC1SUEwgaGFzIGEgbmV3IE1vUCBiZXNpZGVzIHRoZSBmb3VyIE1vUHMgaW4gY29yZSBSUEws IGJlY2F1c2Ugbm9uZSBvZiB0aGVtIGNhbiBmdWxmaWwgdGhlIHJlcXVpcmVtZW50cyBvZiBQMlAg cm91dGUgZGlzY292ZXJ5LiBJdCBpcyB0aGUgc2FtZSBjYXNlIGZvciBBT0RWLVJQTC4gQnV0IG1h eWJlIGl0IGlzIGEgc29sdXRpb24gdG8gbGV0IEFPRFYtUlBMIHNoYXJlIHRoZSBzYW1lIE1vUCB3 aXRoIFAyUC1SUEwsIGFuZCB3ZSBjYW4gZGlzdGluZ3Vpc2ggdGhlc2UgdHdvIGJ5IGlkZW50aWZ5 aW5nIHRoZSB0eXBlIG9mIHRoZSBvcHRpb25zLiBIb3dldmVyLCBpdCBpcyBub3QgYXMgY29udmVu aWVudCBhcyBpZGVudGlmeWluZyB0aGVtIGRpcmVjdGx5IGJ5IHRoZSBNb1AuDQoNCklNSE8sIHRo ZSBNZXNzYWdlIGZvcm1hdCBvZiBkaW8gaXMgbm90IGNvcnJlY3QgbmVlZHMgdG8gaGF2ZSB0eXBl IHRoZW4gdGhlIGxlbmd0aCBmb3JtYXQgYXMgc2hvd24gaW4gdGhlIGRpbyBmb3JtYXQgc3BlY2lm aWNhdGlvbiByZmM2NTUwLg0KDQpMb29raW5nIGF0IEZpZ3VyZSAxNCBpbiBSRkMgNjU1MCwgSSBk byBub3Qgc2VlIGEgbGVuZ3RoIGZpZWxkLiAgIFRoZSBESU8gc2hvd24gaW4gRmlndXJlIDEgb2Yg dGhlIEFPRFYtUlBMIGRyYWZ0IHN0cm9uZ2x5IHJlc2VtYmxlcyBGaWd1cmUgMTUgb2YgUkZDIDY1 NTAuICAgRGlkIHlvdSBoYXZlIHNvbWV0aGluZyBlbHNlIGluIG1pbmQgYWJvdXQgdGhpcz8NCltS ZW15XSBJbmRlZWQsIGZvciB0aGUgb3B0aW9ucyBpbiBESU8gbWVzc2FnZSwgYSBsZW5ndGggZmll bGQgc2hvdWxkIGJlIGluY2x1ZGVkLg0KDQoNCg0KSU1PLCB0aGlzIHByb3RvY29sIFNlcXVlbmNl IG51bWJlciBpcyBub3QgZGlmZmVyZW50IHRoYW4gdGhlIHNlcXVlbmNlIG51bWJlciBvZiBkZXN0 aW5hdGlvbiBtZW50aW9uZWQgaW4gUkZDNjU1MC4gWW91IG11c3QgaW5jbHVkZSB0aGUgRFRTTiBp biB0aGlzIGRyYWZ0LiBJZiB5b3UgdGhpbmtzIEkgYW0gd3JvbmcgcGxlYXNlIG1lbnRpb24gd2h5 IGhlcmUgYW5kIHRoZW4gaXQgc2hvdWxkIGJlIGNsZWFyIHdoYXQgaXMgdGhlIGRpZmZlcmVudCB0 aGFuIFJQTCBpbiB0aGUgZHJhZnQ/DQoNCkkgd2lsbCBnZXQgYmFjayB0byB5b3Ugb24gdGhpcyBw b2ludC4NCltSZW15XSBUaGUgRFRTTiBpcyB1c2VkIHRvIHRyaWdnZXIgREFPIHRyYW5zbWlzc2lv biwgYW5kIGl0IGlzIG5vdCBhIHNlcXVlbmNlIG51bWJlciBmb3IgYSByb3V0ZS4gVGhlIGFjdHVh bCBzZXF1ZW5jZSBudW1iZXIgZm9yIGEgcm91dGUgaXMgaW4gdGhlIFRyYW5zaXQgSW5mb3JtYXRp b24gb3B0aW9uIHdoaWNoIGlzIGluY2x1ZGVkIGluIGEgREFPLiBTaW5jZSB0aGVyZSBpcyBubyBE QU8gaW4gQU9EVi1SUEwsIHRoZSBEVFNOIHNob3VsZCBiZSBzZXQgdG8gMCBhbmQgaWdub3JlZCwg d2hpY2ggaXMgYWxzbyB0aGUgc2V0dGluZ3MgaW4gUkZDNjk5Ny4gVGhlIHR3byBzZXF1ZW5jZSBu dW1iZXJzIGluIEFPRFYtUlBMIGluaGVyaXQgQU9EVi4NCg0KDQoNClNlY3VyaXR5IHNlY3Rpb24g bmVlZHMgdG8gaW5jbHVkZSByZmM2NTUyL3JmYzY1NTMNCg0KUkZDIDY1NTIgaXMgYWJvdXQgdGhl IE9iamVjdGl2ZSBGdW5jdGlvbiBaZXJvLCB3aGljaCBpc24ndCBkaXJlY3RseSByZWxhdGVkIHRv IHNlY3VyaXR5LiAgUkZDIDY1NTMgaXMgYWJvdXQgcHV0dGluZyBSUEwgY29udHJvbCBpbmZvcm1h dGlvbiBpbiBEYXRhLVBsYW5lIHBhY2tldHMsIHdoaWNoIHdlIGRvIG5vdCB1c2UgZm9yIEFPRFYt UlBMLiAgSG93ZXZlciB0aGF0IGlzIGFuIGludGVyZXN0aW5nIGlkZWEgd29ydGggZGlzY3Vzc2lv biwgYWxiZWl0IG5vdCBuZWNlc3NhcmlseSBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbi4gIEkgd291 bGQgYmUgdmVyeSBjdXJpb3VzIHRvIGZpbmQgb3V0IGlmIFJGQyA2NTUzIGhhcyBhdHRyYWN0ZWQg bXVjaCBpbXBsZW1lbnRhdGlvbi4NCg0KDQoNCg0KSSBzdWdnZXN0IHRvIGRlbGV0ZSBmdXR1cmUg d29yayBzZWN0aW9uLg0KDQpJdCdzIG5vdCBub3JtYXRpdmUsIGFuZCBmYWlybHkgcmVmbGVjdHMg c29tZSB1c2VmdWwgZGlzY3Vzc2lvbiB0aGF0IHdlIGhhdmUgaGFkLiAgRG8geW91IHRoaW5rIGl0 IGlzIGNvbmZ1c2luZyBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Pw0KDQpSZWdhcmRzLA0K Q2hhcmxpZSBQLg0K --_000_BB09947B5326FE42BA3918FA28765C2EDD3B08DGGEMM506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9y OmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyBBYmR1c3NhbGFtIGFuZCBDaGFybGllLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGZpbmQgbXkg Y29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5DaGFybGllIFBlcmtpbnM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkg MjcsIDIwMTggNjowNCBBTTxicj4NCjxiPlRvOjwvYj4gQWJkdXNzYWxhbSBCYXJ5dW4gJmx0O2Fi ZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tJmd0Ozsgcm9sbCAmbHQ7cm9sbEBpZXRmLm9yZyZndDs7 IGRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1JvbGxdIENvbW1lbnRzIGZvciBBT0RWLVJQTCBwcm90b2NvbCBbSXNzdWUgIzE4NF08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5IZWxsbyBBYmR1c3NhbGFtLDxvOnA+PC9vOnA+PC9w Pg0KPHA+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4mbmJzcDsgUGxl YXNlIGZpbmQgc29tZSBmb2xsb3ctdXAgY29tbWVudHMgYmVsb3cuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAxLzUvMjAxOCAxMjowNCBQTSwgQWJkdXNzYWxhbSBCYXJ5dW4gd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBXRyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEw LjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllciI+VGhlIGFic3RyYWN0IG5lZWRzIHRvIGRlbGV0ZSBhbnkgaW5kaWNh dGlvbiB0aGF0IHRoaXMgaXMgYSByb3V0aW5nIHByb3RvY29sLiBJTUhPLCB0aGlzIGlzIGEgcm91 dGUgZGlzY292ZXJ5IGZvciB0aGUgUlBMIHByb3RvY29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpUbyBtZSBBT0RWLVJQTCBpcyBhIHZhcmlhdGlvbiBvbiBSUEwuJm5ic3A7IEJ1dCBJIGFtIGN1 cmlvdXMgdG8ga25vdyBtb3JlIGFib3V0IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcm91dGlu ZyBwcm90b2NvbCBhbmQgYSByb3V0ZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgdXNlcyByb3V0 aW5nIHByb3RvY29sIGNvbnRyb2wgbWVzc2FnZXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEwLjBwdDttYXJnaW4tbGVmdDow Y20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+ VGhlIGRpc2NvdmVyeSBvZiByb3V0ZSBpcyBwYXJ0IG9mIHRoZSByb3V0aW5nIHByb3RvY29sIHNv IHdlIGhhdmUgYSBkaWZmZXJlbnQgcm91dGluZyB3aGljaCBpcyBBT0RWLVJQTCByb3V0aW5nIHBy b3RvY29sLiBUaGUgZHJhZnQgbmVlZHMgdG8gbWVudGlvbiBpZiB0aGlzIEFPRFYtUlBMIGNhbiB3 b3JrIHdpdGggUlBMIG9yIG5vdCBpbiB0aGUgc2FtZSBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpZZXMsIEFPRFYtUlBMIHNob3VsZCBpbnRlcm9wZXJhdGUgcXVpdGUgd2VsbCB3aXRo IFJQTCBpbiB0aGUgc2FtZSBuZXR3b3JrLiZuYnNwOyBJZiB0aGVyZSBpcyBzb21lIGNhc2UgdGhh dCBwcmVzZW50cyBkaWZmaWN1bHR5IHBsZWFzZSBsZXQgdXMga25vdyBhbmQgd2Ugd2lsbCBhbmFs eXplIGl0IGZ1cnRoZXIuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltSZW15XSBT aW5jZSBBT0RWLVJQTCBkZWZpbmVzIG5ldyBSUEwgY29udHJvbCBtZXNzYWdlIG9wdGlvbiBpbiB0 aGUgZnJhbWV3b3JrIG9mIGNvcmUgUlBMLiBUaGUgdHdvIHByb3RvY29scyBzaG91bGQgd29yayB3 ZWxsIGluIHRoZSBzYW1lIG5ldHdvcmsuPC9zcGFuPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPklNTywgdGhlIGRy YWZ0IG5lZWRzIHRvIGRlc2NyaWJlIHRoZSBuZWlnaGJvciBkaXNjb3ZlcnkgY29tYmluZWQgd2l0 aCBBT0RWLVJQTCByb3V0ZSBkaXNjb3ZlcnkuIEFsc28gbmVlZHMgdG8gcmVmZXIgdG8gc2VjdGlv bnMgMTguNC4xIGFuZCAxOC42IGluIHJmYzY1NTAuIE9yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2VyaWYiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ij50aGUNCiBkcmFmdCBzaG93cyB0aGUgZGlmZmVyZW5jZSBmcm9tIFJGQzY2NTAgZGlzY292ZXJ5 LiBQbGVhc2UgcmVmZXIgdG8gc2VjdGlvbnMgaW4gUkZDNjU1MCBSUEwuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCkkgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCB0byBtYWtlIG9mIHRoaXMsIHVudGls IGFmdGVyIEkgY2FuIGJldHRlciB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBy b3V0aW5nIHByb3RvY29sIGFuZCBhIHJvdXRlIGRpc2NvdmVyeSBtZWNoYW5pc20gdGhhdCB1c2Vz IHJvdXRpbmcgcHJvdG9jb2wgY29udHJvbCBtZXNzYWdlcy48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjBj bSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1i cmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTAu MHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyIj5BT0RWLVJQTCBpbnN0YW5jZSBhcmUgYW5vdGhlciB0eXBlIG9mIFJQ TC1JbnN0YW5jZXMsIHNvIHdoeSB5b3Ugd3JpdGUgdGhlIEFPRFYgaW5zdGFuY2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPlBsZWFzZSBub3RlIHRoYXQgdGhp cyB3aWxsIGNvbmZsaWN0IHdpdGggTUFORVQgcm91dGluZyBpbnN0YW5jZXMuIFBsZWFzZSBkZWxl dGUgQU9EViBpbnN0YW5jZS4gVGhpcyBkcmFmdCBuZWVkcyB0byBoYXZlIG9ubHkgUlBMIGluc3Rh bmNlcyBvciB0aGlzIEFPRFYtUlBMIGluc3RhbmNlIGRlZmluZWQgYXMgUlBMIGluc3RhbmNlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIGxvb2tlZCBmb3IgdGhlIHN0cmluZ3MgJnF1b3Q7QU9E ViBpbnN0YW5jZSZxdW90OyBhbmQgJnF1b3Q7QU9EVi1SUEwgaW5zdGFuY2UmcXVvdDsgYnV0IGRp ZCBub3QgZmluZC4mbmJzcDsgQ291bGQgeW91IHBvaW50IHRvIHRoZSBwYXJ0aWN1bGFyIG9jY3Vy cmVuY2Ugc28gdGhhdCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBjb25mbGljdD88c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltSZW15XSBJbiB0aGUgdmVyc2lvbiB0aGF0 IHdlIGFyZSBnb2luZyB0byBzdWJtaXQsIHdlIHdpbGwgY2xlYXJseSBzYXkgaW4gdGhlIHRlcm1p bm9sb2d5IHRoYXQgQU9EVi1SUEwgaW5zdGFuY2UgKFJSRVEtSW5zdGFuY2UgYW5kIFJSRVAtSW5z dGFuY2UpIGFyZSBSUEwgaW5zdGFuY2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjEwLjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q291cmllciI+RGVsZXRlIHRoZSB3cml0aW5nIHdvcmRzICdBT0RWIHJvdXRp bmcnIGZyb20gdGhlIGRyYWZ0LCBhbmQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmRlbGV0ZSBB T0RWIHJlZmVyZW5jZQ0KIGFzIHRoZSBJUHY0LVJGQyBtZW50aW9uZWQgKGNhbiBiZSBjb25mdXNp bmcpLiBUaGUgQU9EViBpcyBhbHJlYWR5IHdlbGwga25vd24uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NClRoYW5rcyBmb3IgYWNrbm93bGVkZ2luZyB0aGUgd29yayBvbiBBT0RWLiZuYnNwOyBJIGFt IGhvcGluZyBBT0RWdjIgY29tcGxldGVzIExhc3QgQ2FsbCBzb29uLiZuYnNwOyBIb3dldmVyLCBJ IHNlYXJjaGVkIGZvciAmcXVvdDtBT0RWIHJvdXRpbmcmcXVvdDsgYnV0IGRpZCBub3QgZmluZC4m bmJzcDsgQ291bGQgeW91IHBvaW50IHRvIHRoZSBwYXJ0aWN1bGFyIG9jY3VycmVuY2Ugc28gdGhh dCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBjb25mdXNpb24/PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEwLjBwdDttYXJnaW4tbGVm dDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll ciI+SU1PIHRoZSBvcGVyYXRpb24gbW9kZSBpcyBub3QgdXNlZCBjb3JyZWN0bHksIHdlIG5lZWQg dG8gaWRlbnRpZnkgdGhlIHByb3RvY29sPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5ub3QNCiBi eSB0aGUgTW9QLCB3ZSB3aWxsIHVzZSB0aGVtIGFsbCB0aGVuLCBpdCBzaG91bGQgYmUgcmVzZXJ2 ZWQgZm9yIG5ldHdvcmsgb3BlcmF0aW9ucyBub3QgZm9yIHByb3RvY29scy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KSSBhbSBPLksuIHdpdGggcmVjYXN0aW5nIHRoZSBuZXcgbWVzc2FnZXMgc28g dGhhdCB0aGV5IGRvIG5vdCB1c2UgYW5vdGhlciBNb1AuJm5ic3A7IFRoYXQgaXMgYSB2ZXJ5IGVh c3kgY2hhbmdlIHRvIG1ha2UuJm5ic3A7IEkgd2lsbCBhd2FpdCB0byBzZWUgaWYgb3RoZXJzIGFn cmVlLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUmVteV0gSXQgc2hvdWxkIGJl IGluZGljYXRlZCB0aGF0IFJGQzY5OTcgUDJQLVJQTCBoYXMgYSBuZXcgTW9QIGJlc2lkZXMgdGhl IGZvdXIgTW9QcyBpbiBjb3JlIFJQTCwgYmVjYXVzZSBub25lIG9mIHRoZW0gY2FuIGZ1bGZpbCB0 aGUgcmVxdWlyZW1lbnRzIG9mIFAyUCByb3V0ZSBkaXNjb3ZlcnkuIEl0IGlzIHRoZSBzYW1lIGNh c2UgZm9yIEFPRFYtUlBMLiBCdXQgbWF5YmUgaXQgaXMgYSBzb2x1dGlvbg0KIHRvIGxldCBBT0RW LVJQTCBzaGFyZSB0aGUgc2FtZSBNb1Agd2l0aCBQMlAtUlBMLCBhbmQgd2UgY2FuIGRpc3Rpbmd1 aXNoIHRoZXNlIHR3byBieSBpZGVudGlmeWluZyB0aGUgdHlwZSBvZiB0aGUgb3B0aW9ucy4gSG93 ZXZlciwgaXQgaXMgbm90IGFzIGNvbnZlbmllbnQgYXMgaWRlbnRpZnlpbmcgdGhlbSBkaXJlY3Rs eSBieSB0aGUgTW9QLg0KPC9zcGFuPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPklNSE8sIHRoZSBNZXNzYWdlIGZvcm1hdCBvZiBkaW8g aXMgbm90IGNvcnJlY3QgbmVlZHMgdG8gaGF2ZSB0eXBlIHRoZW4gdGhlIGxlbmd0aCBmb3JtYXQg YXMgc2hvd24gaW4gdGhlIGRpbyBmb3JtYXQgc3BlY2lmaWNhdGlvbiByZmM2NTUwLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQpMb29raW5nIGF0IEZpZ3VyZSAxNCBpbiBSRkMgNjU1MCwgSSBkbyBu b3Qgc2VlIGEgbGVuZ3RoIGZpZWxkLiZuYnNwOyZuYnNwOyBUaGUgRElPIHNob3duIGluIEZpZ3Vy ZSAxIG9mIHRoZSBBT0RWLVJQTCBkcmFmdCBzdHJvbmdseSByZXNlbWJsZXMgRmlndXJlIDE1IG9m IFJGQyA2NTUwLiZuYnNwOyZuYnNwOyBEaWQgeW91IGhhdmUgc29tZXRoaW5nIGVsc2UgaW4gbWlu ZCBhYm91dCB0aGlzPzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUmVteV0gSW5k ZWVkLCBmb3IgdGhlIG9wdGlvbnMgaW4gRElPIG1lc3NhZ2UsIGEgbGVuZ3RoIGZpZWxkIHNob3Vs ZCBiZSBpbmNsdWRlZC4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj48YnI+DQpJTU8sIHRo aXMgcHJvdG9jb2wgU2VxdWVuY2UgbnVtYmVyIGlzIG5vdCBkaWZmZXJlbnQgdGhhbiB0aGUgc2Vx dWVuY2UgbnVtYmVyIG9mIGRlc3RpbmF0aW9uIG1lbnRpb25lZCBpbiBSRkM2NTUwLiBZb3UgbXVz dCBpbmNsdWRlIHRoZSBEVFNOIGluIHRoaXMgZHJhZnQuIElmIHlvdSB0aGlua3MgSSBhbSB3cm9u ZyBwbGVhc2UgbWVudGlvbiB3aHkgaGVyZSBhbmQgdGhlbiBpdCBzaG91bGQgYmUgY2xlYXIgd2hh dCBpcyB0aGUgZGlmZmVyZW50IHRoYW4NCiBSUEw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmlu IHRoZSBkcmFmdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB3aWxsIGdldCBiYWNrIHRvIHlv dSBvbiB0aGlzIHBvaW50Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUmVteV0g VGhlIERUU04gaXMgdXNlZCB0byB0cmlnZ2VyIERBTyB0cmFuc21pc3Npb24sIGFuZCBpdCBpcyBu b3QgYSBzZXF1ZW5jZSBudW1iZXIgZm9yIGEgcm91dGUuIFRoZSBhY3R1YWwgc2VxdWVuY2UgbnVt YmVyIGZvciBhIHJvdXRlIGlzIGluIHRoZSBUcmFuc2l0IEluZm9ybWF0aW9uIG9wdGlvbiB3aGlj aCBpcyBpbmNsdWRlZCBpbiBhIERBTy4gU2luY2UgdGhlcmUgaXMgbm8gREFPIGluIEFPRFYtUlBM LA0KIHRoZSBEVFNOIHNob3VsZCBiZSBzZXQgdG8gMCBhbmQgaWdub3JlZCwgd2hpY2ggaXMgYWxz byB0aGUgc2V0dGluZ3MgaW4gUkZDNjk5Ny4gVGhlIHR3byBzZXF1ZW5jZSBudW1iZXJzIGluIEFP RFYtUlBMIGluaGVyaXQgQU9EVi4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5TZWN1cml0 eSBzZWN0aW9uIG5lZWRzIHRvIGluY2x1ZGUgcmZjNjU1Mi9yZmM2NTUzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NClJGQyA2NTUyIGlzIGFib3V0IHRoZSBPYmplY3RpdmUgRnVuY3Rpb24gWmVybywg d2hpY2ggaXNuJ3QgZGlyZWN0bHkgcmVsYXRlZCB0byBzZWN1cml0eS4mbmJzcDsgUkZDIDY1NTMg aXMgYWJvdXQgcHV0dGluZyBSUEwgY29udHJvbCBpbmZvcm1hdGlvbiBpbiBEYXRhLVBsYW5lIHBh Y2tldHMsIHdoaWNoIHdlIGRvIG5vdCB1c2UgZm9yIEFPRFYtUlBMLiZuYnNwOyBIb3dldmVyIHRo YXQgaXMgYW4gaW50ZXJlc3RpbmcgaWRlYSB3b3J0aCBkaXNjdXNzaW9uLCBhbGJlaXQNCiBub3Qg bmVjZXNzYXJpbHkgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24uJm5ic3A7IEkgd291bGQgYmUgdmVy eSBjdXJpb3VzIHRvIGZpbmQgb3V0IGlmIFJGQyA2NTUzIGhhcyBhdHRyYWN0ZWQgbXVjaCBpbXBs ZW1lbnRhdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5JIHN1Z2dlc3QgdG8gZGVsZXRl IGZ1dHVyZSB3b3JrIHNlY3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KSXQncyBub3Qgbm9ybWF0aXZlLCBhbmQgZmFpcmx5IHJlZmxlY3Rz IHNvbWUgdXNlZnVsIGRpc2N1c3Npb24gdGhhdCB3ZSBoYXZlIGhhZC4mbmJzcDsgRG8geW91IHRo aW5rIGl0IGlzIGNvbmZ1c2luZyBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Pzxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB09947B5326FE42BA3918FA28765C2EDD3B08DGGEMM506MBSchina_--