From nobody Mon Jul 3 07:18:21 2017 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 DFBF413153C; Mon, 3 Jul 2017 07:18:19 -0700 (PDT) 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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909149986.22726.8293534829769219410@ietfa.amsl.com> Date: Mon, 03 Jul 2017 07:18:19 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-16.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: Mon, 03 Jul 2017 14:18:20 -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 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-16.txt Pages : 48 Date : 2017-07-03 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. Additionally, this document updates the RFC 6553 adding a change to the RPL Option Type and the RFC 6550 to indicate about this change. 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-16 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 Tue Jul 4 07:25:09 2017 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 F171013192B for ; Tue, 4 Jul 2017 07:25:06 -0700 (PDT) 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 Y4wP_fiMeAsw for ; Tue, 4 Jul 2017 07:25:05 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 9AF2E12EA74 for ; Tue, 4 Jul 2017 07:25:04 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id r36so72374501ioi.1 for ; Tue, 04 Jul 2017 07:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2qUxVUpu96CpZOwAKrQESgCNE8Uq4t/Oi7gZuKyB1O4=; b=IlWJGz73yKABQnI51/rJ7ZNlYYwZJH5wT4xAsBd1rJAqnHrpoa0IXPIPeQnlLVgfAA RDB1HnOM8itxNWfaZjvkrmlIwyiM4hvZUZGCS+VLSG76KH+mXCDlLyQ1N6PFtgEhd8Qw 8BE6a+Y/sGyrbSGei/hv+hft4QxdultuDlWAnKlJqsbyetr7ZrYcYRVqo5ZOyiJ/UygR 3yeoa03CYDgqW/bHkK+2o37zTKE49dk2eFIyDwC6zJKX3gIWH2sBln90i4l0zLJE/FaA PPxn9d2qc3dePNF1EV9bW7EvOe9iKHjSv+qcr8ul0HA+8ZvKk5vOGG10wjZmB17GpiNM ynsQ== 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=2qUxVUpu96CpZOwAKrQESgCNE8Uq4t/Oi7gZuKyB1O4=; b=gPBN8VlEGkD8LS5Kj9x3cBEZQa5vsJpoWmuDNv4341QZ2H6Zyliicppwxw32k58M9+ WuR87PMAxvWKQAWI+D0r70BtusUlQrOD0j+4hdWgor+ADupnMFYayrqdnIsNC+74RHLP 0l9O9o1SAIz/mHoDaX59BUJ40BkP1z+P+B8lxtIoTb0gem8XgcQ66w2LO4WPpoYpGW0c PujXdNXtM5XuVAy3nTUhYdhW0aX77TqdKk9Z1Hf1533m/M5+ldFUXKGUb9Gg5Kv94qDN b7ZcfA1OsbmdsnSOrsuhA8IbjbXe3VNNy0RwWYRxFC9x5TIsrCmdIthBwPiXUj1bZBrg PXVQ== X-Gm-Message-State: AKS2vOxFieYET28Ykrwe1Kbv5xfHyP+90N81XlQXCAwT/GfUVGnhuFNb xMUX6fgA5FV4KNeiayceazaY+6ice/64 X-Received: by 10.107.10.168 with SMTP id 40mr40117671iok.210.1499178303803; Tue, 04 Jul 2017 07:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 4 Jul 2017 07:25:03 -0700 (PDT) From: Ines Robles Date: Tue, 4 Jul 2017 17:25:03 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="001a113f96fe40d5fc05537ea6ee" Archived-At: Subject: [Roll] Agenda IETF 99 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, 04 Jul 2017 14:25:07 -0000 --001a113f96fe40d5fc05537ea6ee Content-Type: text/plain; charset="UTF-8" Dear all, Please find the agenda for IETF 99, https://www.ietf.org/proceedings/99/agenda/agenda-99-roll-00 Comments are welcome, Thanks, Ines + Peter --001a113f96fe40d5fc05537ea6ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the agenda for IE= TF 99,


Comments are welcome,

Thanks,

Ines + Peter
--001a113f96fe40d5fc05537ea6ee-- From nobody Wed Jul 12 05:23:38 2017 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 CCA4B131690 for ; Wed, 12 Jul 2017 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itron.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 5cYFyQDlx8M6 for ; Wed, 12 Jul 2017 05:23:34 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0078.outbound.protection.outlook.com [104.47.37.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98EA12EC30 for ; Wed, 12 Jul 2017 05:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itron.onmicrosoft.com; s=selector1-itron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hI9+Ukhh9RXBVSW7aVSIO9t4FoPS28NN0r7Re1pV+64=; b=WNeIIvXT51PwKiX0GqI0oR4fq+1A/OHzYuFXW/V5Z6wtLKy5nPB4Hu91iTiPG843ovKoFCYblayi/aMnUC5EQSaRrvTKvUk+xsCVZeAw/tkLgQEmfSQK4BnrICt+E3U0oX4evpZMtZagbAnd3c4dAPTTk4ZB19VMau7ClAYz2LY= Received: from BY1PR0401MB1174.namprd04.prod.outlook.com (10.160.194.148) by BY1PR0401MB1174.namprd04.prod.outlook.com (10.160.194.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Wed, 12 Jul 2017 12:23:32 +0000 Received: from BY1PR0401MB1174.namprd04.prod.outlook.com ([10.160.194.148]) by BY1PR0401MB1174.namprd04.prod.outlook.com ([10.160.194.148]) with mapi id 15.01.1199.019; Wed, 12 Jul 2017 12:23:32 +0000 From: "Gillmore, Matthew" To: "roll@ietf.org" Thread-Topic: Route Projection draft Thread-Index: AdL7B2wV0zEYr1bgRN23677AOjvAeA== Date: Wed, 12 Jul 2017 12:23:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=itron.com; x-originating-ip: [217.243.173.245] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY1PR0401MB1174; 7:A1YMaOUUI2HZZ6XNqMLVQxQdAUG1PMiYVu9upg80Gg3Dug1Zn754j6smCeD1uEk+ZTCgNiBhktaIMYFLUwzZHnVvZbrS/k7P9mFFVJLGTeg2Q8fhnhIHYfq4wYuZzyGIEe6VH5mgGz1rB0TAWosXZmt2sf3ZUTa2vifr4/IrLhkghB3yiV7sJNPy8HhquOnjQPHalh3RQ+gLviySQ8QU8Htyerb+qwjNYwv13aCqw9xldYdNkRsXXP/Kk4CxVB6UglNghl1jJNsP3rp+se6wK5iVQyMzfL6QezoD6EgeQhI14E69cFGG5a77r9B3VuEhwWIQJmWpd9NZ7tyOMyOmDiaNBFKAXEiPg3s7igeaq/0wM/P2imPGejR52DlSQcgolnoecB6c1/nrAQQ+daEqTff6bQNI+TRAo6IRjuSf5lpZP4TYmI16HiweYfjDPtK+8AukfIRpS8O4KJtbNDMitd7oWA3BJassLTwsCJK56ipvlcMImRrmtxE1ng6HQOtY7ZMcJCyG1cxalCYslQb/nlqmBbuQTfwKIp8dN3zKN4rmaP+lgSsm2HH1gB+b3oHNrADHW44610bcBtLXU6aGTJdednBZiDWJGNM0xkwsBEETvRN1ZPDK9SUO38HwZ00/BCe0pm6B35coYRLkfBvXlsiiIh7FWXG8WMwthUd0H6ixVvV15kAywdEf/aE9OjvTqSdvs8eFpG0ttnHfIKriKU2LvwKENK7OJp6h96nBcXh+lQ2e2RMELrA5UNAf3oCx7ms43olozh0Wzw3GgMNrv48hke1yv0hPXoftWpmhdMM= x-ms-office365-filtering-correlation-id: 0f2f14e4-3633-4218-4dde-08d4c920cfbe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0401MB1174; x-ms-traffictypediagnostic: BY1PR0401MB1174: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0401MB1174; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0401MB1174; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39410400002)(39840400002)(39850400002)(39400400002)(39860400002)(3846002)(8936002)(33656002)(54896002)(7116003)(790700001)(7696004)(55016002)(3480700004)(66066001)(2501003)(5630700001)(6306002)(25786009)(2351001)(54356999)(72206003)(6506006)(99286003)(2900100001)(110136004)(38730400002)(6116002)(6916009)(7736002)(966005)(53936002)(6436002)(9326002)(8676002)(5640700003)(50986999)(74316002)(236005)(5660300001)(3660700001)(478600001)(102836003)(3280700002)(86362001)(14454004)(81166006)(189998001)(1730700003)(9686003)(77096006)(606006)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0401MB1174; H:BY1PR0401MB1174.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR0401MB117400933DD23DA563AC8C3A98AF0BY1PR0401MB1174_" MIME-Version: 1.0 X-OriginatorOrg: itron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 12:23:32.6011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5818bd20-bf25-47b1-b996-d419d7e6e8ba X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0401MB1174 Archived-At: Subject: [Roll] Route Projection draft 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, 12 Jul 2017 12:23:36 -0000 --_000_BY1PR0401MB117400933DD23DA563AC8C3A98AF0BY1PR0401MB1174_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, My company (Itron) has implemented most of what has been described in https= ://tools.ietf.org/html/draft-ietf-roll-dao-projection-01. We find this dra= ft very useful and if possible we would like to make suggestions/improvemen= ts. 1) We would like the ability to check what P-DAO routes have been sent= to a router a. This could be done with a P-DAO acknowledgement 2) What is meant by a "No-Path" when a path lifetime is 00? 3) Could a device NACK a P-DAO? Thanks! --_000_BY1PR0401MB117400933DD23DA563AC8C3A98AF0BY1PR0401MB1174_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

My company (Itron) has implemented most of what has = been described in h= ttps://tools.ietf.org/html/draft-ietf-roll-dao-projection-01.  We = find this draft very useful and if possible we would like to make suggestio= ns/improvements.

 

1)      We would like the ability to check what P-DAO route= s have been sent to a router

a.       This could be done with a P-DAO acknowledgement

2)      What is meant by a “No-Path” when a pat= h lifetime is 00?

3)      Could a device NACK a P-DAO?

 

Thanks!

 

--_000_BY1PR0401MB117400933DD23DA563AC8C3A98AF0BY1PR0401MB1174_-- From nobody Thu Jul 13 11:22:29 2017 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 280DC1316E3 for ; Thu, 13 Jul 2017 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 ofz3PJOv6_vy for ; Thu, 13 Jul 2017 11:22:26 -0700 (PDT) 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 F2698131549 for ; Thu, 13 Jul 2017 11:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10617; q=dns/txt; s=iport; t=1499970145; x=1501179745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X5/rbOBwOuRsw5Q5FmIGW6zqXY33aw5AgeyyjX1t4gs=; b=TBg4Xck0PRT9J7rvnzOppvn1vAqmq/HQ2vHzWs0fdTe1ncHauF4Od87X kKPd/O2mIa22qc+zXB7WDzQMw43rOkIsY12T6SqI27tpXfEuikUDQ5UuK m62HB+xhBQgeHScVvtSRSbB6qvoQOtJKzBDL5+zb+WuDUz2tXWA2GbBta o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAABAuWdZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44CkXaQV4UsghEshUoCg2k/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAy1MEAIBCBEEAQEoBzIUCQgBAQQOBQiJQ2QQsSuLJAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyiDTYFgAYMkhRAQhT4Fl0CHcAKHSIxBghWFTIpRlVQBHzi?= =?us-ascii?q?BCnUVh192iACBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,355,1496102400"; d="scan'208,217";a="259267765" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2017 18:22:24 +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 v6DIMOf6003385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jul 2017 18:22:24 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.1210.3; Thu, 13 Jul 2017 13:22:23 -0500 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.1210.000; Thu, 13 Jul 2017 13:22:23 -0500 From: "Pascal Thubert (pthubert)" To: "Gillmore, Matthew" CC: Routing Over Low power and Lossy networks Thread-Topic: Route Projection draft Thread-Index: AdL7B2wV0zEYr1bgRN23677AOjvAeAA6r62A Date: Thu, 13 Jul 2017 18:22:02 +0000 Deferred-Delivery: Thu, 13 Jul 2017 17:58:24 +0000 Message-ID: <2b6352aa1d3743adb571aa1bd23135db@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.56.235.254] Content-Type: multipart/alternative; boundary="_000_2b6352aa1d3743adb571aa1bd23135dbXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Route Projection draft 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, 13 Jul 2017 18:22:28 -0000 --_000_2b6352aa1d3743adb571aa1bd23135dbXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Matt : Many good points, please see below: From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Gillmore, Matthew Sent: mercredi 12 juillet 2017 14:24 To: roll@ietf.org Subject: [Roll] Route Projection draft Hi Pascal, My company (Itron) has implemented most of what has been described in https= ://tools.ietf.org/html/draft-ietf-roll-dao-projection-01. We find this dra= ft very useful and if possible we would like to make suggestions/improvemen= ts. 1) We would like the ability to check what P-DAO routes have been sent= to a router a. This could be done with a P-DAO acknowledgement [Pascal] The DAO-ACK guarantees that the devices on the way have processed = the DAO. Now there is no way in the current draft to go to a particular dev= ice and ask it what routes is has currently installed, and / or how many mo= re rotes it can accept based on available resources. Would that be needed? = Would you contribute? 2) What is meant by a "No-Path" when a path lifetime is 00? [Pascal] This terminology is inherited from RFC 6550. It really means that = the DAO flow cleans up a state as opposed to adding one. The way to signal = that is that the route lifetime is set to 0. 3) Could a device NACK a P-DAO? [Pascal] Yes, any device on the way can respond with a DAO-Ack as opposed t= o forward to the next node, indicating a problem in a status > 127. Then ag= ain we have to design the gory details and your help in edition and or with= return from implementation would be highly welcome... Take care, Pascal Thanks! --_000_2b6352aa1d3743adb571aa1bd23135dbXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Matt :=

 

Many good points, plea= se see below:

 

From: Roll [mail= to:roll-bounces@ietf.org] On Behalf Of Gillmore, Matthew
Sent: mercredi 12 juillet 2017 14:24
To: roll@ietf.org
Subject: [Roll] Route Projection draft

 

Hi Pascal,

 

My company (Itron) has = implemented most of what has been described in h= ttps://tools.ietf.org/html/draft-ietf-roll-dao-projection-01.  We = find this draft very useful and if possible we would like to make suggestio= ns/improvements.

 

1)      We would like the ability to check what P-DAO route= s have been sent to a router

a.      This could be done with a P-DAO acknowledgement

 

[Pascal] = The DAO-ACK guarantees that the devic= es on the way have processed the DAO. Now there is no way in the current dr= aft to go to a particular device and ask it what routes is has currently installed, and / or how many more rotes it= can accept based on available resources. Would that be needed? Would you c= ontribute?

 

2)      What is meant by a “No-Path” when a pat= h lifetime is 00?

[Pascal] = This terminology is inherited from RF= C 6550. It really means that the DAO flow cleans up a state as opposed to a= dding one. The way to signal that is that the route lifetime is set to 0.

 

3)      Could a device NACK a P-DAO?

[Pascal] = Yes, any device on the way can respon= d with a DAO-Ack as opposed to forward to the next node, indicating a probl= em in a status > 127. Then again we have to design the gory details and your help in edition and or with return fro= m implementation would be highly welcome…

 

Take care,<= /span>

 

Pascal

 

Thanks!

 

--_000_2b6352aa1d3743adb571aa1bd23135dbXCHRCD001ciscocom_-- From nobody Thu Jul 13 17:48:51 2017 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 AAE901242F5; Thu, 13 Jul 2017 17:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 sO3a6oJPUvKf; Thu, 13 Jul 2017 17:48:35 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 67136128BC8; Thu, 13 Jul 2017 17:48:32 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id j53so43742891uaa.2; Thu, 13 Jul 2017 17:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=fBXmvcw4Nxl8SCjXJeRABWlDR4tPOO5oaj1LyTSI8mM=; b=mdmfMGoBnrQSpFTdlp8xbtZ5zV5SsvCPYRRJEETwIMdIjboagr79bJUcS+UDOTPNxJ bKaiCFUrrl02yddZ4/mvVcgpezpNHUTTXd+JNCucSLKV68FsEgW7yEWnabCHVPTSIB6D ul30bR6fMmq4GwG5K5YWxbuwv3oAbFwu6HIy+IRRM5h6A9GBVWvIQg/yB2a/uPVmP6Zr BP9YaZT05uwJcr6NxBCwXkNz5Za06s85ZnfMiO9xv6+KBRrYbW3Szwu7Yi9Z3vm0Wz8W SQhjxbylOplfViYEbQja9ssjyqQsn0HS9FwMSdD51PrM6Cbu2dcJOT0bitxP5oZE5J26 rdIA== 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 :content-transfer-encoding; bh=fBXmvcw4Nxl8SCjXJeRABWlDR4tPOO5oaj1LyTSI8mM=; b=RMODzvpxkgh4ouEC9OXjMFHaj1K+kaSoGvN6fHqOY4U5vPp/BXJQmJRnWx4+qjvMj+ 10IYcintBZaWp5cxLORBUny/csggrzfAao/R/VxHrb97hbLDNImMkGgfNjctFgHidIpB SY93z84mUjbIeL7zUVfeVd1yUnAyubvfOdrnDl9Mw/eVYdiC0czSAEsqEaL+ajGS0HRA xsbZoDUbSPWs/SXdxMFBWu8Tx5aTgPVvG5Hj7s3k6go2xOEgYbBGpm/BTQrFm86Xb9N9 4yyFAnt3ytDBDPMjMKqn1hkpu+W4s+oD4IArNZY7eAlOUfoAFmIPaWqrSdtkyUAUqvbK zBQg== X-Gm-Message-State: AIVw112fw/MEy9GOxX2tbTm7qt38TQlz4onDZ0yST8NUz+49bEmhcsas z9eCe2kFJToJuTG5/Y9c2W6ziOsG6ria X-Received: by 10.176.17.26 with SMTP id e26mr3592340uab.94.1499993311379; Thu, 13 Jul 2017 17:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.59.203 with HTTP; Thu, 13 Jul 2017 17:48:30 -0700 (PDT) From: Zhen Cao Date: Fri, 14 Jul 2017 08:48:30 +0800 Message-ID: To: lwip@ietf.org, draft-jadhav-lwig-nbr-mgmt-policy@ietf.org Cc: 6lo@ietf.org, Routing Over Low power and Lossy networks Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Roll] Comments of draft-jadhav-lwig-nbr-mgmt-policy-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: Fri, 14 Jul 2017 00:48:37 -0000 Dear Rahul and co-authors, Many thanks for the hard work in contributing this draft to the lwig wg. (I am copying roll and 6lo since some discussion will be quite relevant) As I go through the document, I found essentially there are three types of different policies discussed: a. Trivial neighbor management (FCFS/LRU) b. advanced neighbor management (proactive and reactive) c. proposed =E2=80=98reservation based=E2=80=99 approach Logically I understand the shortcomings of the trivial approach, however in practice, how much this many impact the network stability is not convincing enough yet. (what=E2=80=99s the possible size of node density/mobility may be impacted? ). The discussion of reactive and proactive ways of managing the neighbor cache entries is helpful. The discussion about the proactive approach in Sec.2.5.2 quoted below has some pending relationship with RPL (if this is an acknowledged problem by ROLL WG). Anyway this is something we need to discuss with the ROLL wg to see if this a need feature. Currently there is no standard way of signaling such neighbor cache space availability information. RPL's DIO messages carry metric information and can be augmented with neighbor cache space as an additional metric. For the proposed reservation based approach, I think this is quite a practical recommendation (if my concern about a. will be relaxed). I also found the Contiki RPL implementation has recently used a similar way in its rpl-nbr-policy. Shall we link the draft to the open source community to see if the document has provided additional help to the implementation? (or that=E2=80=99s already done given coauthors Simo= n and Joakim are both active contributors of Contiki)? Many thanks for discussion. Cheers, Zhen From nobody Fri Jul 14 03:12:59 2017 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 B4CE1128768; Fri, 14 Jul 2017 03:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0x9PRDZ71szq; Fri, 14 Jul 2017 03:12:44 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 36C62131828; Fri, 14 Jul 2017 03:12:44 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id g13so30559312uaj.0; Fri, 14 Jul 2017 03:12:44 -0700 (PDT) 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=ESWO4R7vYDuE6brUbrTdV7T1CtVzgcf4NQ/4vRuLpZI=; b=Bb8neqJjBMbDmn5hQbE/8kq6mQU3uJVhw5sBCGRde4cMn2Snf2x85hPyLIlVB7AyoM l0QNkcZOqr0PSiKqWiRGh6xMk3SGCGVVskO4doIYQs2p1MVYE5Qt9pipdSep7WIjBuIo nqz1MWfySil002dAdRZmLCAGbSwu1v2Q1LPGUWEUjklV9GRrvfnnDHCHfTcGEwOwd/di d9YtyUA/TItq0aQ7BJUap3sSZI2OfpiImFs2CrcxITNnMrgFM/KSe+4XBSnkPjGH7Q7A ohZeTzVcAV0IdAlOX/dZ+sheHKEXCQqg0kJ0KhdTuNFhUkH5lwEjg7K5c5r+diDbsrnd 9i5w== 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=ESWO4R7vYDuE6brUbrTdV7T1CtVzgcf4NQ/4vRuLpZI=; b=o2/xoWDb1OCLNDe6yfTM0crqmm1FRaQMOhLhoBIpY7xetP9Be1xLEuWXXSYTKwVz7b INXODbV+ctbB40lkXYL+uKYz+5fiOSLxPq1Qh86eYJdqPdbrImCQSZFdgSb2NNXQpSxr duFkCVKXNjFA97EUBYBDAvci1D5sEl3aOr+D8S3DghcAvZTvglrbbTuSWRJTNAsmvCxe PSM7Pp2NwhsApLkLcCmSTKDYZORH4JfhXC47YWlSKsAFyJb9/Q9lsguBQOABx2APRJlZ yyLFXrKEeHqGzTzz0apwVs2c81bAAQ1dvQwMIo/ehq9lH1T8pTFjGjDJrZiKdtxHvsQh syKg== X-Gm-Message-State: AIVw113UWROFo9ZIHHsEmSwm+nw15KH0hX6cF0wu4LShk/7KbV1TNM3N l94VqAgJcRTVgFeE5CkvtIlKwtNsJQ== X-Received: by 10.159.33.237 with SMTP id 100mr5453945uac.108.1500027163270; Fri, 14 Jul 2017 03:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.65.136 with HTTP; Fri, 14 Jul 2017 03:12:42 -0700 (PDT) In-Reply-To: References: From: Rahul Jadhav Date: Fri, 14 Jul 2017 15:42:42 +0530 Message-ID: To: Zhen Cao Cc: lwip@ietf.org, draft-jadhav-lwig-nbr-mgmt-policy@ietf.org, lo <6lo@ietf.org>, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a113562da3863d80554444aa4" Archived-At: Subject: Re: [Roll] Comments of draft-jadhav-lwig-nbr-mgmt-policy-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: Fri, 14 Jul 2017 10:12:47 -0000 --001a113562da3863d80554444aa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Zhen for the review and comments... Please find my responses inline ... cheers, Rahul On 14 July 2017 at 06:18, Zhen Cao wrote: > Dear Rahul and co-authors, > > Many thanks for the hard work in contributing this draft to the lwig > wg. (I am copying roll and 6lo since some discussion will be quite > relevant) > > As I go through the document, I found essentially there are three > types of different policies discussed: > a. Trivial neighbor management (FCFS/LRU) > b. advanced neighbor management (proactive and reactive) > c. proposed =E2=80=98reservation based=E2=80=99 approach > > Logically I understand the shortcomings of the trivial approach, > however in practice, how much this many impact the network stability > is not convincing enough yet. (what=E2=80=99s the possible size of node > density/mobility may be impacted? ). > [RJ]: a) Existing open sources (such as RioT and Contiki) implement trivial nbr mgmt policies ... for e.g. riot uses FCFS, and Contiki previously used LRU (but Contiki in the past some time has upgraded and put out a new implementation inline to what we have proposed) ... Through this draft we want to highlight scalability issues with such trivial policies ... Scalability issues arise especially in case of dense networks with nodes having limited memory for neighbor cache ... b) Currently the draft talks only about reactive "reservation" based policy, since our aim to begin with, is to check what best can be achieved without making any signaling changes ... But clearly this has limitations which also are highlighted by the draft and we have put forth the reasoning for using proactive signaling ... In my deployment scenario, we could never stabilize the network unless we implemented such a policy ... My deployment is a typical metering scenario and the node density is not in control (network size is, but not the node density) ... In some areas the node density is high (100 nodes on the same hop) .. and the nbr cache is limited to say 25 entries ... in such a case NCEs undergo a churn which results in routing adjacencies never stabilizing ... Specifically, the draft will help implementers in cases "where the node density is higher than nbr cache size". Another way to look at that is, even if a node can afford to store a bigger nbr cache, it is inefficient use of dynamic memory. Proposed policy can be used to reduce the nbr cache size and thus optimize mem usage! > > The discussion of reactive and proactive ways of managing the neighbor > cache entries is helpful. The discussion about the proactive approach > in Sec.2.5.2 quoted below has some pending relationship with RPL (if > this is an acknowledged problem by ROLL WG). Anyway this is something > we need to discuss with the ROLL wg to see if this a need feature. > > Currently there is no standard way of signaling such neighbor cache > space availability information. RPL's DIO messages carry metric > information and can be augmented with neighbor cache space as an > additional metric. > [RJ] As I mentioned before, the current approach is a reactive "reservation" based approach ... It improves network stability but still has its own limitations (highlighted in the draft). These limitations could be worked out with some changes to existing protocols (such as RPL). As part of LWIG draft we have set forth only requirements towards such changes= . > > For the proposed reservation based approach, I think this is quite a > practical recommendation (if my concern about a. will be relaxed). > > I also found the Contiki RPL implementation has recently used a > similar way in its rpl-nbr-policy. Shall we link the draft to the open > source community to see if the document has provided additional help > to the implementation? (or that=E2=80=99s already done given coauthors Si= mon > and Joakim are both active contributors of Contiki)? > [RJ] The Contiki rpl-nbr-policy implementation is already in line with the proposed draft. We already have the Contiki implementers as co-authors of this draft and their inputs have shaped the draft quite a lot. > > Many thanks for discussion. > Thank You! > > Cheers, > Zhen > --001a113562da3863d80554444aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Zhen for the re= view and comments...
Please find my responses inline ...

cheers,
Rahul

On 14 July= 2017 at 06:18, Zhen Cao <zhencao.ietf@gmail.com> wrote= :
Dear Rahul and co-au= thors,

Many thanks for the hard work in contributing this draft to the lwig
wg. (I am copying roll and 6lo since some discussion will be quite
relevant)

As I go through the document, I found essentially there are three
types of different policies discussed:
a. Trivial neighbor management (FCFS/LRU)
b. advanced neighbor management (proactive and reactive)
c. proposed =E2=80=98reservation based=E2=80=99 approach

Logically I understand the shortcomings of the trivial approach,
however in practice, how much this many impact the network stability
is not convincing enough yet. (what=E2=80=99s the possible size of node
density/mobility may be impacted? ).

[RJ]:
a) Existing open sources (such as RioT and Conti= ki) implement trivial nbr mgmt policies ... for e.g. riot uses FCFS, and Co= ntiki previously used LRU (but Contiki in the past some time has upgraded a= nd put out a new implementation inline to what we have proposed) ... Throug= h this draft we want to highlight scalability issues with such trivial poli= cies ... Scalability issues arise especially in case of dense networks with= nodes having limited memory for neighbor cache ...
b) Currently the draft talks= only about reactive "reservation" based policy, since our aim to= begin with, is to check what best can be achieved without making any signa= ling changes ... But clearly this has limitations which also are highlighte= d by the draft and we have put forth=C2=A0 the reasoning for using proactiv= e signaling ...
In my deployment scenario, we could never stabilize the network = unless we implemented such a policy ... My deployment is a typical metering= scenario and the node density is not in control (network size is, but not = the node density) ... In some areas the node density is high (100 nodes on = the same hop) .. and the nbr cache is limited to say 25 entries ... in such= a case NCEs undergo a churn which results in routing adjacencies never sta= bilizing ...=C2=A0 Specifically, the draft will help implementers in cases = "where the node density is higher than nbr cache size".
Another w= ay to look at that is, even if a node can afford to store a bigger nbr cach= e, it is inefficient use of dynamic memory. Proposed policy can be used to = reduce the nbr cache size and thus optimize mem usage!
=C2= =A0

The discussion of reactive and proactive ways of managing the neighbor
cache entries is helpful. The discussion about the proactive approach
in Sec.2.5.2 quoted below has some pending relationship with RPL (if
this is an acknowledged problem by ROLL WG).=C2=A0 Anyway this is something=
we need to discuss with the ROLL wg to see if this a need feature.

=C2=A0 =C2=A0 Currently there is no standard way of signaling such neighbor= cache
=C2=A0 =C2=A0space availability information.=C2=A0 RPL's DIO messages c= arry metric
=C2=A0 =C2=A0information and can be augmented with neighbor cache space as = an
=C2=A0 =C2=A0additional metric.

[RJ] As I mentioned before, the current approach = is a reactive "reservation" based approach ... It improves networ= k stability but still has its own limitations (highlighted in the draft). T= hese limitations could be worked out with some changes to existing protocol= s (such as RPL). As part of LWIG draft we have set forth only requirements = towards such changes.
=C2=A0

For the proposed reservation based approach,=C2=A0 I think this is quite a<= br> practical recommendation (if my concern about a. will be relaxed).

I also found the Contiki RPL implementation has recently used a
similar way in its rpl-nbr-policy. Shall we link the draft to the open
source community to see if the document has provided additional help
to the implementation? (or that=E2=80=99s already done given coauthors Simo= n
and Joakim are both active contributors of Contiki)?
<= br>
[RJ] The Contiki rpl-nbr-pol= icy implementation is already in line with the proposed draft. We already h= ave the Contiki implementers as co-authors of this draft and their inputs h= ave shaped the draft quite a lot.
=C2=A0

Many thanks for discussion.

Thank You!<= /div>
=C2=A0

Cheers,
Zhen

--001a113562da3863d80554444aa4-- From nobody Fri Jul 14 13:47:48 2017 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 254CB1316A9; Fri, 14 Jul 2017 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 50dNtfkBifLY; Fri, 14 Jul 2017 13:47:39 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 0A20212441E; Fri, 14 Jul 2017 13:47:39 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 35so11444503uax.3; Fri, 14 Jul 2017 13:47:38 -0700 (PDT) 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=btaGdYelhne61Y9Fq28C5edPJcR7dE+vMKS7J+utquo=; b=p1yl6R6LZGaalf2cgxDYhM3kw3YXq/4jVFnEbpsXfIVtB8lZm97G980m5FHa/mKySK vf0agWmtnhsrM+byTSpkvevSv2DTo5ueofRQrSDGjtZ4pQLWJ4wdv3Jocfn6aSdFhQXC rERRZrBvXKQyO6A+1wpfVLZgdezorH+GnJNmaesfFnHsdpL0f4OGb4qZF/Zgi78SSBTw 3u1+t6FsS5KjadG3TdKOxK0qvNavP92tBQEyiomM6Q+/c9NLlq1HixOQu+a+nnBDvjlH YwT8Um79a2A2A8Xt57velE5iLfFx7spQ7+S/tUPTiSjA/6TbVuLv4cW5sNjgGxD/m1JY qBHQ== 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=btaGdYelhne61Y9Fq28C5edPJcR7dE+vMKS7J+utquo=; b=Z0kyrJE2EqRGgNnQPezVTUXrr5gIke+m418naU2teR+Hnp/Io/fiYyVPXd5VvxMenk MjYdP4uVBnjI6Ee5l9L+ol4lPxqvf8fY1xy2pE58R5e6BXh/CLxX6MYU2RclpmmPgoZM cwkwpbPpDG+p/Llmusw9MhkZ9zwV1KLl05sVTxwUrM65UV2V9dVL7B/d6HWIQPfp20zS 3fdqN6YyHh42PGEfNWbZUOiZyIRTB+D9WqwPRr6UGB+HF74PUjifH/t3jXtFFkqHgwqu ATwT0xiN0Ix1MSERYuDvCSbYdThmoCY1rErU+U5kKLtwxIqk1GsK2HarK+M2cfIlfwXS Hryw== X-Gm-Message-State: AIVw110nBf3GEZqfZKdXWc8IIgVeEmr+TSoaVBDf+44zCsqGBW8D+EQx 4fyYaTn/tqFs9UrwfLgALDutZZpJLg== X-Received: by 10.176.25.66 with SMTP id u2mr4623467uag.36.1500065258182; Fri, 14 Jul 2017 13:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.207 with HTTP; Fri, 14 Jul 2017 13:47:37 -0700 (PDT) In-Reply-To: References: From: Samita Chakrabarti Date: Fri, 14 Jul 2017 13:47:37 -0700 Message-ID: To: Zhen Cao Cc: lwip@ietf.org, draft-jadhav-lwig-nbr-mgmt-policy@ietf.org, Routing Over Low power and Lossy networks , lo <6lo@ietf.org> Content-Type: multipart/alternative; boundary="f403043eb49cda9bfc05544d28e3" Archived-At: Subject: Re: [Roll] [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-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: Fri, 14 Jul 2017 20:47:41 -0000 --f403043eb49cda9bfc05544d28e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Zhen and Rahul: Thanks for looping 6lo in the lwig-nbr-mgmt-policy draft discussions. 6lo WG, please review draft-jadhav-lwig-nbr-mgmt-policy document for any impact in 6lowpan-nd. Also it is a good place to discuss if anyone else is aware of any alternative neighbor management methods. Also please provide feedback for improving neighbor management from 6lo perspective. -Samita On Thu, Jul 13, 2017 at 5:48 PM, Zhen Cao wrote: > Dear Rahul and co-authors, > > Many thanks for the hard work in contributing this draft to the lwig > wg. (I am copying roll and 6lo since some discussion will be quite > relevant) > > As I go through the document, I found essentially there are three > types of different policies discussed: > a. Trivial neighbor management (FCFS/LRU) > b. advanced neighbor management (proactive and reactive) > c. proposed =E2=80=98reservation based=E2=80=99 approach > > Logically I understand the shortcomings of the trivial approach, > however in practice, how much this many impact the network stability > is not convincing enough yet. (what=E2=80=99s the possible size of node > density/mobility may be impacted? ). > > The discussion of reactive and proactive ways of managing the neighbor > cache entries is helpful. The discussion about the proactive approach > in Sec.2.5.2 quoted below has some pending relationship with RPL (if > this is an acknowledged problem by ROLL WG). Anyway this is something > we need to discuss with the ROLL wg to see if this a need feature. > > Currently there is no standard way of signaling such neighbor cache > space availability information. RPL's DIO messages carry metric > information and can be augmented with neighbor cache space as an > additional metric. > > For the proposed reservation based approach, I think this is quite a > practical recommendation (if my concern about a. will be relaxed). > > I also found the Contiki RPL implementation has recently used a > similar way in its rpl-nbr-policy. Shall we link the draft to the open > source community to see if the document has provided additional help > to the implementation? (or that=E2=80=99s already done given coauthors Si= mon > and Joakim are both active contributors of Contiki)? > > Many thanks for discussion. > > Cheers, > Zhen > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --f403043eb49cda9bfc05544d28e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Zhen and Rahul:

Thanks for looping 6= lo in the lwig-nbr-mgmt-policy draft discussions.

= 6lo WG, please review=C2=A0draft-jadhav-lwig-nbr-mg= mt-policy=C2=A0=C2=A0document for any impact in 6lowpan-nd. Also it = is a good place to discuss if anyone else is aware of any alternative neigh= bor management methods.
Also please provide feedback for improvin= g neighbor management from 6lo perspective.

-Samit= a

On T= hu, Jul 13, 2017 at 5:48 PM, Zhen Cao <zhencao.ietf@gmail.com>= wrote:
Dear Rahul and co-authors,=

Many thanks for the hard work in contributing this draft to the lwig
wg. (I am copying roll and 6lo since some discussion will be quite
relevant)

As I go through the document, I found essentially there are three
types of different policies discussed:
a. Trivial neighbor management (FCFS/LRU)
b. advanced neighbor management (proactive and reactive)
c. proposed =E2=80=98reservation based=E2=80=99 approach

Logically I understand the shortcomings of the trivial approach,
however in practice, how much this many impact the network stability
is not convincing enough yet. (what=E2=80=99s the possible size of node
density/mobility may be impacted? ).

The discussion of reactive and proactive ways of managing the neighbor
cache entries is helpful. The discussion about the proactive approach
in Sec.2.5.2 quoted below has some pending relationship with RPL (if
this is an acknowledged problem by ROLL WG).=C2=A0 Anyway this is something=
we need to discuss with the ROLL wg to see if this a need feature.

=C2=A0 =C2=A0 Currently there is no standard way of signaling such neighbor= cache
=C2=A0 =C2=A0space availability information.=C2=A0 RPL's DIO messages c= arry metric
=C2=A0 =C2=A0information and can be augmented with neighbor cache space as = an
=C2=A0 =C2=A0additional metric.

For the proposed reservation based approach,=C2=A0 I think this is quite a<= br> practical recommendation (if my concern about a. will be relaxed).

I also found the Contiki RPL implementation has recently used a
similar way in its rpl-nbr-policy. Shall we link the draft to the open
source community to see if the document has provided additional help
to the implementation? (or that=E2=80=99s already done given coauthors Simo= n
and Joakim are both active contributors of Contiki)?

Many thanks for discussion.

Cheers,
Zhen

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

--f403043eb49cda9bfc05544d28e3-- From nobody Sat Jul 15 00:36:05 2017 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 C8C541318A8; Sat, 15 Jul 2017 00:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 sEVBAP44drTi; Sat, 15 Jul 2017 00:35:50 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 3DD79131AAF; Sat, 15 Jul 2017 00:35:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,362,1496095200"; d="scan'208";a="231602953" Received: from mail-wr0-f173.google.com ([209.85.128.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 15 Jul 2017 09:35:47 +0200 Received: by mail-wr0-f173.google.com with SMTP id u110so11328388wrb.0; Sat, 15 Jul 2017 00:35:47 -0700 (PDT) X-Gm-Message-State: AIVw112uGYHutPBs5wGKNmlH5AUmsM1CQQ93Tw+Sv082ErtMi+N+SSSP uRWPg+KlmsBfkXQwF/A0Ccxpjz5j7w== X-Received: by 10.223.136.178 with SMTP id f47mr6703739wrf.117.1500104146962; Sat, 15 Jul 2017 00:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.130.115 with HTTP; Sat, 15 Jul 2017 00:35:46 -0700 (PDT) In-Reply-To: References: From: Simon Duquennoy Date: Sat, 15 Jul 2017 09:35:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Zhen Cao Cc: lwip@ietf.org, draft-jadhav-lwig-nbr-mgmt-policy@ietf.org, Routing Over Low power and Lossy networks , 6lo@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-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: Sat, 15 Jul 2017 07:35:52 -0000 > I also found the Contiki RPL implementation has recently used a > similar way in its rpl-nbr-policy. Shall we link the draft to the open > source community to see if the document has provided additional help > to the implementation? (or that=E2=80=99s already done given coauthors Si= mon > and Joakim are both active contributors of Contiki)? The document has not influenced the implementation yet -- so far it is the other way around: the implementation came first and we put some of our experience into the draft. As the draft evolves, we will indeed keep Contiki aligned. /Simon From nobody Mon Jul 17 02:27:26 2017 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 F20DE12EA7C for ; Mon, 17 Jul 2017 02:27:25 -0700 (PDT) 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 RlwZd6-drrBu for ; Mon, 17 Jul 2017 02:27:24 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 7C590129B5B for ; Mon, 17 Jul 2017 02:27:24 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h199so14907240ith.1 for ; Mon, 17 Jul 2017 02:27:24 -0700 (PDT) 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=9FJ3Fp+mOrE+4elvRin31YcwKXF168sUbEyQnaZhz/s=; b=Qz4HFj+VW9T+uHkhQ6kt71gGgkHKGAYXvBtL1JHJGR5ypaYyIKel8vs+HLqiqYekPh C/oe9WrutX9KjhzaBYmMw2akhH8U7vO7kVOAscpEF4vngPbVLvKoRH6DRSUsJMt0XTQu ikI6i7Jcgka7dqp+L2Ya3u/0HTjJn0ql0xPrWsJt2U2/vILiV0bBzhEG+KBFF3nukdjq YE6YXF+6yrKt3s5gpSAOhHZvIYB3A1spuAVK36hVtHykhmL22hdhDxuZsd3oPfWbk9Kk Gw2ard7QqsIvtmC0rouQcNzbtmhgmqicDaZldtFBZFlNb3gklPfy+fJbQnf6v/jUN6rO FJ3w== 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=9FJ3Fp+mOrE+4elvRin31YcwKXF168sUbEyQnaZhz/s=; b=tK2yIj0IzpfzCqn03wemavOsTPUPJAxFCVWAX3XiGbX6Sh+NfvF9TFMRWRVyiNVlUP CHAaqWPEdcUgM33GmAtRqq/6herK3n2BEoKvuC8O0YkSQOEAV6uM7ZJNEjxYASUbOgR/ WqacYHrGs2dkKEjikeEMZ+ceHbMJr1zo4YUHvweW4c9SKidEA/ubhRsq603Uox3myQzV J6xFwXcujqb9fCfbXaJtTp63tOPPJuy2P33yEbg1fvt1g1yNBkKZtUDl8rJKg0gbXHcS upJBRa1GewRQ0iEHlWLYDxu8ArLmWp6/72XfZM8cVdUcqLlssa+2AvtQSnL4Zxx1jxO4 hY+g== X-Gm-Message-State: AIVw112cHmC/KaySTQgaR/h0VOAOpysLCzYIfyoSRXluZ2tQGfVwmFNe Bca1tIRxnm1zsD8AwF0dSrrcHKGXeJYb X-Received: by 10.36.110.23 with SMTP id w23mr4588384itc.24.1500283643730; Mon, 17 Jul 2017 02:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Mon, 17 Jul 2017 02:27:23 -0700 (PDT) From: Ines Robles Date: Mon, 17 Jul 2017 11:27:23 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a114aa0daa5c0bf0554800122" Archived-At: Subject: [Roll] Slides IETF 99 - Draft version 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, 17 Jul 2017 09:27:26 -0000 --001a114aa0daa5c0bf0554800122 Content-Type: text/plain; charset="UTF-8" Hi, Please find a draft version of the slides for IETF 99 https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf_99_roll_slides_v1-01.pdf Comments welcome, Thanks, Ines + Peter --001a114aa0daa5c0bf0554800122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find a draft version of the = slides for IETF 99


Comments welcome,

Thanks,

Ines + Peter
--001a114aa0daa5c0bf0554800122-- From nobody Mon Jul 17 14:37:57 2017 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 A3305131BF4 for ; Mon, 17 Jul 2017 14:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 P0878ZUNDxMc for ; Mon, 17 Jul 2017 14:37:54 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0457612942F for ; Mon, 17 Jul 2017 14:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1500327474; bh=LphI2+00Hy7TfnMjTi7lKrsZqRbq2zuScIhN KnIZ3Eg=; h=Received:To:From:Subject:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Language:X-ELNK-Trace:X-Originating-IP; b=nxGlwid3xWKDV1Ve JDSrCH30zMErzKn6JhmCm/xg/bTzVMhE2iYOG+xwwd1ZmpeChq3InT5yCxIkPLTUfIB q4FTlzb05QFGNXK6HoBEpc8ByD7XBQQ/S5cmLH64Qvbg7zQiG1NRSxLxLFanTkHiBWk Pkzg2D9MjdsUMt7A/eIKPd9ALQTsnoegl8JONMKcR3Cw1f8plcnR6r7IXZh9Og1pylw rsfYeeFSvbi1t0UVMFZwp+v0/kAErNk/H73aA6XelnNacFenHrouKVSMZn1NiXeMHCi LvM9g9y+FCEMMhf7LgW4szKB7PWQspjBwZ84UTez6wlBflDDR9FOumYKFQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=m+BQXlHlMxtSEJOI/Q56pD2Bq+QDMpRRDMdnwGpM6GIurOO+4UpF61s1Wlp0y3T/vIAi0+ifXcOqZ3R5qTkmWzyR1aGXhy5NCiq4K3ARI88j1kI0ySrBkVZHKPJpJs2loApRefzeUtuknEj5tegTq4YL97yJLn0wdxSSNB7m4PVhussTr3+gB2zu17jj+Ge0NDNNqCRMWnh5VAqSPJ6TA8MqpTeHncDnMXAHjXMaQN5PokN+CO1ic1oe3gLESnCzHGLfNigNKAb4Yatt31SUn1qAGM71Rzard5tvgUtnBvU6iyGIEUjoMJsKDxSngU4n9ik/T+KrqONcgAEaLHDPJg==; h=Received:To:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.157.127] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1dXDiC-00095g-Qc for roll@ietf.org; Mon, 17 Jul 2017 17:37:53 -0400 To: Routing Over Low power and Lossy networks From: Charlie Perkins Message-ID: <0ee2fb56-03b9-1635-5640-2ed1d748a151@earthlink.net> Date: Mon, 17 Jul 2017 14:37:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95cadde61a18db5f2e1e6e64dd4c56b065350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.157.127 Archived-At: Subject: [Roll] AODV-RPL currently is stable: discussion requested about two possible updates 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, 17 Jul 2017 21:37:56 -0000 Hello folks, The AODV-RPL draft has been pretty stable. There have not been any modifications needed that were important enough to motivate submission of a revised draft. We had a suggestion for supporting non-storing mode in AODV-RPL. Prior to our presentation on Tuesday, I would like to discuss whether or not there is support for this improvements. The mechanism for supporting non-storing mode is straightforward -- basically it is analogous to what is already specified in RPL. Using AODV-RPL in non-storing mode would no longer provide the benefit of small control messages, because the source routes would have to be stored in RREQ and RREP. However, for the class of devices that cannot store routes, AODV-RPL would still provide a beneficial way to establish peer-to-peer routes. If it is desired to have both storing mode and non-storing mode in the same draft, I reckon that the AODV-RPL author team could have another draft ready for that purpose in short order. If it is preferable to have another draft to support non-storing mode, then that is also a possibility, and likewise the new draft could be done soon. Comments will be appreciated. Regards, Charlie P. From c-lavanya@iisc.ac.in Mon Jul 17 21:53:21 2017 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 33C5C12869B for ; Mon, 17 Jul 2017 21:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=indianinstituteofscience.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 jl2bOg6pwOGg for ; Mon, 17 Jul 2017 21:53:17 -0700 (PDT) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0064.outbound.protection.outlook.com [104.47.101.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB992126C0F for ; Mon, 17 Jul 2017 21:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=IndianInstituteofScience.onmicrosoft.com; s=selector1-iisc-ac-in; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=octBjURqw3hQA13tuAMr7IfI9kL9Dli9Xh5PSvY3Vt8=; b=gd0Lx6tgbcI1Fegl6xw8m3Tcn8hkT/1AjhVnQus/lRjJuhqD2yicVyt0Yoi56cOIHryec38egG5NQ3lm5PZcT/CW2y6aullKXPRJoRD0mSE/Gaq34L4A1PTUx/DMqnf91uY4pl+ZGGB6lPl+wz/pe0KDPq1BS/lc0nSn32QAD+Y= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=ece.iisc.ernet.in; Received: from ece.iisc.ernet.in (14.139.128.22) by MAXPR01MB0185.INDPRD01.PROD.OUTLOOK.COM (10.164.149.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Tue, 18 Jul 2017 04:53:12 +0000 Received: from 10.32.13.87 (SquirrelMail authenticated user c-lavanya@iisc.ac.in) by ece.iisc.ernet.in with HTTP; Tue, 18 Jul 2017 10:26:44 +0530 Message-ID: <1b9c00420fef2e15d2bbfd6217acc795.squirrel@ece.iisc.ernet.in> Date: Tue, 18 Jul 2017 10:26:44 +0530 From: LavanyaHM To: Reply-To: User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [14.139.128.22] X-ClientProxiedBy: KL1PR0601CA0016.apcprd06.prod.outlook.com (10.170.160.154) To MAXPR01MB0185.INDPRD01.PROD.OUTLOOK.COM (10.164.149.139) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2cdbf11e-6b0e-4dd3-6fcc-08d4cd98e532 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MAXPR01MB0185; X-Microsoft-Exchange-Diagnostics: 1; MAXPR01MB0185; 3:epuYgSRhs8vbxTZ9ZbE1yvpPTGO80MZifOjfQbM9xlUKnPFdt8LgUpa/boHSf7zIV9jo7rdQsOsbPmqlbc4jUmFKySmxmsfvCvV34EEhBbZOWc+RdmKbu2y1DqDCv/JY852h7wtA7llAofJIiE2j/iKs4lvCzwsCmA9adsMcuehqQ/JjcmcP34+bs1v4gq8y/FjIujdeotVvepeDfqlBw7umuDEhlxFS4GUM0bv8VHu6sVz9lsw28YWaV0zlUn0mcOETjouFkEHIG7JvO923tXL9IXh7I2sqRvjzaDbPf3mYVd9RZ36JH602ISla1volHJboYUeEddC5oXqtUt/j5yilGR4rEx5XfpY45ZD5uXl4Is0nFX9xhAcxy6TzbjLASWA0dOaZsnOciawYgzIyn5cOPQH8tuMTiFlu6nyLe91Dhj0LqXAE62xYdgj/RdFkBVKaDaF+2wNe3iFHbhJfrg1WIZvGhMLRVfNI8bY1f9RcvebvWjF3+WQ52z2tVCeVvt9I4V2zVAcQtN2rUod4JAey8FALKaK/VefDtb/6TEQTvZCxTH0KU4p0BKtggo7TnC2b+B6NjfA1Gk2ynFupOj8BAcHPlNM7GLCeIaSj5ZK6GcyehR0xdjMh8RPkVHLglTb6/VsPbbZ0t7t7dSlpjbws/H4up4is9FP4sHf5jrl2ZgU++f/CdAXX06DU8RzVuF8PFlgZREhfkmTq+yUiQ++gSpC+oXYREDbF2JG6B+o= X-MS-TrafficTypeDiagnostic: MAXPR01MB0185: X-Microsoft-Exchange-Diagnostics: 1; MAXPR01MB0185; 25:YwJ7AWUNG76WUFycGvxDjtUHeDm/WY3w8GKqZIFoKi28h6gMY5Z2fo3K11rnECTrJzZJPqgjjiDuadLTWzMcaoFi0p+9It578HS13heHxuwpbz2MiunzfHvS89E7FjKaDnyhvZyWv9jMh3K1kuhUPTIU2eyj4AZ9OuZ3wKtPvORhaLy3q+vb9yYEcLVvim13cB+Cx2D4HqXgpCJgBHuEFmvdundI5rbjBMcTX6BYSp66gk0bPc5ilXUUGEri4au2XgdOXGv3J30TNxh5fzTCfTTK8kVn5tIeBYnTwIgb2/gwtLAXD0XV4Xi3t5QHxhvZkf2oaNCNG2G1yNwQwU96ULNyDNblobPzjsMPssuTDC4b3dA4JX+GQrPUWOskhRJAb44eUwN5LpUlBZkGfUZckWbf4ytwVj3AcyK71Lp09/JgqdSwNAWFCfGLrdOdVBj+XB/wzypucPO5pkF6FY+u3uC+qzanII1b/7ibTmSgQVmQyBLoHpWby/c2kpMw3eq+YNLRlT0f17v3zQwonD4s/vc7nsVbQIzs4DmJ7hCj5c/vpjs9F6d8zQ3HHeOb3kqICwMMhFfe6oXQ7RnLzgP8CRcRRE4tFi2sDWKTFIkt7+GdryVBLpiiFvGXfJqkJymBWKs6vPC6sZdg5qYvn7WzrIppqL8ITIUDUqjgUTs8mCU9AGWgalX0O7OEGnD9aWrc1LelNgQF64fdRH6guKTFZe4UAxOhZLHF3bIyzDwMTyo9CpnORVC1VuZn1X+fY167QmjAm/543rBR7/P0HoVCRFM1Z55h7Jm7X748R0wAyXNnuqzEQr1aNqzpwNxFTk9lbuXdTEhTtfJ2nMx6PIogCu3VTrhbTavKgJ2LvxRSiTf73YxcJJ1MFscdJz3VoTAYol2vyV5BWtZEMQgPnh2xeQtG+jxHAdtc5daFdAyu3AI= X-Microsoft-Exchange-Diagnostics: 1; MAXPR01MB0185; 31:EG6SHiOF5Qc6eZdlYflXvh+lRUP5ufpgthzTFyi7egAw2t2ENrA7ExZlVH8vs45WySCgacfj0kUGYrzzmv2xPv1gxPxUw4zYxj2kQYAKiLpYRg1EhZPUbZlbvtZ8Vo/Zn9e5X2sVCYasmRxgU5VScYhEiJlyv8sbUpLxGen5lFX1Y9TWbrUJKqbTr+haoMcIvnQ6fNhYJ9i90eCZz8OiLnZTwMo2/8e4gZuMASBmYxtifschu1VG5uytY9PZS8Vqfv2MGV4DMkMMiUNm4LWiiliMKlNjrJPLRe8idzKU+sAzAkssAX5P5EtHkM4NvklcqNUjbiS4UnQ8k16SdoR8Oscc9Kw1BN3TBS83AgfrjtWqOaND+JoBhDqzOKmdzuvQ+YSoN1dlxYwx1HxeiOCGhG/UEXp7BQWcJ7+0pinXt6NZaeXTx/MPA0J2hbRIYus8XzePAwyHlskBXP6jnNux5jGJpocRC7HppIGZbspXseP4XS2hKKTvhUtORNn8XIAKTxl1vfcDNT9PqWXBkDSxgNJgaXshi/un0WpEIXoYMo9X3QfthRZKsU1FSNHIuwoo1274IKi/VC4h2W6Ik2IQYKQGGboVp6Rz6jD5uIEmZAjacfr6pshgZdSFlvIrVnZUb5thAGapCVESXYexASC+FphUgJUHk89mwwpPGFFR2FVDQtbI496N+SXWUKzTg+WJCeNxRvfcj/lTRchV0wr0qw==; 20:E3I5iqs9AdckPhkhWOyk4tNKO+lecSdDn/nShc9tuTl9RYYpMXt51vYNb8jdxv3smk4GVarcPSrOrtXN7axsNbh1MmOIrViwd/yVUji2gyeOC+P3q6upWf20mwI/Zzc3ZenjQVkLmTEnAEPEIyZ4HWyTODxTPfHaXKP1+S18WhE= X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(48057245064654)(92977632026198)(209349559609743); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(3002001)(10201501046)(93006095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MAXPR01MB0185; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MAXPR01MB0185; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MAXPR01MB0185; 4:SyKB0Vms1jeYzSvOghTuxRMdTwB5a/XTZdoHW/Wr?= =?iso-8859-1?Q?EWeD45ImBXtrwy0Q08i4+06FgdHXEasqjYJ1Aqr+p9lAT8Hx3zrOZD/pFK?= =?iso-8859-1?Q?95dZ/UffD/10syeltYqbIYBs9SlZhKxmHbNWCeWZUNAnrKoy5BFFCK1kCE?= =?iso-8859-1?Q?sVavMXDqOF/xUDIlpy5YVSGxpe+948Zen+WR/XRLt4QErgOxmsJT0aQn6j?= =?iso-8859-1?Q?HECQX/FqX+LfDnV/Oh5AezVnOum0eexXeojsFvGW30HvOE8kck5pQ2Rfzu?= =?iso-8859-1?Q?r/FlHQNfNCMcuOlUUYT5mHOyl3RLRD/iO61haXui42zUH+MIU17XmD0AXg?= =?iso-8859-1?Q?UJj1ZrecRMnJWwOB5TjP+FabSMWHqOJXpxpTYwTSWiVk23+Oa4lqcrM047?= =?iso-8859-1?Q?dkH3yHx13P54NRmVaVCrJKCd8mUjcQXs2azfYMInZqSJnXhnjYHxoSmJks?= =?iso-8859-1?Q?nxdebWhVFLf0deR8fvEvXhhi9FkQF1jyLg5sLR0Q1Q1/ezU5+c0TCjtnZ5?= =?iso-8859-1?Q?CZyJw3bETfmvURqa2Icc4hh5cpHj9KbL9Hw/ELgv1T06QR3nRSxyGveJDL?= =?iso-8859-1?Q?VkrFwwUfZhwmCErwfE2R3XwJ2pHrlGeUh5L5BDQvq23YocVr1dG9ZEay7y?= =?iso-8859-1?Q?Tgg59aPWmTCDyqO7jUNGxwGduBes6+TkXaIgQcF8NANQh7g2ToZCmZSi+P?= =?iso-8859-1?Q?OmOmzazX/qro0UPZd4oQkoEvx/tSzmJLYCquhgvPfJY8V8/P7V4iq7ir+6?= =?iso-8859-1?Q?dyCVgRnQbuBOvvR/au2gxpafZKlOD2zwUTaDwfKKhmndposMyoidp/p8Jp?= =?iso-8859-1?Q?W12x/2hyFFJGCv7dM0qRmFpFiwUcwMM2eh9kuuz9t/kZh0fY9/Mg74lsQi?= =?iso-8859-1?Q?HyAKcF12tg114mxFB6OMKmljJTgJ9sjgp4AexEdA/wKWEoM9EPqcQ8XVvJ?= =?iso-8859-1?Q?kYEcwiroj4OHv53PRCbHbGGs8uWXivVOEKfe8st7VQX28cjSk0TTy1JJ1/?= =?iso-8859-1?Q?r2WTypryCnbHhf/kKxLxbrSZ5Bk/6oWZP/CZo9aWJXKAqD6ic7mSOV3pcf?= =?iso-8859-1?Q?ipJJxdYtbH8jYfXLZYBrtLVqrC4ep6VmgYjr9Jboh7ZhrGTYiK1a49JBs0?= =?iso-8859-1?Q?t2rMdVgIf2//wfb129B23EQ/TAOI4SewZOLwzxr20H3tOFfu87ug5vKLLh?= =?iso-8859-1?Q?7xtlwQVBZ88eegSQUb9VBoiTsCm7twM3g/ImtXFDBlntyq2wPbpliPMZNi?= =?iso-8859-1?Q?CWrD3QJ2M0SsZWPQQR79M638lsCxmCiweeEcfZbGS0Tx4scrfi2TDuf7Jt?= =?iso-8859-1?Q?N0wfujj+HUIUscRtPwJxmTSJnvOuFr7x7+GCJbd5c9Ijduk/vbwaJHkZSt?= =?iso-8859-1?Q?0nfRTYNRdGGOOc/85Sq+nTf1cmZR?= X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(50986999)(305945005)(54356999)(110136004)(38730400002)(2906002)(2870700001)(3450700001)(53936002)(118296001)(81166006)(8676002)(47776003)(66066001)(50466002)(74482002)(23756003)(43066003)(189998001)(7736002)(42882006)(6916009)(2351001)(33646002)(5660300001)(720700001)(3846002)(6116002)(39056004)(83506001)(4001350100001)(478600001)(413944005)(7350300001)(3380500001)(80872002)(63076003); DIR:OUT; SFP:1101; SCL:1; SRVR:MAXPR01MB0185; H:ece.iisc.ernet.in; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MAXPR01MB0185; 23:BfhIdWlo5ybJypd0shoVsY4wFmx7VP7M5L9GbR9?= =?iso-8859-1?Q?wKmLs5B+1j2xBShu8ugfBA8gOp203b33fK+w2ExZS9x3VjEe/jJitXMw8J?= =?iso-8859-1?Q?VY6mUw+NSmT8ZiOug5uPbIRmWES6J7i5OkrGTCCsqMwAMjaudj3FhDBGWL?= =?iso-8859-1?Q?WbyOx2c3vFTia6Koy9JxSMXRtfK7ENbceTJX0xEdrDTrMqNgv0rmtMHgrO?= =?iso-8859-1?Q?nI+u1nlGTAvW3lCypxPaf6n63Nso/PdHfVMtYtzqVIxt4US/pVgq/nVwQe?= =?iso-8859-1?Q?vKlRoqvEcpDzj1hTCRTGAyuylaWGLgd+5CxS/2gun/C5IVgh8Rncn8NRE5?= =?iso-8859-1?Q?YVcoRbTjZE28nsK31ZRpZVCMFNwCUlK4MNQzPCS4QPMCJNcob2AnXVtY7E?= =?iso-8859-1?Q?Cyj3HF/8Jo2qtE4zGd7hTW76KK6ej2De7GNJyY+NBlkzg0gisurb5X5erv?= =?iso-8859-1?Q?b7QaRSmIHb1KZDMq+9tarXR6HYTZVac5KyaBjt0eRTx+Zv6DVUboxPQuFJ?= =?iso-8859-1?Q?Ou6dLsPQAhwwEw0TCJl21I6/FWtW7x3FDpteGKugqzE0QyNQfkDS+FI+Zs?= =?iso-8859-1?Q?BLxoDFwW2wevNspGIjXkKgA9gqboPhD1FsTYwFQmgO9I2hXK1zVQythe3C?= =?iso-8859-1?Q?C0nxtJZvFvjRpqnqIRvVD3HRwNRFlDuK/wJKWRvSG6yhw03XxLs2w/xCkY?= =?iso-8859-1?Q?uEWAWL4QoNoKKDfC6eLiIpJ1A7lAIZNB7lZ46CPJyXzqYjgqRqraUmObd6?= =?iso-8859-1?Q?x3o/KhAwGtDMM6VREDHg6+nQC1BCNTZO9ziIguHz3P197pyRChFy7sqsby?= =?iso-8859-1?Q?09+tinOePz1I6Z5Ohk8kQv5mVQHym3aw9BsLsP+jXOp2eqeEWfR5toNYvA?= =?iso-8859-1?Q?fZC6VtplMOVjJOFRLIj5MR5WXZSYoi4iUMQzSJNklTnaOs714V/GuC5lJ3?= =?iso-8859-1?Q?P3FnrXTiymdah5vqBBGW2LTOhWgSEBYuDsuQ7GykYjYCOGsOCUI1l3LTH2?= =?iso-8859-1?Q?0bZG3ulsg4CZspSHbRNRzA+dciRKUXM0O1tb/WRpwSEM3GFEsjF5ktd8/L?= =?iso-8859-1?Q?BhsRPDZb9efin+89t3QTFVxV89C63ZjbLd98yi069JAyFPFN11TVT/g5BL?= =?iso-8859-1?Q?fSixeWRw03Cilh6Piwso3wkDEpHZKTf70oMTJ1ocdCJj5dC8W+EP1B6oTr?= =?iso-8859-1?Q?02DCa9967KF?= X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MAXPR01MB0185; 6:6XCYCuNuTS6S3xKA9TLyX4fZhUwXs2+ca1Y9UQcx?= =?iso-8859-1?Q?KHdjGWR4oiLoYX9RG4FdgKynMTOIrH0Z8ctH5cNoTrU/aQYqR8PmJUM44d?= =?iso-8859-1?Q?bgHhyAQ6xnFgqfi8dChmV6vOVLwYGUc0uupwPsB8npFcfhCYIqwWR8p5TW?= =?iso-8859-1?Q?xh2ik5+ZUd+tiU2nxybiH3SdRiMXmmerLbznbEQuHXKPttp2IGcdQNUkl0?= =?iso-8859-1?Q?Gg11eotDr97vwp/4uzA6zCdYwji9avJeu+SH1fKvacOEri0r3XZUlaFtyd?= =?iso-8859-1?Q?aUn+twGfL9YMcXpjUQceBO0Bp6m57XYimBXMBWA0t9bjABe0tyRYb1ys0V?= =?iso-8859-1?Q?O3uZ1UsDsf3V6fJ9gaz/nn7U4LZuMLDsrv1Zw7CUieEnIeS4YeX17IUx0c?= =?iso-8859-1?Q?MoS8P5jRKidU7jc+hKA9s5LJrtnUbTB92L84hxI9RPlz9vUHH9NZBAlrtT?= =?iso-8859-1?Q?L/mKtYQtDl+gFuJ2Z8WAqLuyzPiu6NFlTGdXyL68MNycdY18p26xf+lEz2?= =?iso-8859-1?Q?Z8KKTD+leTmpG5I+znSjCrVHpGcTCUKgNI1N/11VjvL3OOBBLaN6kPN/6w?= =?iso-8859-1?Q?+B7oQUpZeq89X7rk85msJ6w2GB5DBIYVngVlnyOf1f/4NtlDjfNn+b2SA+?= =?iso-8859-1?Q?/afubdJS14zvSMbBiqeYOo5+GrDH6nW/SZpULvXCpi8CAI7B6PSWelQY9R?= =?iso-8859-1?Q?EtcI69BV735PWxq2mptb2Uo/DhAwfT6chf9W8gDINVupqP5KGG7ArFN5of?= =?iso-8859-1?Q?5xETHf1TVHTUs6sIZoBONVns5lmWzyVT4hfHTCsSqqJjY3RPod3Nlt/mvs?= =?iso-8859-1?Q?btDHnXym7RPbOpl4qitD/xhohKA/ysIV9Q9dP3BIebXHhFGmt8tkhwBhYY?= =?iso-8859-1?Q?v/O0n9UNzIdRfrhIjdEy3AftvyXWGu/2uk3bR7Y2aYlaPq0Ix90ThvtP7+?= =?iso-8859-1?Q?H6bqcV8nMapb89gnkkFabsKFmRDY24Vhh9A5oO1eQO30Dc+paEsRuHo6oC?= =?iso-8859-1?Q?p3OnidMbuZrgG5WgQtztFaCxgkh5hvQKrRM=3D?= X-Microsoft-Exchange-Diagnostics: 1; MAXPR01MB0185; 5:+gT/Q5LkzRptflu3hVg9tBd0/AwO2IfHqKJHXMzgHvdwGmcrjIPfOAOZq+i9fW4iZFhNM5ZmLYV2L6rd1jP6NAeeXeMQ0CO4jmtlHCNXOAQJ/Glek9LamKzrVED2hKBem53oLSgKMBfO40vSSRE6xLl3vq6LWYWdm2eSXpmLsei+htCL3KflATHW2OAJJlnLN2SuQ7lvAbfiGGXWcEo4OAmYu5NyU05IOj1VNiNInFKLHXjAYk3WkhQy4aCH6mFBnmACYRZPJviT1Lw4IjBv+1W7geRbYm8Eg4Vj4q4+ym4Slnwoqsf2vC5bM1NDCBSa2AJ9QtGKObq04SadB6+QSkNEC+ifk3g08ZYEaBZDkvjCR5nUObcRhMcEYzlJIQA+1T9mCA9SIXMCq1rht/41hcIuDOKiizqlPUyTI/V3ZdJLbBtF2T0IUlTgdYqu0ybjIXq38kdgm5XiCLWmMDB5QCzJMIA/NBXT6a2aN+XrMJvepG506beN5j2MIZdM3GO+; 24:v874lXFGP9DSMHrbi0B1OEanCoxzrljwOHRJ9Ow3jSfXyNka8m+q86tlVkxSjUKsgElyAmLOWKm+WT6LPeIH5QbVqphBQ8PiwZ0+lCgFSp0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MAXPR01MB0185; 7:pxW6owa7Lk16h28cdULRpp72eVmuuE6+BcgaxyyUcE5eCQUb80tNWIELuSQPjwY0rRWeOiAYUDUpfjNbJZ1bcQeXKaKM7ID14gENcoixVtrm3oFq5z1AwfB5It5j/YkIl7bvZls//8t4zWN4rpPsK0A7yL885kvEoiOge3PBJien/0cxw44537R6pZPwZw6u9VR6JkgLFDqNlE15X1DsmioCUhu2ai7N7fh26Z8l5MgvTn2C/ck/t8oUebggrsftV/93mWrWszm4tdHPoQBBnruWdCC9MVJxL0LyeM7J7rs6TE+AYj9nP2STp4UbwiaoG7AoRY+6dmErabIJhJf51OfkydmTPJ3c+eK9i+aoqM0X7Q+Gd3FW2OGSO7Q4ifMjzuKYv5LXnHRgu9hiC5bS5VTDlx4mAh3/DpFWHZAQjogxYzkoAnBH73/X7mw6Gp9b9IVMt5xYPcQd9+wNjmis+P/q5BHCIIrHK+vKr6lBJygZ3Hk78NZplDflE4famkJJ3mVGq/hL1ctsuShnsRdOc4sLw/HZgyWTrWijat7/Iehpwr5vwLfd+F7RnhbzTPqfurEr9hT9FAYh8WiuL7wqZmXUMYittb9Xuotffuzkw9TmngVR5I1Sd8tlOUEJk3z4wMEJMfdMJTADNqtY8EIA9t1h611dfKWPEClOwioOhtAyTBs6EeSnerVAOo62YMmhwiq9+S9cGn+VeVWqPS71ecYxncg5qrv87uIqAjMGGK0UmPtfmvy/I4IjV3CTFjKJ4n2KcIASkE7AAp7/jbuDrDf9sD5c7hR2nY2+yqwA1zg= X-OriginatorOrg: ece.iisc.ernet.in X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2017 04:53:12.5659 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MAXPR01MB0185 Archived-At: Subject: [Roll] AODV-RPL : unknown link state 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, 18 Jul 2017 04:59:24 -0000 Dear AODV-RPL authors, First of all I want to thank authors of this draft as it is useful in ad hoc  and  on-demand  routing cases.  I am implementing AODV-RPL in Contiki OS. During implementation, I am facing a situation where a node has no way of determining the bi-directional state of its peering link, symmetric or  asymmetric, at the time of path establishment. The reason being, there was no data transferred  earlier over the link between the sender and receiver of RREQ message. This is  especially true when the network has freshly come up and AODV-RPL session was initiated, and the network is not sufficiently warmed up. The question is, should we treat the lack of knowledge about the bi-directional link state as symmetric or asymmetric ? When encountered with this situation, the current implementation optimistically treats the link as symmetric, by default. But then, if the link actually turns out to exhibit asymmetric behavior once the data starts flowing, what should the protocol do ? In the current specification, we don't have a provision for re-initiating or modifying a P2P connection once it is set up. Let me know your thoughts on this. Any recommendation on assigning life time for routes? Regards, Lavanya H M From nobody Tue Jul 18 01:19:13 2017 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 45516131A50; Tue, 18 Jul 2017 01:19:11 -0700 (PDT) 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 6w5l_tULN2-v; Tue, 18 Jul 2017 01:19:10 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 D8F1E131A4F; Tue, 18 Jul 2017 01:19:09 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k71so9491666iod.2; Tue, 18 Jul 2017 01:19:09 -0700 (PDT) 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=TxjiGm1ovBikFyWd6z0Oh1nlB4/PznxR3uiWgTEY7aE=; b=rMS3kFIRghwN1Rx2NkJMfrbW5O0CGOFYSD+TkK7r1Ww4balaSMb07RIpGzsmy6mhQ1 ZA+qaR+mHS4a7urrTHOCGLbINTYHtiuCxfXj55ukkpoIfrWUh2SSSEijvvmfUaCwsrf/ fE1cOqT2FSrtuWv/4XRJUpF3lh1KZkOiPwjnH7R7qnvpH358aBQcOHRpBXSaznBxltZm x/VvaVbaOitePci6KaYnda1xocFx2E7ZKp34h+J/IlJEbHA0EvGP0NYdkY+vmJ5lnEDy YdwtoYlvlPbGiQ3/VMImRCyCC7W6f9FbUru7kmyjSG2NFIL3ptseXOPYrDD2FuScGYK+ X6Uw== 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=TxjiGm1ovBikFyWd6z0Oh1nlB4/PznxR3uiWgTEY7aE=; b=bX1uGDRGZM+rw/POPucj/3XOIuApbQAfA31tJjstBAaXTpC9p2ou21hTR9e19eucLb Jio5qN+Y46ogyDULtvnX2nKTDRy6IfPwY2noES6w4Ag/QJad7Fq28v1ysBo6UgWoCE8b vrtw56Yzb+i7q9eEvtynrBehQgES2xIU95A8EqVmSHnDNFzm4ewlqdas39xBeYOaRnp4 ayvMDVXXt4EDG9pc5B8n5IYlRI2vGsXmkTRzo9t3S/lUnerH90W1uI3QYdHnmBPnmBpk myPukhJmwPn28UItMKxq/FhoYTVM+58GaNgQV2M4R4iWE1fOfDiB1gEINaNZpociWWMj Y2ig== X-Gm-Message-State: AIVw1106x64pWAEZqumVIeNeB6+MDFlN1ub07tsW7niGFkozsu1MD6BG ETIpEhhWXI9aPBZ2kF/zlgcsoGCYRiD1 X-Received: by 10.107.179.135 with SMTP id c129mr497377iof.74.1500365948958; Tue, 18 Jul 2017 01:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 18 Jul 2017 01:19:08 -0700 (PDT) From: Ines Robles Date: Tue, 18 Jul 2017 10:19:08 +0200 Message-ID: To: roll , "6tisch@ietf.org" <6tisch@ietf.org> Cc: Michael Richardson Content-Type: multipart/alternative; boundary="001a114853be6bc6650554932b00" Archived-At: Subject: [Roll] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 18 Jul 2017 08:19:11 -0000 --001a114853be6bc6650554932b00 Content-Type: text/plain; charset="UTF-8" Dear all, Yesterday at 6tisch meeting was suggested to add this document, https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 as an Appendix section in useofrplinfo draft. We would like to know your opinion on that, - Should we add this draft as an appendix? or - Should this draft be presented in lwig? or - Additional Suggestions? Thank you, The authors. --001a114853be6bc6650554932b00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Yesterday at 6tisc= h meeting was suggested to add this document,


=
as an Appendix section in useofrplinfo draft.=C2=A0

We would like to know your opinion on that,=C2=A0

- Should we add this draft as an appendix? or

- Should this draft be presented in lwig? or

- = Additional Suggestions?

Thank you,

<= /div>
The authors.
--001a114853be6bc6650554932b00-- From nobody Tue Jul 18 01:30:30 2017 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 E57D5131D2B for ; Tue, 18 Jul 2017 01:30:22 -0700 (PDT) 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=unavailable 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 aFUU969AbxNV for ; Tue, 18 Jul 2017 01:30:20 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA21120227 for ; Tue, 18 Jul 2017 01:30:18 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud3.xs4all.net with ESMTP id m8W71v00v5LLN1B018W8eh; Tue, 18 Jul 2017 10:30:14 +0200 Received: from 2001:67c:1232:144:9016:6f55:5e12:75b8 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 10:30:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 10:30:07 +0200 From: peter van der Stok To: Ines Robles Cc: roll , 6tisch@ietf.org, Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 18 Jul 2017 08:30:23 -0000 Hi Ines, I don't see the relation between the examples and the rplinfo draft. RPLinfo is about routes through the DODAG and the use of IP-in-IP and RPI. The examples do not reflect that topic in my opinion. Peter Ines Robles schreef op 2017-07-18 10:19: > Dear all, > > Yesterday at 6tisch meeting was suggested to add this document, > > https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 > > as an Appendix section in useofrplinfo draft. > > We would like to know your opinion on that, > > - Should we add this draft as an appendix? or > > - Should this draft be presented in lwig? or > > - Additional Suggestions? > > Thank you, > > The authors. > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Tue Jul 18 01:52:59 2017 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 7BD5B131A78 for ; Tue, 18 Jul 2017 01:52:56 -0700 (PDT) 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 A3FQ7fqI5sdo for ; Tue, 18 Jul 2017 01:52:54 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A65131A7E for ; Tue, 18 Jul 2017 01:52:54 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:209]) by smtp-cloud2.xs4all.net with ESMTP id m8ss1v00C208vl0018sstS; Tue, 18 Jul 2017 10:52:52 +0200 Received: from dhcp-9b3f.meeting.ietf.org ([31.133.155.63]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 10:52:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 18 Jul 2017 10:52:33 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] rplinfo 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, 18 Jul 2017 08:52:56 -0000 Hi all, I had a quick look through the RPLinfo document. The text has considerably improved since the last 2 versions. For me less reasoning was needed to understand what was going on. I did not check all the individual tables. I appreciated the larger security considerations section. The considerations about the effect of RPI on non RPL aware nodes has been clarified. Below some of my comments (typos and other comments mixed); hope they help Peter _____________________________________________________________________________________________________ Page 4; this document clarifIES section 2 ; RPL-not-capable : …..which DOES not… section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It can be a neighbour of a DODAG node but not a leaf in my understanding section 3.1 I don’t understand the following text “This ensures that a packet that leaves the RPL domain of an LLN (or that leaves the LLN entirely) will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop option known as RPI.†How can a change to an RPL option field have a consequence for a not-RPL-aware node? The only thing a change to the option field can do is that the treatment by rpl-aware and not-aware nodes is the same. Page 6; We propose -> the document proposes. Section 4 page 7, A “new†ICMP message, propose to remove “new†Page 7, “or an in non-storing†suggest to remove “an†Figures 5 and 6 are referenced as figures 1 and 2 Figure 2(6) In my understanding Raf 6LN are leaves of the DODAG and ~RAF 6LN are not leaves but are part of the lowpan network to which the DODAG nodes belong as well. Using the concept of lowpan network (LLN) and subset that forms a DODAG may help the explanation. Also the term “RPL Domain†is used; is that equivalent to DODAG? Suggest to use only one term and explain it. Section 5 “This document also describe†-> describes Section 5 “hte LLN†->the Section 5 “We describe also how is the communication inside of the LLN†-> We also describe the communication inside the LLN (I stop noting typos from here) Page 11: “leaves the LLN entirely†what does that mean? LLN is not well defined Page 11: “ NOTE: There is some possible security risk when the RPI information is released to the Internet. At this point this is a theoretical situation.†Suggest to remove this phrase and add this point to security considerations page 11: “be placed is placed†twice placed Page 12 “so an IPsec AH security header can be applied across these headers, but it can not secure the values which mutate.†Not sure that I understand. I read: You can encrypt the header but not some of the values. Is that meant? How does the encryption algorithm know which values not to touch? Section 6 first sentence “inside the LLN†is that inside the DODAG? Page 13: Figure 6? Is unreadable. Section 6.1.1 “1 <= i >= n†<= n (and at other places) Why is the row “Re-added headers†necessary in the table? In all tables that I checked no node re-adds headers. Section 11, “RPL root†-> DODAG root ? -- Peter van der Stok From nobody Tue Jul 18 01:59:22 2017 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 30813131DC2 for ; Tue, 18 Jul 2017 01:59:21 -0700 (PDT) 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 kmKghXHC8KUk for ; Tue, 18 Jul 2017 01:59:18 -0700 (PDT) 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 428AD12009C for ; Tue, 18 Jul 2017 01:59:18 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id z62so10204027ioi.3 for ; Tue, 18 Jul 2017 01:59:18 -0700 (PDT) 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; bh=64XMUgEeFPrq4BddSyf1ZQ/Et6UntOS/jV5cYftGHOw=; b=pOQd2d7Nt+BXvtwN4yR5Zy0AaxnEoBXCFjDYRxW/h4NDhpEq5HAIw8tlhogCUHeCSz 8HfskT7o2nNMW4hSTDOAkdi3lZy80vz6g5QfDSXYhPkReEAtb1fKySlqn7X1NBmwD1UE 5BrxOf9F23flzM/5FfIf0NtrSXcc1u8EkMYrCfA24ctLBrj1/2lq7Aj7QVmIxN4Dm4Cf rZhnj640A2RrAaFNAtcacDtu9LczHwdwjHmH40pCtBYnPabsdGe1264sEq9T4dYmlIJy alwA+gOUReYS2L+kkfu9tOVBPrJiF4hIXHaZjdo3ILRdapGTSA/Yw/cJ5laC3LW1io/c 0Unw== 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=64XMUgEeFPrq4BddSyf1ZQ/Et6UntOS/jV5cYftGHOw=; b=Pt4I3P6fvn+2vpWUgbGBbvBA3Hr1lDDZGHorH2d1pZRXzZpwygLkhshsHZuE/U63wu n3JM1419bR7QqMo/eHDx/zKpvAsNhzXHHgRy3k/lMiCj3r2KOkwhMnp3R5aEamPrGlC2 VU02nz/7vifkT2l7HcgisSYWqV9US6nyakCPjvxdw7RTEpHnJIWjVf56rPq9VAsoPyFI lsTX4lkewRyJXGN23/Nxeo97HZs307Y+sIh1Rr7+DAaoKlT48WmupsVYe0lkg7111O81 nnORL5VNxFzD44xrx4bQBS+ehFwO0FqFjkRRPMQGYgt6LVoqIThQuvs1Dd08/peXNhQ2 fFzA== X-Gm-Message-State: AIVw112+k/6V5aymzCDiyD5n8eO/dBWglLSzc/oPpgwPsTBpYx8q/QuC rlRVRP4S3Mu1mzBvmtWjq+psQ2xEkw== X-Received: by 10.107.152.85 with SMTP id a82mr487003ioe.105.1500368357531; Tue, 18 Jul 2017 01:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 18 Jul 2017 01:59:17 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Tue, 18 Jul 2017 10:59:17 +0200 Message-ID: To: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a11454732fbb2a5055493babc" Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 08:59:21 -0000 --001a11454732fbb2a5055493babc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Peter, ticket 183 was created to track this. [ https://trac.ietf.org/trac/roll/ticket/183#ticket] Cheers, Ines. 2017-07-18 10:52 GMT+02:00 peter van der Stok : > Hi all, > > I had a quick look through the RPLinfo document. > The text has considerably improved since the last 2 versions. For me less > reasoning was needed to understand what was going on. I did not check all > the individual tables. I appreciated the larger security considerations > section. > The considerations about the effect of RPI on non RPL aware nodes has bee= n > clarified. > Below some of my comments (typos and other comments mixed); hope they hel= p > > Peter > > ____________________________________________________________ > _________________________________________ > > Page 4; this document clarifIES > section 2 ; RPL-not-capable : =E2=80=A6..which DOES not=E2=80=A6 > section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It ca= n > be a neighbour of a DODAG node but not a leaf in my understanding > section 3.1 I don=E2=80=99t understand the following text =E2=80=9CThis e= nsures that a > packet that > leaves the RPL domain of an LLN (or that leaves the LLN entirely) > will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop > option known as RPI.=E2=80=9D > How can a change to an RPL option field have a consequence for a > not-RPL-aware node? The only thing a change to the option field can do is > that the treatment by rpl-aware and not-aware nodes is the same. > Page 6; We propose -> the document proposes. > Section 4 page 7, A =E2=80=9Cnew=E2=80=9D ICMP message, propose to remove= =E2=80=9Cnew=E2=80=9D > Page 7, =E2=80=9Cor an in non-storing=E2=80=9D suggest to remove =E2=80= =9Can=E2=80=9D > Figures 5 and 6 are referenced as figures 1 and 2 > Figure 2(6) In my understanding Raf 6LN are leaves of the DODAG and ~RAF > 6LN are not leaves but are part of the lowpan network to which the DODAG > nodes belong as well. Using the concept of lowpan network (LLN) and subse= t > that forms a DODAG may help the explanation. > Also the term =E2=80=9CRPL Domain=E2=80=9D is used; is that equivalent to= DODAG? Suggest > to use only one term and explain it. > Section 5 =E2=80=9CThis document also describe=E2=80=9D -> describes > Section 5 =E2=80=9Chte LLN=E2=80=9D ->the > Section 5 =E2=80=9CWe describe also how is the communication inside of th= e LLN=E2=80=9D -> > We also describe the communication inside the LLN > (I stop noting typos from here) > Page 11: =E2=80=9Cleaves the LLN entirely=E2=80=9D what does that mean? L= LN is not well > defined > Page 11: =E2=80=9C NOTE: There is some possible security risk when the = RPI > information > is released to the Internet. At this point this is a theoretical > situation.=E2=80=9D > Suggest to remove this phrase and add this point to security consideratio= ns > > page 11: =E2=80=9Cbe placed is placed=E2=80=9D twice placed > Page 12 =E2=80=9Cso an IPsec AH security header can be > applied across these headers, but it can not secure the values which > mutate.=E2=80=9D > Not sure that I understand. I read: You can encrypt the header but not > some of the values. Is that meant? How does the encryption algorithm know > which values not to touch? > > Section 6 first sentence =E2=80=9Cinside the LLN=E2=80=9D is that inside = the DODAG? > Page 13: Figure 6? Is unreadable. > Section 6.1.1 =E2=80=9C1 <=3D i >=3D n=E2=80=9D <=3D n (and at other plac= es) > Why is the row =E2=80=9CRe-added headers=E2=80=9D necessary in the table?= In all tables > that I checked no node re-adds headers. > Section 11, =E2=80=9CRPL root=E2=80=9D -> DODAG root ? > > > -- > Peter van der Stok > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11454732fbb2a5055493babc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Peter,=C2=A0

ticket 183 was c= reated to track this. [https://trac.ietf.org/trac/roll/ticket/183#ticket]
=
Cheers,

Ines.

2017-07-18 10:52 GMT+02:00 peter va= n der Stok <stokcons@xs4all.nl>:
Hi all,

I had a quick look through the RPLinfo document.
The text has considerably improved since the last 2 versions. For me less r= easoning was needed to understand what was going on. I did not check all th= e individual tables. I appreciated the larger security considerations secti= on.
The considerations about the effect of RPI on non RPL aware nodes has been = clarified.
Below some of my comments (typos and other comments mixed); hope they help<= br>
Peter

_________________________________________________________________= ____________________________________

Page 4; this document clarifIES
section 2 ; RPL-not-capable : =E2=80=A6..which DOES not=E2=80=A6
section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It can = be a neighbour of a DODAG node but not a leaf in my understanding
section 3.1 I don=E2=80=99t understand the following text =E2=80=9CThis ens= ures that a packet that
=C2=A0 =C2=A0leaves the RPL domain of an LLN (or that leaves the LLN entire= ly)
=C2=A0 =C2=A0will not be discarded when it contains the [RFC6553] RPL Hop-b= y-Hop
=C2=A0 =C2=A0option known as RPI.=E2=80=9D
How can a change to an RPL option field have a consequence for a not-RPL-aw= are node? The only thing a change to the option field can do is that the tr= eatment by rpl-aware and not-aware nodes is the same.
Page 6; We propose -> the document proposes.
Section 4 page 7, A =E2=80=9Cnew=E2=80=9D ICMP message, propose to remove = =E2=80=9Cnew=E2=80=9D
Page 7, =E2=80=9Cor an in non-storing=E2=80=9D suggest to remove =E2=80=9Ca= n=E2=80=9D
Figures 5 and 6 are referenced as figures 1 and 2
Figure 2(6) In my understanding Raf 6LN are leaves of the DODAG and ~RAF 6L= N are not leaves but are part of the lowpan network to which the DODAG node= s belong as well. Using the concept of lowpan network (LLN) and subset that= forms a DODAG may help the explanation.
Also the term =E2=80=9CRPL Domain=E2=80=9D is used; is that equivalent to D= ODAG? Suggest to use only one term and explain it.
Section 5 =E2=80=9CThis document also describe=E2=80=9D -> describes
Section 5 =E2=80=9Chte LLN=E2=80=9D ->the
Section 5 =E2=80=9CWe describe also how is the communication inside of the = LLN=E2=80=9D -> We also describe the communication inside the LLN
(I stop noting typos from here)
Page 11: =E2=80=9Cleaves the LLN entirely=E2=80=9D what does that mean? LLN= is not well defined
Page 11: =E2=80=9C=C2=A0 =C2=A0NOTE: There is some possible security risk w= hen the RPI information
=C2=A0 =C2=A0is released to the Internet.=C2=A0 At this point this is a the= oretical
=C2=A0 =C2=A0situation.=E2=80=9D
Suggest to remove this phrase and add this point to security considerations=

page 11: =E2=80=9Cbe placed is placed=E2=80=9D twice placed
Page 12 =E2=80=9Cso an IPsec AH security header can be
=C2=A0 =C2=A0applied across these headers, but it can not secure the values= which
=C2=A0 =C2=A0mutate.=E2=80=9D
=C2=A0Not sure that I understand. I read: You can encrypt the header but no= t some of the values. Is that meant? How does the encryption algorithm know= which values not to touch?

Section 6 first sentence =E2=80=9Cinside the LLN=E2=80=9D is that inside th= e DODAG?
Page 13: Figure 6? Is unreadable.
Section 6.1.1 =E2=80=9C1 <=3D i >=3D n=E2=80=9D <=3D n (and at oth= er places)
Why is the row =E2=80=9CRe-added headers=E2=80=9D necessary in the table? I= n all tables that I checked no node re-adds headers.
Section 11, =E2=80=9CRPL root=E2=80=9D -> DODAG root ?


--
Peter van der Stok

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

--001a11454732fbb2a5055493babc-- From nobody Tue Jul 18 02:36:52 2017 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 13B3E131945; Tue, 18 Jul 2017 02:36:51 -0700 (PDT) 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, 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 67k89wSbu0EY; Tue, 18 Jul 2017 02:36:49 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A916126E3A; Tue, 18 Jul 2017 02:36:49 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-8110.meeting.ietf.org [31.133.129.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 622411F8EE; Tue, 18 Jul 2017 09:36:47 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6ABEE2C7F; Tue, 18 Jul 2017 11:36:39 +0200 (CEST) From: Michael Richardson To: roll , 6tisch@ietf.org In-reply-to: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Tue, 18 Jul 2017 10:30:07 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 18 Jul 2017 11:36:39 +0200 Message-ID: <19776.1500370599@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 18 Jul 2017 09:36:51 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > I don't see the relation between the examples and the rplinfo draft. > RPLinfo is about routes through the DODAG and the use of IP-in-IP and > RPI. The examples do not reflect that topic in my opinion. >> https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 This document is a set of examples packets using RPL and 6tisch. Section 3.6 includes packets from the data plane that are 6loRH compressed. The examples do not include very much of useofrplinfo examples, but the idea would be to include such packets. I'm not sure what we would do with the beacons and other L2 examples. Maybe this was a poor idea in the end. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZbdanAAoJEJVM4Vb9/EKQhmYH/1zJr5wa2c/p/C++GUe7faPE vBEB0VJkKK/Sa81kqgRbDYRmOmft4cqF7NvWz6FAzmw32zZ83QamsiS4QOgL37Lr Orlo6fBMHI0sIObdRDYizm2CWe+N4u69qGTuGElQYrnhSzanWxH1R6qhenelH583 kORvG9EuI1ZYfc0Py6qu7i8cXLvEGs4D5HzrB9bAup6inBM3SLcmO0SAeVLqpu98 m5dwkViPTzXoMhpUTpk72ZD1euCJMIrU4wcFljjhEqcOCmKQLoDo3SGTYAAnTz93 fn5eujxzFwN276/qjLO+C1fdGWEzYwtDcpgxkGHaBUoxwmxRTgiZZVoMd5WUTTY= =fpE9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 18 04:15:16 2017 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 D9E68131667 for ; Tue, 18 Jul 2017 04:15:13 -0700 (PDT) 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 BZR6WY8oE5x8 for ; Tue, 18 Jul 2017 04:15:11 -0700 (PDT) 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 9F480131471 for ; Tue, 18 Jul 2017 04:15:11 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k71so11416542iod.2 for ; Tue, 18 Jul 2017 04:15:11 -0700 (PDT) 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; bh=NY7kRUrkraPfsS/WV7AbI8wB4QSmc4VwmboukPi6W08=; b=CxAMrixoTwfxQesHdqvjMWYcgCD67hL+NSwsg+eEcA3nBnqI1jrzOaDZwRoaLu5nQl Ahrk5CH88+waDFZ6S2RiD80Gg+AMMza7sUXmDsTVzfZKZNf6jGop7o+eOecseKNuLTgG 6Z3Euyj55KAXhzNBhwn6IaFggsMQtw1hILe73ZO/W3zucmmwFmwurStNxHZOonGdlE7X GIt/7qbfrcfunz5q7EONFfdTPYsTa/xkW/y8s0tx5TeicMUZurVaIjppbj6C6L88ZIo+ /nvIFJq/QNPTBsmTxoZIVwb9G+sc8ej8JZhCcNbRERkO05oRD7KGEScpYC8hTbKXIoMx 01Vw== 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=NY7kRUrkraPfsS/WV7AbI8wB4QSmc4VwmboukPi6W08=; b=Qql85Qhnrowl/6t3CHtnZk/quOA6LmjISD7oysW3mb4QwyG1pOQFt5FsV7VfV7zT0l b1jMNN+KTapEv4tjglt/y5OBItJN6ZMYqnvH+/yeEUWpw8O+cYxNtieRKKpKawc+raLm GnyG/T61yDA/UptLv48GBsACFBusuf/ovGn2HtWIwBpXTNntDVlA8+4kqLwZpwIe9CfY ZroxYn1ajnfYQlGvQRI3RsxDsQofkTxsQvsGlYcEqRGm5oqCo8wmwTgN58TfcAjGvAMA +yiR/UV2SQIXybQjXXjoXLUhKXt/dkDywFKNDHvBEioaA/ciNGvf+jVqHRk7jNBGmBCd v7XQ== X-Gm-Message-State: AIVw112a9RXEqd5ftqkPVo+TnC2zA0H7vlhtzBy4qrX5zMtu+s0mj6zM LAgEgmARutItih2E2txWmj+21pUe9w== X-Received: by 10.107.152.85 with SMTP id a82mr980302ioe.105.1500376510901; Tue, 18 Jul 2017 04:15:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 18 Jul 2017 04:15:10 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Tue, 18 Jul 2017 13:15:10 +0200 Message-ID: To: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a11454732f63d5b055495a032" Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 11:15:14 -0000 --001a11454732f63d5b055495a032 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Peter for your suggestions/corrections. Please find some comments bellow. 2017-07-18 10:52 GMT+02:00 peter van der Stok : > section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It ca= n > be a neighbour of a DODAG node but not a leaf in my understanding > I understand that we can have it. Please someone correct me if I am wrong. RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: - A leaf node (only) does not ever participate as a RPL router. - Support of a particular MOP encoding is not required - Support of a particular OF is not required. - A leaf node does not generally issue DIO messages, - it may issue DAO and DIS messages. A leaf node accepts DIO messages though it generally ignores DAO and DIS messages (not applied in our case) > section 3.1 I don=E2=80=99t understand the following text =E2=80=9CThis e= nsures that a > packet that > leaves the RPL domain of an LLN (or that leaves the LLN entirely) > will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop > option known as RPI.=E2=80=9D > How can a change to an RPL option field have a consequence for a > not-RPL-aware node? The only thing a change to the option field can do is > that the treatment by rpl-aware and not-aware nodes is the same. > The RPI is carried within the IPv6 Hop-by-Hop header. Processing of the Hop-by-Hop Options header (by IPv6 intermediate nodes) is now optional, but if nodes (not-rpl-aware) are configured to process the header, and if such nodes encounter an option with the first two bits set to 01 (RPI), they will drop the packet. > Figure 2(6) In my understanding Raf 6LN are leaves of the DODAG and ~RAF > 6LN are not leaves but are part of the lowpan network to which the DODAG > nodes belong as well. Using the concept of lowpan network (LLN) and subse= t > that forms a DODAG may help the explanation. > Ok, This is related with a previous comment above. > Also the term =E2=80=9CRPL Domain=E2=80=9D is used; is that equivalent to= DODAG? Suggest > to use only one term and explain it. > Ok, thanks, we are going to clarify those terms in text. In Figure 2 we are using the meaning for RPL domain, not equivalent to DODAG: RPL Domain: A collection of RPL routers under the control of a single administration. The boundaries of routing domains are defined by network management by setting some links to be exterior, or inter- domain, links. [RFC 7102] Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root (the DODAG root) with no outgoing edges.[RFC 6550] > Page 11: =E2=80=9Cleaves the LLN entirely=E2=80=9D what does that mean? L= LN is not well > defined > Ok, we will explain that better. >From Figure 5, it means e.g. go out of the RPL domain, in this case go to the Internet. > Page 11: =E2=80=9C NOTE: There is some possible security risk when the = RPI > information > is released to the Internet. At this point this is a theoretical > situation.=E2=80=9D > Suggest to remove this phrase and add this point to security consideratio= ns > Ok, > > Page 12 =E2=80=9Cso an IPsec AH security header can be > applied across these headers, but it can not secure the values which > mutate.=E2=80=9D > Not sure that I understand. I read: You can encrypt the header but not > some of the values. Is that meant? Yes. How does the encryption algorithm know which values not to touch? > Have to check this. > Section 6 first sentence =E2=80=9Cinside the LLN=E2=80=9D is that inside = the DODAG? > I would say here, inside the RPL Domain. Page 13: Figure 6? Is unreadable. > Ok, we will add more clarification here. > Section 6.1.1 =E2=80=9C1 <=3D i >=3D n=E2=80=9D <=3D n (and at other plac= es) > Why is the row =E2=80=9CRe-added headers=E2=80=9D necessary in the table?= In all tables > that I checked no node re-adds headers. > Section 11, =E2=80=9CRPL root=E2=80=9D -> DODAG root ? We will check it. Thank you again. Ines. > > > > -- > Peter van der Stok > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11454732f63d5b055495a032 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Peter for your suggestions/corrections.=C2=A0
Please find some comments bellow.

2017-07-18 10:52 GMT+02:00 peter van= der Stok <stokcons@xs4all.nl>:
section 2, rpl-not-capable; how can this node be = a leaf of a DODAG. It can be a neighbour of a DODAG node but not a leaf in = my understanding

I understand that= we can have it. Please someone correct me if I am wrong.

RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only:
<= br>
=C2=A0- A leaf node (only) does not ever participate as a RPL= router.=C2=A0

=C2=A0- Support of a particular MOP= encoding is not required

=C2=A0- Support of a par= ticular OF is not required.

=C2=A0- =C2=A0A leaf n= ode does not generally issue DIO messages,

=C2=A0-= it may issue DAO and DIS messages.=C2=A0 A leaf node accepts DIO messages = though it generally ignores DAO and DIS messages =C2=A0(not applied in our = case)

=C2=A0
section 3.1 I don=E2=80=99t understand the following text =E2=80=9CThis ens= ures that a packet that
=C2=A0 =C2=A0leaves the RPL domain of an LLN (or that leaves the LLN entire= ly)
=C2=A0 =C2=A0will not be discarded when it contains the [RFC6553] RPL Hop-b= y-Hop
=C2=A0 =C2=A0option known as RPI.=E2=80=9D
How can a change to an RPL option field have a consequence for a not-RPL-aw= are node? The only thing a change to the option field can do is that the tr= eatment by rpl-aware and not-aware nodes is the same.
=
The RPI is carried within the IPv6 Hop-by-Hop header. Proces= sing of the Hop-by-Hop Options header (by IPv6 intermediate nodes) is now o= ptional, but if nodes (not-rpl-aware) are configured to process the header,= and if such nodes encounter an option with the first two bits set to 01 (R= PI), they will drop the packet.
=C2=A0
Figure 2(6) In my understanding Raf 6LN are le= aves of the DODAG and ~RAF 6LN are not leaves but are part of the lowpan ne= twork to which the DODAG nodes belong as well. Using the concept of lowpan = network (LLN) and subset that forms a DODAG may help the explanation.

Ok, This is related with a previous comment = above.
=C2=A0
Also the term =E2=80=9CRPL Domain=E2=80=9D is used; is that equivalent to D= ODAG? Suggest to use only one term and explain it.
Ok, thanks, we are going to clarify those terms in text. I= n Figure 2 we are using the meaning for RPL domain, not equivalent to DODAG= :=C2=A0

RPL Domain: A collection of RPL routers un= der the control of a single
=C2=A0 =C2=A0 =C2=A0 administration.= =C2=A0 The boundaries of routing domains are defined by
=C2=A0 = =C2=A0 =C2=A0 network management by setting some links to be exterior, or i= nter-
=C2=A0 =C2=A0 =C2=A0 domain, links. [RFC 7102]
Destination-Oriented DAG (DODAG): A DAG rooted at a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destination, i.e., at a single DAG= root (the DODAG root) with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no = outgoing edges.[RFC 6550]

=C2=A0
Page 11: =E2=80=9Cleaves the LL= N entirely=E2=80=9D what does that mean? LLN is not well defined

Ok, we will explain that better.=C2=A0
=
From Figure 5, it means e.g. go out of the RPL domain, in th= is case go to the Internet.
=C2=A0
Page 11: =E2=80=9C=C2=A0 =C2=A0NOTE: There is some possible security risk w= hen the RPI information
=C2=A0 =C2=A0is released to the Internet.=C2=A0 At this point this is a the= oretical
=C2=A0 =C2=A0situation.=E2=80=9D
Suggest to remove this phrase and add this point to security considerations=

Ok,=C2=A0

Page 12 =E2=80=9Cso an IPsec AH security header can be
=C2=A0 =C2=A0applied across these headers, but it can not secure the values= which
=C2=A0 =C2=A0mutate.=E2=80=9D
=C2=A0Not sure that I understand. I read: You can encrypt the header but no= t some of the values. Is that meant?
=C2=A0
Yes.= =C2=A0


Section 6 first sentence =E2=80=9Cinside the LLN=E2=80=9D is that inside th= e DODAG?

I would say here, inside the R= PL Domain.=C2=A0

Page 13: Figure 6? Is unreadable.

Ok, w= e will add more clarification here.
=C2=A0
Section 6.1.1 =E2=80=9C1 <=3D i >=3D n=E2=80=9D <=3D n (and at oth= er places)
Why is the row =E2=80=9CRe-added headers=E2=80=9D necessary in the table? I= n all tables that I checked no node re-adds headers.
Section 11, =E2=80=9CRPL root=E2=80=9D -> DODAG root ?
=
We will check it.

Thank you again.<= /div>

Ines.=C2=A0



--
Peter van der Stok

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

--001a11454732f63d5b055495a032-- From nobody Tue Jul 18 04:23:44 2017 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 C0DC8131471 for ; Tue, 18 Jul 2017 04:23:42 -0700 (PDT) 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 v_9YbgT5h77X for ; Tue, 18 Jul 2017 04:23:41 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5406D1317C3 for ; Tue, 18 Jul 2017 04:23:41 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id mBPf1v0040F6qFb01BPf7R; Tue, 18 Jul 2017 13:23:39 +0200 Received: from 2001:67c:370:128:4a7:3504:ae1d:4449 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 13:23:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 13:23:39 +0200 From: peter van der Stok To: Ines Robles Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 11:23:43 -0000 >> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >> It can be a neighbour of a DODAG node but not a leaf in my >> understanding > > I understand that we can have it. Please someone correct me if I am > wrong. > > RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: > > - A leaf node (only) does not ever participate as a RPL router. > > - Support of a particular MOP encoding is not required > > - Support of a particular OF is not required. > > - A leaf node does not generally issue DIO messages, > > - it may issue DAO and DIS messages. A leaf node accepts DIO > messages though it generally ignores DAO and DIS messages (not > applied in our case) > A leaf node accepts DIO messages and is thus RPL-aware in my understanding; Peter From nobody Tue Jul 18 04:32:33 2017 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 7B93713178E for ; Tue, 18 Jul 2017 04:32:31 -0700 (PDT) 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 W2f6a8FIiVN0 for ; Tue, 18 Jul 2017 04:32:29 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 A9168131A7B for ; Tue, 18 Jul 2017 04:32:29 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 5so11313573iow.0 for ; Tue, 18 Jul 2017 04:32:29 -0700 (PDT) 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=xXxTHzMZdZO6UrsZT/nW8JYtcklBGTzvZ8bYsMcs9Og=; b=fUJvWJxI5E9LLEjgR7CSx8bMvDespRYyFJtChwgTTBpLnMqauux/FbbsFGwVAK7LKB hKMQ6o0xux773MaNGmbT7EUCjLePFBSE7A8HrlcvsrwbTN2vk7M7BftO4kUVNRJIIhcJ LCCt8IeKKK+n+y0nFuBXUN3833ZSnJiR4tuQPvLC4+GWePNR8c9dL5VN7lkybUUnIOK2 Pp6vAGTGaCinGP2KtRG11KLREMqO5bVbf0OCSujzhYzJ/fy7RB3aon2ly/fnBRADBfaJ q/t0Yd6hqcq5xXVLmUv/YIUzu+KUpCz39Khba6yE6qYXjzDgCCcQNEkACIlo1oQLk81W JzLg== 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=xXxTHzMZdZO6UrsZT/nW8JYtcklBGTzvZ8bYsMcs9Og=; b=Q+AB0uKX0pVlp0MHWtFUI1UCNhMQrW9i4afb33BNsuEgZgjCdTyHb7mp6mzyaOKUS2 NVMAV4ib5vYUloi/PgLj5o5o5JTaU9RIpvdQKHIbZ76SkQs1u/hiyVoqvX6Kpxvv80b+ gcvvnMOb7pGflT4eEZLI+nUKDc77nPIxVxG5ElXSATTHBUYaHn+GPq4yTYQGM/NSn+Zn hE1bVTgpO+jOnFLbSOmSRSxSagjelpyPDwcU4r7eoNqqiEwfwejDK8uBX2Vx5YkVHz24 I0k4FxdsTpT0MG5T7wJvVdN9NYDuaHYYJjc66H+VeZTA/N5r63pgrrbKXeCx1qrpOcte dBvA== X-Gm-Message-State: AIVw110UjlCog5KkcNUNnM+RvcuSDKr19nOrhx3pbUesGo8m9UbuQVHc N/bcw8G9qOUW9SB2AcjGOJEHC27rUUAX X-Received: by 10.107.135.217 with SMTP id r86mr982585ioi.3.1500377548977; Tue, 18 Jul 2017 04:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 18 Jul 2017 04:32:28 -0700 (PDT) In-Reply-To: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> From: Ines Robles Date: Tue, 18 Jul 2017 13:32:28 +0200 Message-ID: To: "consultancy@vanderstok.org" Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a113fbf90d5fea1055495de5d" Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 11:32:31 -0000 --001a113fbf90d5fea1055495de5d Content-Type: text/plain; charset="UTF-8" Yes, agree. So, could we have a case where the leaf nodes do not accept DIO Messages like in the use cases? Maybe we should define the features with more detail of a not-RPL-aware-leaf in the document. 2017-07-18 13:23 GMT+02:00 peter van der Stok : > > section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >>> It can be a neighbour of a DODAG node but not a leaf in my >>> understanding >>> >> >> I understand that we can have it. Please someone correct me if I am >> wrong. >> >> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >> >> - A leaf node (only) does not ever participate as a RPL router. >> >> - Support of a particular MOP encoding is not required >> >> - Support of a particular OF is not required. >> >> - A leaf node does not generally issue DIO messages, >> >> - it may issue DAO and DIS messages. A leaf node accepts DIO >> messages though it generally ignores DAO and DIS messages (not >> applied in our case) >> >> > A leaf node accepts DIO messages and is thus RPL-aware in my understanding; > > Peter > --001a113fbf90d5fea1055495de5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, agree.

So, coul= d we have a case where the leaf nodes do not accept DIO Messages like in th= e use cases?

Maybe we should define the features with more detail of a = not-RPL-aware-leaf in the document.

2017-07-18 13:23 GMT+02:00 pete= r van der Stok <stokcons@xs4all.nl>:

section 2, rpl-not-capable; how can this node be a leaf of a DODAG.
It can be a neighbour of a DODAG node but not a leaf in my
understanding

I understand that we can have it. Please someone correct me if I am
wrong.

RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only:

=C2=A0- A leaf node (only) does not ever participate as a RPL router.

=C2=A0- Support of a particular MOP encoding is not required

=C2=A0- Support of a particular OF is not required.

=C2=A0-=C2=A0 A leaf node does not generally issue DIO messages,

=C2=A0- it may issue DAO and DIS messages.=C2=A0 A leaf node accepts DIO messages though it generally ignores DAO and DIS messages=C2=A0 (not
applied in our case)


 A leaf node accepts DIO messages and is thus RPL-aware in my understanding;=

Peter

--001a113fbf90d5fea1055495de5d-- From nobody Tue Jul 18 04:48:41 2017 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 136C8131DFB for ; Tue, 18 Jul 2017 04:48:40 -0700 (PDT) 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 MN91Z4-K8amO for ; Tue, 18 Jul 2017 04:48:38 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9254131DFA for ; Tue, 18 Jul 2017 04:48:37 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id mBoa1v00V0F6qFb01BobLJ; Tue, 18 Jul 2017 13:48:35 +0200 Received: from 2001:67c:370:128:4a7:3504:ae1d:4449 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 13:48:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 13:48:34 +0200 From: peter van der Stok To: Ines Robles Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> Message-ID: <53ff58f630492909409429a1f49da504@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 11:48:40 -0000 Hi Ines, my suggestion: There is a LLN of connected nodes with IPv6 addresses and paths between them A subset of these nodes is RPL aware. These RPL aware nodes form a DODAG. The non RPL aware nodes are not part of the DODAG and cannot be leaves of the DODAG However, communication is possible between a rpl-aware node and a non-rpl-aware node via link-local addresses at least. Peter Ines Robles schreef op 2017-07-18 13:32: > Yes, agree. > > So, could we have a case where the leaf nodes do not accept DIO > Messages like in the use cases? > > Maybe we should define the features with more detail of a > not-RPL-aware-leaf in the document. > > 2017-07-18 13:23 GMT+02:00 peter van der Stok : > >> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >> It can be a neighbour of a DODAG node but not a leaf in my >> understanding >> >> I understand that we can have it. Please someone correct me if I am >> wrong. >> >> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >> >> - A leaf node (only) does not ever participate as a RPL router. >> >> - Support of a particular MOP encoding is not required >> >> - Support of a particular OF is not required. >> >> - A leaf node does not generally issue DIO messages, >> >> - it may issue DAO and DIS messages. A leaf node accepts DIO >> messages though it generally ignores DAO and DIS messages (not >> applied in our case) > > A leaf node accepts DIO messages and is thus RPL-aware in my > understanding; > > Peter From nobody Tue Jul 18 05:12:54 2017 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 E595412785F for ; Tue, 18 Jul 2017 05:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 qpM1rT7HbpER for ; Tue, 18 Jul 2017 05:12:51 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::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 DCBE1127599 for ; Tue, 18 Jul 2017 05:12:50 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id e199so2488167pfh.0 for ; Tue, 18 Jul 2017 05:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:message-id:subject :in-reply-to:references:to; bh=gzc1wzUbgYCLDCxFlv/4vLIZjr2GSwPljUlt8F9hCTM=; b=iDV3SloOoC88QHnXEzRGd6aBKI/OK6R9PhtBrCTJ7B1FBtzPJRlfXD66G7DyPOp4Ee Vi3mMtB2Z0HDr/7qXOzJKumfJl0nGrIH8vKygiGNOCepeRDwxoukJrZaPRA86Bnvc3ja 1MQKadjLE+CkblX2SfoVuB0K8VZCbB3SRNtcMQUX3kWz1/EIKqf+dCPqPHwyzNlij6Mg oJzMAA/d5skhaWoZOivzQbnzGosVshZ8xNm+EshFnWWQH5JWlDfUPEkjqoEtKeDq7aqw erAovuh0AUFzeA3WjDaO0VMqqjj4f1F8/WhkcFnrSMFSqryYRB8IDWPB8gH1MpgXCpSU vPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:in-reply-to:references:to; bh=gzc1wzUbgYCLDCxFlv/4vLIZjr2GSwPljUlt8F9hCTM=; b=BIEAhewvjLFFqwkQtvp7liD75i4MmoKJFSnk5/2N941ie2t/85cFy17xYNeDcozryZ nf3+zUmyatXr/FhrCevB1yDlkOEaMi2sRzeuDDl4SPOXRzl6S8a/g14UqH8lO5ct4Q9I jp9jAfMdAJFdin6gHktU5Ipy5gbZkY2gmIeVojLZDNDdVnRUJGENFEsRlJa13DsClDTx UItRV9MmHA6DQiypjtMVlz/mLsp9eylX+R8ya0nG4N/6mQmMILTxUoQsHVthFTqu0JXq dqFVZKGAWCdOwCwoT/YojmC0nccWi7GKc9o7XZy5NjIAMG3I90/OCzmUV4TIymhSDZDb qmzQ== X-Gm-Message-State: AIVw111xv5l2FpKiGbuA/ZOgpgB2iwbkgXCaI0uzQY+aQnAXbE7b8iYF f/SF/c/LtO5mUHGMkI1i6w== X-Received: by 10.84.232.129 with SMTP id i1mr1525159plk.28.1500379970429; Tue, 18 Jul 2017 05:12:50 -0700 (PDT) Received: from [10.160.128.93] ([45.77.71.122]) by smtp.gmail.com with ESMTPSA id u6sm3339206pgb.12.2017.07.18.05.12.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:12:48 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-22C3EB27-F205-4034-BDC7-0BDB63465FD8 From: satish anamalamudi Mime-Version: 1.0 (1.0) Date: Tue, 18 Jul 2017 20:12:45 +0800 Message-Id: In-Reply-To: <1b9c00420fef2e15d2bbfd6217acc795.squirrel@ece.iisc.ernet.in> References: <1b9c00420fef2e15d2bbfd6217acc795.squirrel@ece.iisc.ernet.in> To: lavanyahm@ece.iisc.ernet.in, Routing Over Low power and Lossy networks X-Mailer: iPhone Mail (14F89) Archived-At: Subject: Re: [Roll] AODV-RPL : unknown link state 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, 18 Jul 2017 12:12:53 -0000 --Apple-Mail-22C3EB27-F205-4034-BDC7-0BDB63465FD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Lavanya and all, Please see my response in [SA]. Regards, Satish Sent from my iPhone > On 18 Jul 2017, at 12:56 PM, LavanyaHM wrote= : >=20 > Dear AODV-RPL authors, >=20 > First of all I want to thank authors of this draft as it is useful in ad > hoc and on-demand routing cases.=20 > I am implementing AODV-RPL in Contiki OS. During implementation, I am > facing a situation where a node > has no way of determining the bi-directional state of its peering link, > symmetric or asymmetric, at the time of path establishment. The reason > being, there was no data transferred earlier over the link between the > sender and receiver of RREQ message. > This is especially true when the network has freshly come up and AODV-RPL= > session was initiated, and the network is not sufficiently warmed up. >=20 > The question is, should we treat the lack of knowledge about the > bi-directional link state as symmetric or asymmetric ? When encountered > with this situation, the current implementation optimistically treats the > link > as symmetric, by default. But then, if the link actually turns out to > exhibit asymmetric behavior once the data > starts flowing, what should the protocol do ?In the current specification,= we don't have a provision for re-initiating or modifying a P2P connection o= nce it is set up. Let me know your thoughts on this. [SA] During the network bootup, we can assume the AODV-RPL protocol operatio= n as bi-directional symmetric if there is no ETX statistics of default-RPL. O= nce, the data transmission occurs we can reconstruct the symmetric or asymme= tric routes based on actual ETX statistics. > Since DIO RREQ messages follow the operation of default RPL DIO trickle ti= mer, we can expect that these messages continue to flow even after the RREP i= s received. Therefore, these messages act like probes to detect the presence= of an asymmetric link. In fact, we are trying to reconstruct P2P connection= s all the time at the rate as dictated by the DIO RREQ trickle timer. If th= e above explanation is fine, then we need to accordingly handle the existing= > instance.=20 >=20 >=20 >=20 > Any recommendation on assigning life time for routes ? [SA] We will consider this issue in the next version of the draft. >=20 > Regards, > Lavanya H M >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-22C3EB27-F205-4034-BDC7-0BDB63465FD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello La= vanya and all,

Please see my response in [S= A].

Regards,
Satish<= br>
Sent from my iPhone

On 18 Jul 2017, at 12:56 PM, LavanyaHM <lavanyahm@ece.iisc.ernet.in&g= t; wrote:

=
Dear AODV-RPL authors,

First of all I want to thank authors of this draf= t as it is useful in ad
hoc  and  on-demand  routing cases.
I am implementing AODV-RPL in Contiki OS. D= uring implementation, I am
= facing a situation where a node
has no way of determining the bi-directional state of its p= eering link,
symmetri= c or  asymmetric, at the time of path establishment. The reason<= br>
being, there was no data tra= nsferred  earlier over the link between the
sender and receiver of RREQ message.
<= /blockquote>
This is  especially true wh= en the network has freshly come up and AODV-RPL
session was initiated, and the network is not suf= ficiently warmed up.
=
The question is, sho= uld we treat the lack of knowledge about the
bi-directional link state as symmetric or asymmetric= ? When encountered
w= ith this situation, the current implementation optimistically treats the
link
as symmetric, by default. But then, if t= he link actually turns out to
exhibit asymmetric behavior once the data
starts flowing, what should the protocol do ?<= /span>In the curre= nt specification, we don't have a provision for re-initiating or modifying a P2P c= onnection once it is set up. Let me know your thoughts on this.
[SA] During the network bootup, we can assume the AO= DV-RPL protocol operation as bi-directional symmetric if there is no ETX sta= tistics of default-RPL. Once, the data transmission occurs we can reconstruc= t the symmetric or asymmetric routes based on actual ETX statistics.<= /div>
Since DIO RREQ messages follow the operation of default RPL DI= O trickle timer, we can expect that these messages continue to flow eve= n after the RREP is received. Therefore, these messages act like probes= to detect the presence of an asymmetric link. In fact, we are trying t= o reconstruct P2P connections all the time at the rate as dictated by t= he DIO RREQ trickle timer.  If the above explanation is fine, then= we need to accordingly handle the existing
instance. =

<= blockquote type=3D"cite">

Any recommendation on a= ssigning life time for routes ?

[SA] W= e will consider this issue in the next version of the draft.

R= egards,
Lavanya H M


_______________________________________________
Roll mailing list
Roll@i= etf.org
https://www.ietf.org/mailman/li= stinfo/roll
= --Apple-Mail-22C3EB27-F205-4034-BDC7-0BDB63465FD8-- From nobody Tue Jul 18 05:53:11 2017 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 C369A129B10 for ; Tue, 18 Jul 2017 05:53:10 -0700 (PDT) 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 pLyiIu2qGqjd for ; Tue, 18 Jul 2017 05:53:09 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009E9131898 for ; Tue, 18 Jul 2017 05:53:07 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id v127so2956557itd.0 for ; Tue, 18 Jul 2017 05:53:07 -0700 (PDT) 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=glWBgXZ82uloJwEYPsKswfXzQuF8tKzOEpUkqhdCl5I=; b=g4B4t/zzjvaZecwvoNWVnaqsrn12syddubWRqFN0H0sD9tr/ekIuWf2DZQNdkFClLd IfV4slBKpfT9c+F61E6sAdOX6LyoyZKwv1SID3HoCftZZS8nzbyuhXRs7aZCIPdPwtKK bBbMyc6J9uGR+un/Wo88UI35hXvnkbYUHUJd4YaEblqSAecwej9W1H5S+o8AggC98S/9 kSqOgzsJ//Agl/l7xx5/XE7+jvdixjFE1vTpv+VHfx9PQBLw17m/b39Cd24Qkmo2lsPM xlw1DpAMJWxAKw+TzZwLWqBcerSVYaZDFEr5DKPN4JlyC1Vniz9Ea5EYHbHDl5ePXokv mlrg== 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=glWBgXZ82uloJwEYPsKswfXzQuF8tKzOEpUkqhdCl5I=; b=K0C1mNGjvas4fR/Hk2CJ5meSOjqAxUURNu+nT4YI2cLHmFVAYs1fOQOIgYeQl1uZFi /RrncyYR+NSQypaK9PbmLSPk6ZRAuv4Jqi61Iz1gion3HaoU+ROUZp33B+REAWzfX8x+ EOHP0cvaLL/qGNAlHPeslkNHueqUVqbhWTM0MBDrJyhuE+oXXZNU0kS86qASfAUyyYfV wVBwgIxgiVFt9Q0oNRiNQ/bAW+KVP+BF8YKiA/XIORVT/AkPsccnxjKoWjyd5bMhYbI5 srJP9uUJXcUqMizEJ4iT5zOionVictpd0+z/yJUkCdlvG05NH/5vkrrcCWKU7s5duLVE dnZw== X-Gm-Message-State: AIVw110vGfC8JusVEPISLofjejlNlTmxfDoibucsAzTInvg3JIUhjYD1 eVv7MHKLeFuaz7lvf7AySF4/J5uI1f9e X-Received: by 10.36.33.202 with SMTP id e193mr2512340ita.92.1500382387295; Tue, 18 Jul 2017 05:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Tue, 18 Jul 2017 05:53:06 -0700 (PDT) In-Reply-To: <53ff58f630492909409429a1f49da504@xs4all.nl> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <53ff58f630492909409429a1f49da504@xs4all.nl> From: Ines Robles Date: Tue, 18 Jul 2017 14:53:06 +0200 Message-ID: To: "consultancy@vanderstok.org" Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a1146ee3e38df86055496ff57" Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 12:53:11 -0000 --001a1146ee3e38df86055496ff57 Content-Type: text/plain; charset="UTF-8" Yes. a non RPL aware node is not part of a DODAG. We should add more clarification in the text, so far we have: RPL-not-capable: It is a device which do not implement RPL, thus we can say that the device is not-RPL-aware. Please note that the device can be found inside the LLN. In this document a not-RPL-aware node which is a leaf of a DODAG is called not-RPL-aware-leaf. Could be changed to: RPL-not-capable: It is a device which does not implement RPL, thus, we can say that the device is not-RPL-aware. Please, note that the device can be found inside the LLN. In ths document, a not-RPL-aware node is connected to a 6LR in a "leaf position" ( note that the device does not belong to a DODAG). The device uses Router-Advertisements, 6LowPAN DAR/DAC and efficient-ND only to participate in the network This type of node is called a not-RPL-aware-leaf. What do you think? Thanks, Ines 2017-07-18 13:48 GMT+02:00 peter van der Stok : > Hi Ines, > > my suggestion: > There is a LLN of connected nodes with IPv6 addresses and paths between > them > A subset of these nodes is RPL aware. > These RPL aware nodes form a DODAG. > The non RPL aware nodes are not part of the DODAG and cannot be leaves of > the DODAG > However, communication is possible between a rpl-aware node and a > non-rpl-aware node via link-local addresses at least. > > Peter > > Ines Robles schreef op 2017-07-18 13:32: > > Yes, agree. >> >> So, could we have a case where the leaf nodes do not accept DIO >> Messages like in the use cases? >> >> Maybe we should define the features with more detail of a >> not-RPL-aware-leaf in the document. >> >> 2017-07-18 13:23 GMT+02:00 peter van der Stok : >> >> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >>> It can be a neighbour of a DODAG node but not a leaf in my >>> understanding >>> >>> I understand that we can have it. Please someone correct me if I am >>> wrong. >>> >>> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >>> >>> - A leaf node (only) does not ever participate as a RPL router. >>> >>> - Support of a particular MOP encoding is not required >>> >>> - Support of a particular OF is not required. >>> >>> - A leaf node does not generally issue DIO messages, >>> >>> - it may issue DAO and DIS messages. A leaf node accepts DIO >>> messages though it generally ignores DAO and DIS messages (not >>> applied in our case) >>> >> >> A leaf node accepts DIO messages and is thus RPL-aware in my >> understanding; >> >> Peter >> > --001a1146ee3e38df86055496ff57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. =C2=A0a non RPL aware node is not part of a DODAG.=C2= =A0

We should add more clarification in the text, so far= we have:

 RPL-n=
ot-capable: It is a device which do not implement RPL, thus we can
   say that the device is not-RPL-aware.  Please note that the device
   can be found inside the LLN.  In this document a not-RPL-aware node
   which is a leaf of a DODAG is called not-RPL-aware-leaf.

Could be changed to:

=
 RPL-not-capabl=
e: It is a device which does not implement RPL,=20
 thus, we can say that the device is not-RPL-aware.=20
 Please, note that the device can be found inside the LLN. =20
 In ths document, a not-RPL-aware node is connected to a 6LR in a "lea=
f position"=20
 ( note that the device does not belong to a DODAG).
 The device uses Router-Advertisements, 6LowPAN DAR/DAC and=20
   efficient-ND only to participate in the network=20
 This type of node is called a not-RPL-aware-leaf.
<= pre class=3D"gmail-newpage" style=3D"margin-top:0px;margin-bottom:0px">
<= /pre>
What do you t=
hink?

Thanks,

Ines


2017-07-18= 13:48 GMT+02:00 peter van der Stok <stokcons@xs4all.nl>:
Hi Ines,

my suggestion:
There is a LLN of connected nodes with IPv6 addresses and paths between the= m
A subset of these nodes is RPL aware.
These RPL aware nodes form a DODAG.
The non RPL aware nodes are not part of the DODAG and cannot be leaves of t= he DODAG
However, communication is possible between a rpl-aware node and a non-rpl-a= ware node via link-local addresses at least.

Peter

Ines=C2=A0 Robles schreef op 2017-07-18 13:32:

Yes, agree.

So, could we have a case where the leaf nodes do not accept DIO
Messages like in the use cases?

Maybe we should define the features with more detail of a
not-RPL-aware-leaf in the document.

2017-07-18 13:23 GMT+02:00 peter van der Stok <stokcons@xs4all.nl>:

section 2, rpl-not-capable; how can this node be a leaf of a DODAG.
It can be a neighbour of a DODAG node but not a leaf in my
understanding

I understand that we can have it. Please someone correct me if I am
wrong.

RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only:

- A leaf node (only) does not ever participate as a RPL router.

- Support of a particular MOP encoding is not required

- Support of a particular OF is not required.

-=C2=A0 A leaf node does not generally issue DIO messages,

- it may issue DAO and DIS messages.=C2=A0 A leaf node accepts DIO
messages though it generally ignores DAO and DIS messages=C2=A0 (not
applied in our case)

=C2=A0A leaf node accepts DIO messages and is thus RPL-aware in my
understanding;

Peter

--001a1146ee3e38df86055496ff57-- From nobody Tue Jul 18 05:59:05 2017 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 14D9A1287A5 for ; Tue, 18 Jul 2017 05:59:03 -0700 (PDT) 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 zrV_8EZeJgQ5 for ; Tue, 18 Jul 2017 05:58:55 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B8A1318A8 for ; Tue, 18 Jul 2017 05:58:54 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id mCyr1v00S0F6qFb01Cyr95; Tue, 18 Jul 2017 14:58:51 +0200 Received: from 2001:67c:370:128:4a7:3504:ae1d:4449 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 14:58:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 14:58:51 +0200 From: peter van der Stok To: Ines Robles Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <53ff58f630492909409429a1f49da504@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] rplinfo 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, 18 Jul 2017 12:59:03 -0000 Yes, better, removes my confusion. Ines Robles schreef op 2017-07-18 14:53: > Yes. a non RPL aware node is not part of a DODAG. > > We should add more clarification in the text, so far we have: > > RPL-not-capable: It is a device which do not implement RPL, thus we > can > say that the device is not-RPL-aware. Please note that the device > can be found inside the LLN. In this document a not-RPL-aware node > which is a leaf of a DODAG is called not-RPL-aware-leaf. > > Could be changed to: > > RPL-not-capable: It is a device which does not implement RPL, > thus, we can say that the device is not-RPL-aware. > Please, note that the device can be found inside the LLN. > In ths document, a not-RPL-aware node is connected to a 6LR in a > "leaf position" > ( note that the device does not belong to a DODAG). > The device uses Router-Advertisements, 6LowPAN DAR/DAC and > efficient-ND only to participate in the network > This type of node is called a not-RPL-aware-leaf. > > What do you think? > > Thanks, > > Ines > > 2017-07-18 13:48 GMT+02:00 peter van der Stok : > >> Hi Ines, >> >> my suggestion: >> There is a LLN of connected nodes with IPv6 addresses and paths >> between them >> A subset of these nodes is RPL aware. >> These RPL aware nodes form a DODAG. >> The non RPL aware nodes are not part of the DODAG and cannot be >> leaves of the DODAG >> However, communication is possible between a rpl-aware node and a >> non-rpl-aware node via link-local addresses at least. >> >> Peter >> >> Ines Robles schreef op 2017-07-18 13:32: >> >> Yes, agree. >> >> So, could we have a case where the leaf nodes do not accept DIO >> Messages like in the use cases? >> >> Maybe we should define the features with more detail of a >> not-RPL-aware-leaf in the document. >> >> 2017-07-18 13:23 GMT+02:00 peter van der Stok : >> >> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >> It can be a neighbour of a DODAG node but not a leaf in my >> understanding >> >> I understand that we can have it. Please someone correct me if I am >> wrong. >> >> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >> >> - A leaf node (only) does not ever participate as a RPL router. >> >> - Support of a particular MOP encoding is not required >> >> - Support of a particular OF is not required. >> >> - A leaf node does not generally issue DIO messages, >> >> - it may issue DAO and DIS messages. A leaf node accepts DIO >> messages though it generally ignores DAO and DIS messages (not >> applied in our case) >> >> A leaf node accepts DIO messages and is thus RPL-aware in my >> understanding; >> >> Peter From nobody Tue Jul 18 06:23:41 2017 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 2FD0612F3CB; Tue, 18 Jul 2017 06:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qqI8z8wFw-k3; Tue, 18 Jul 2017 06:23:31 -0700 (PDT) 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 8763712EC51; Tue, 18 Jul 2017 06:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1733; q=dns/txt; s=iport; t=1500384211; x=1501593811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=glRtMetHerU68+SpPDqKo1ChrnaCjfV8xfOVmGeUbAU=; b=CP/56nBycZ0xTnLbklPNfkYCMya6lawD2qdAxS7VEcBzP7THRwGqark2 NN5yHh3cN4lZ/puiKOBd2ceMV55vUbY31R28BTunfBrXQfvpJnjl1oZzG t2vMU0t+KoytCMGItgBWrmedFrdk7lY6Xyla0IW2Zm/AsN6rbdfCp9tov M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAABlC25Z/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRZZYEghEhC4RMTwKDUT8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDAQE4NAQHDAQCAQgRBAEBHwUEBycLFAkIAgQBDQUIig8DFRCwXYc6DYNGA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKINNhQWCV4gHBZ80AodIjEOSOJVWAR8?= =?us-ascii?q?4gQp1FUmFSIFOdodLgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,378,1496102400"; d="scan'208";a="261047849" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2017 13:23:30 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6IDNUOe010989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 13:23:30 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.1210.3; Tue, 18 Jul 2017 08:23:29 -0500 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.1210.000; Tue, 18 Jul 2017 08:23:29 -0500 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" , Ines Robles CC: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft Thread-Index: AQHS/8kJ2qIzcvWl/EiVcKLzs8IYrg== Date: Tue, 18 Jul 2017 13:23:25 +0000 Deferred-Delivery: Tue, 18 Jul 2017 13:23:11 +0000 Message-ID: References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> In-Reply-To: <65ebd4a8922641c33865871d76e94c10@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.72.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 18 Jul 2017 13:23:33 -0000 Hell Peter The document also indicates when to encaps and which artifacts are needed. = Whereas 6LoRH describes how to compress the artifacts and the encaps. An annex somewhere that captures the resulting shape of the packets is of g= reat help for implementers. I think it does not hurt as annex, all the cont= rary. Take care, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: mardi 18 juillet 2017 10:30 To: Ines Robles Cc: Michael Richardson ; roll ; 6tisc= h@ietf.org Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH C= onfiguration into useofrplinfo draft Hi Ines, I don't see the relation between the examples and the rplinfo draft. RPLinfo is about routes through the DODAG and the use of IP-in-IP and RPI. The examples do not reflect that topic in my opinion. Peter Ines Robles schreef op 2017-07-18 10:19: > Dear all, >=20 > Yesterday at 6tisch meeting was suggested to add this document, >=20 > https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 >=20 > as an Appendix section in useofrplinfo draft. >=20 > We would like to know your opinion on that, >=20 > - Should we add this draft as an appendix? or >=20 > - Should this draft be presented in lwig? or >=20 > - Additional Suggestions? >=20 > Thank you, >=20 > The authors. > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jul 18 06:52:22 2017 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 1720F131905 for ; Tue, 18 Jul 2017 06:52:15 -0700 (PDT) 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=unavailable 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 xUoosVXRaD5N for ; Tue, 18 Jul 2017 06:52:11 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00B4131B09 for ; Tue, 18 Jul 2017 06:52:11 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id mDs91v00l0F6qFb01Ds9Uo; Tue, 18 Jul 2017 15:52:09 +0200 Received: from 2001:67c:370:128:4a7:3504:ae1d:4449 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Jul 2017 15:52:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 15:52:09 +0200 From: peter van der Stok To: "Pascal Thubert (pthubert)" Cc: consultancy@vanderstok.org, Routing Over Low power and Lossy networks , Ines Robles , Michael Richardson , 6tisch@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 18 Jul 2017 13:52:15 -0000 Well Pascal, The authors should decide, but I recommend some structuring and additional text. Peter Pascal Thubert (pthubert) schreef op 2017-07-18 15:23: > Hell Peter > > The document also indicates when to encaps and which artifacts are > needed. Whereas 6LoRH describes how to compress the artifacts and the > encaps. > An annex somewhere that captures the resulting shape of the packets is > of great help for implementers. I think it does not hurt as annex, all > the contrary. > > Take care, > > Pascal > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: mardi 18 juillet 2017 10:30 > To: Ines Robles > Cc: Michael Richardson ; roll ; > 6tisch@ietf.org > Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for > 6TiSCH Configuration into useofrplinfo draft > > Hi Ines, > > I don't see the relation between the examples and the rplinfo draft. > RPLinfo is about routes through the DODAG and the use of IP-in-IP and > RPI. > The examples do not reflect that topic in my opinion. > > Peter > > Ines Robles schreef op 2017-07-18 10:19: >> Dear all, >> >> Yesterday at 6tisch meeting was suggested to add this document, >> >> https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 >> >> as an Appendix section in useofrplinfo draft. >> >> We would like to know your opinion on that, >> >> - Should we add this draft as an appendix? or >> >> - Should this draft be presented in lwig? or >> >> - Additional Suggestions? >> >> Thank you, >> >> The authors. >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Tue Jul 18 08:03:56 2017 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 15B6D129482; Tue, 18 Jul 2017 08:03:55 -0700 (PDT) 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 XXuKvE-TR7-g; Tue, 18 Jul 2017 08:03:53 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 11E231204DA; Tue, 18 Jul 2017 08:03:50 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id t2so15886895qkc.1; Tue, 18 Jul 2017 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=YialDoGFyWhTWSqozVIOPPNV4Q6CbKGQ35ov6aQQ79k=; b=sptCGuPnc0bXfFUq81rO5HVkkQaNYlED0+gl2CIKB2UnbAzKgpUqGaUQgMLrgJS8+X 7oIuzOjK04b1T9EeXUJwGEFsHGifhH5ktO/drO5rtjRD1Txpj37Pli3x9p+as3E7V+e0 RjXGP9iWNEJQwFV8Z7LJbilPpcVWQ0tPuQKHx8BrP80Dyv1zcQPXQcjj4+/NzfLDWQXU V7/UDatrI0waXWQ/WgDcKLL0Vsfmy9jagRDXy9/4xcdQUsUBG3/3QaA4+h/I/k9gsGoe tGYqg2aHrPyownqP5e1HZqWQXc1COwAtpuD7ooCBjR6xVn5Dkj4yADdlnElTSCaKeyDf x3dw== 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=YialDoGFyWhTWSqozVIOPPNV4Q6CbKGQ35ov6aQQ79k=; b=oQSg1FqDPR3Vu1H6QnQTRjWwvVT1U4ipuF2iNPi0FSxoWWET0rgnGVOfmOFsyHEAoj PZOVSyxEz00oT2qEn2aR7pmAQMc4Q+7upJ5qvuv8oRPjh5kwX/b2B3PwMzVQLDSgNeZ4 icAtcQPvO+Pz+YqenND9ZNiiW1lcJAmf9j+k9iOtuKAgT+znMONLhCRGUJTlBt7maycV n0zljPaBGQjauHkoZw8txR74y1BQdtlPWsFKc69G4DtnpEAPVIg4SWp+JRoubrYv60TB RhrEECMSCnmocmxLoqZzskPUmRJre7NnWA9/e442XgN0v8SoSw9VVgLl1optuDMEsg0N +z9w== X-Gm-Message-State: AIVw1111+j9WbdcRLNHnpxLa0KuIsHiYv4D031AFbUR51/Nic3Xquz7s Re2/T+1qmfUbP0UiJdTZd7+OAMxn1A== X-Received: by 10.55.40.218 with SMTP id o87mr2409091qko.50.1500390228923; Tue, 18 Jul 2017 08:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.85 with HTTP; Tue, 18 Jul 2017 08:03:48 -0700 (PDT) From: Abdussalam Baryun Date: Tue, 18 Jul 2017 17:03:48 +0200 Message-ID: To: Routing Over Low power and Lossy networks Cc: draft-ietf-roll-aodv-rpl@ietf.org Content-Type: multipart/alternative; boundary="001a113ea6569e9b0d055498d237" Archived-At: Subject: Re: [Roll] AODV-RPL currently is stable: discussion requested about two possible updates 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, 18 Jul 2017 15:03:55 -0000 --001a113ea6569e9b0d055498d237 Content-Type: text/plain; charset="UTF-8" Hi Charlie, On Mon, Jul 17, 2017 at 11:37 PM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello folks, > > The AODV-RPL draft has been pretty stable. There have not been any > modifications needed that were important enough to motivate submission of a > revised draft. > > We had a suggestion for supporting non-storing mode in AODV-RPL. Prior to > our presentation on Tuesday, I would like to discuss whether or not there > is support for this improvements. > Yes, however, I prefer in separate draft. I support this draft is for only store-mode. > > The mechanism for supporting non-storing mode is straightforward -- > basically it is analogous to what is already specified in RPL. Using > AODV-RPL in non-storing mode would no longer provide the benefit of small > control messages, because the source routes would have to be stored in RREQ > and RREP. We may have a mix situation which can be usually, and we may have a way to optimize the message overhead. However, for the class of devices that cannot store routes, AODV-RPL would > still provide a beneficial way to establish peer-to-peer routes. I think this is the worst case for ROLL with all devices not-storing > If it is desired to have both storing mode and non-storing mode in the > same draft, I reckon that the AODV-RPL author team could have another draft > ready for that purpose in short order. If it is preferable to have another > draft to support non-storing mode, then that is also a possibility, and > likewise the new draft could be done soon. > I support another draft for the both non-store mode and mix. So one draft for store-mode and another draft for two modes (on-store and mix). > > Comments will be appreciated. > will try to review, thanks > > Regards, > Charlie P. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a113ea6569e9b0d055498d237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Charlie,

On Mon, Jul 17, 2017 at 11:37 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
Hello folks,

The AODV-RPL draft has been pretty stable.=C2=A0 There have not been any mo= difications needed that were important enough to motivate submission of a r= evised draft.

We had a suggestion for supporting non-storing mode in AODV-RPL. Prior to o= ur presentation on Tuesday, I would like to discuss whether or not there is= support for this improvements.
Yes, however, I prefer= =C2=A0in separate draft.=C2=A0I support this draft is for only store-mode.<= /div>

The mechanism for supporting non-storing mode is straightforward -- basical= ly it is analogous to what is already specified in RPL. Using AODV-RPL in n= on-storing mode would no longer provide the benefit of small control messag= es, because the source routes would have to be stored in RREQ and RREP.=C2= =A0

We may have a mix situation which=C2= =A0can be=C2=A0usually, and we may have a=C2=A0way to optimize the message = overhead.

However, for the class of de= vices that cannot store routes, AODV-RPL would still provide a beneficial w= ay to establish peer-to-peer routes.=C2=A0

= I think this is=C2=A0the worst case for ROLL with all devices not-storing
=C2=A0
If it is desired to have both storin= g mode and non-storing mode in the same draft, I reckon that the AODV-RPL a= uthor team could have another draft ready for that purpose in short order.= =C2=A0 If it is preferable to have another draft to support non-storing mod= e, then that is also a possibility, and likewise the new draft could be don= e soon.

I support another draft=C2=A0fo= r the both non-store mode and mix. So one draft for store-mode and another = draft for two modes (on-store and mix).

Comments will be appreciated.

will try = to review, thanks=C2=A0

Regards,
Charlie P.


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

--001a113ea6569e9b0d055498d237-- From nobody Wed Jul 19 05:29:27 2017 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 A774D131CF3 for ; Wed, 19 Jul 2017 05:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, RP_MATCHES_RCVD=-0.001, 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 CgWRN-SU4Afv for ; Wed, 19 Jul 2017 05:29:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E159131CEE for ; Wed, 19 Jul 2017 05:29:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRN87767; Wed, 19 Jul 2017 12:29:23 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Jul 2017 13:29:23 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.222]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Wed, 19 Jul 2017 20:29:18 +0800 From: houjianqiang To: "roll@ietf.org" Thread-Topic: Key points of draft-hou-roll-rpl-parent-selection Thread-Index: AdMAiqRkE8PSYNJxTuWXeakLbnfOTQ== Date: Wed, 19 Jul 2017 12:29:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086A4B84BDGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.596F50A4.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.222, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 91725661acb906068591dadc2f0a4ea1 Archived-At: Subject: [Roll] Key points of draft-hou-roll-rpl-parent-selection 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, 19 Jul 2017 12:29:26 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C086A4B84BDGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYW0gZ29pbmcgdG8gcHJlc2VudCBteSBkcmFmdCA8ZHJhZnQtaG91LXJv bGwtcnBsLXBhcmVudC1zZWxlY3Rpb24tMDA+IGluIFJvbGwgV0cuIFRoZSBzbGlkZXMgYXJlIG9u bGluZSBub3cuIFRvIG1ha2UgaXQgZWFzaWVyIGZvciB5b3UgdG8gdW5kZXJzdGFuZCBpdCwgYmVs b3cgYXJlIHNvbWUga2V5IHBvaW50cyBpbiB0aGUgcHJlc2VudGF0aW9uOg0KDQpJc3N1ZTogUmFu ZG9tbHkgVW5iYWxhbmNlZCBOZXR3b3JraW5nDQoNCkdvYWw6IGJhbGFuY2luZyB0aGUgbnVtYmVy IG9mIGNoaWxkIG5vZGVzDQoNClBvc3NpYmxlIHVzaW5nIHNjZW5hcmlvOiBTbWFydCBNZXRlcnMN Cg0KU29sdXRpb246DQoNCjEuDQogQ29tcHV0ZSB0aGUgTnVtYmVyX29mX0NoaWxkcmVuIGZyb20g TmVpZ2hib3IgVGFibGUgKE5laWdoYm9yIENhY2hlIEVudHJ5KQ0KDQoyLg0KIFN0b3JlIHRoZSBO dW1iZXJfb2ZfQ2hpbGRyZW4gaW4gYSBuZXcgTWV0cmljLCBhbmQgc2VuZCBpdCB0byBkb3duc3Ry ZWFtIG5vZGVzIHdpdGggRElPDQoNCjMuDQogRG93bnN0cmVhbSBub2RlcyBjaG9vc2UgcGFyZW50 IG5vZGUgYmFzZWQgb24gTnVtYmVyX29mX0NoaWxkcmVuDQoNCjQuDQogQ29tYmluZSB0aGUgTnVt YmVyX29mX0NoaWxkcmVuIHdpdGggb3RoZXIgbWV0cmljcy9jb25zdHJhaW50cw0KDQpUaGUgZGV0 YWlscyBvZiBjb21wdXRpbmcgdGhlIE51bWJlcl9vZl9DaGlsZHJlbiBhcmUgcmVsYXRlZCB0byB0 aGUgbmVpZ2hib3IgdGFibGUgbWFuYWdlbWVudCwgYW5kIFJhaHVsIGhhcyBnaXZlbiBhIGdvb2Qg aWxsdXN0cmF0aW9uIGluIDxkcmFmdC1qYWRoYXYtbHdpZy1uYnItbWdtdC1wb2xpY3ktMDA+LiBU aGUgY2hpbGQgcmVnaXN0ZXIvZGVyZWdpc3RlciBpbiBwYXJlbnTigJlzIE5DRSBhY2NvcmRpbmcg dG8gREFPL05QREFPDQogKHN0b3JpbmcgbW9kZSkgb3IgTlMrQVJPL05TK0FST18wbGZ0aW1lIChu b24tc3RvcmluZyBtb2RlKS4NCg0KQ2hlZXJzLA0KSmlhbnFpYW5nDQo= --_000_DD0A994E4D6B3F4080662703C8C7C086A4B84BDGGEMM506MBSchina_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i 5a6L5L2TLEFyaWFsLEhlbHZldGljYSFpbXBvcnRhbnQiPkRlYXImbmJzcDthbGwsPGJyPg0KPGJy Pg0KSSZuYnNwO2FtJm5ic3A7Z29pbmcmbmJzcDt0byZuYnNwO3ByZXNlbnQmbmJzcDtteSZuYnNw O2RyYWZ0Jm5ic3A7Jmx0O2RyYWZ0LWhvdS1yb2xsLXJwbC1wYXJlbnQtc2VsZWN0aW9uLTAwJmd0 OyZuYnNwO2luJm5ic3A7Um9sbCZuYnNwO1dHLiZuYnNwO1RoZSZuYnNwO3NsaWRlcyZuYnNwO2Fy ZSZuYnNwO29ubGluZSZuYnNwO25vdy4mbmJzcDtUbyZuYnNwO21ha2UmbmJzcDtpdCZuYnNwO2Vh c2llciZuYnNwO2ZvciZuYnNwO3lvdSZuYnNwO3RvJm5ic3A7dW5kZXJzdGFuZCZuYnNwO2l0LCZu YnNwO2JlbG93Jm5ic3A7YXJlJm5ic3A7c29tZSZuYnNwO2tleSZuYnNwO3BvaW50cyZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7cHJlc2VudGF0aW9uOjxicj4NCjxicj4NCklzc3VlOiZuYnNwO1JhbmRv bWx5Jm5ic3A7VW5iYWxhbmNlZCZuYnNwO05ldHdvcmtpbmc8YnI+DQo8YnI+DQpHb2FsOiZuYnNw O2JhbGFuY2luZyZuYnNwO3RoZSZuYnNwO251bWJlciZuYnNwO29mJm5ic3A7Y2hpbGQmbmJzcDtu b2Rlczxicj4NCjxicj4NClBvc3NpYmxlJm5ic3A7dXNpbmcmbmJzcDtzY2VuYXJpbzombmJzcDtT bWFydCZuYnNwO01ldGVyczxicj4NCjxicj4NClNvbHV0aW9uOjxicj4NCjxicj4NCjEuJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyPg0KJm5ic3A7Q29tcHV0ZSZuYnNwO3Ro ZSZuYnNwO051bWJlcl9vZl9DaGlsZHJlbiZuYnNwO2Zyb20mbmJzcDtOZWlnaGJvciZuYnNwO1Rh YmxlJm5ic3A7KE5laWdoYm9yJm5ic3A7Q2FjaGUmbmJzcDtFbnRyeSk8YnI+DQo8YnI+DQoyLiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwO1N0b3JlJm5ic3A7 dGhlJm5ic3A7TnVtYmVyX29mX0NoaWxkcmVuJm5ic3A7aW4mbmJzcDthJm5ic3A7bmV3Jm5ic3A7 TWV0cmljLCZuYnNwO2FuZCZuYnNwO3NlbmQmbmJzcDtpdCZuYnNwO3RvJm5ic3A7ZG93bnN0cmVh bSZuYnNwO25vZGVzJm5ic3A7d2l0aCZuYnNwO0RJTzxicj4NCjxicj4NCjMuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyPg0KJm5ic3A7RG93bnN0cmVhbSZuYnNwO25vZGVz Jm5ic3A7Y2hvb3NlJm5ic3A7cGFyZW50Jm5ic3A7bm9kZSZuYnNwO2Jhc2VkJm5ic3A7b24mbmJz cDtOdW1iZXJfb2ZfQ2hpbGRyZW48YnI+DQo8YnI+DQo0LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwO0NvbWJpbmUmbmJzcDt0aGUmbmJzcDtOdW1iZXJfb2Zf Q2hpbGRyZW4mbmJzcDt3aXRoJm5ic3A7b3RoZXImbmJzcDttZXRyaWNzL2NvbnN0cmFpbnRzPGJy Pg0KPGJyPg0KVGhlJm5ic3A7ZGV0YWlscyZuYnNwO29mJm5ic3A7Y29tcHV0aW5nJm5ic3A7dGhl Jm5ic3A7TnVtYmVyX29mX0NoaWxkcmVuJm5ic3A7YXJlJm5ic3A7cmVsYXRlZCZuYnNwO3RvJm5i c3A7dGhlJm5ic3A7bmVpZ2hib3ImbmJzcDt0YWJsZSZuYnNwO21hbmFnZW1lbnQsJm5ic3A7YW5k Jm5ic3A7UmFodWwmbmJzcDtoYXMmbmJzcDtnaXZlbiZuYnNwO2EmbmJzcDtnb29kJm5ic3A7aWxs dXN0cmF0aW9uJm5ic3A7aW4mbmJzcDsmbHQ7ZHJhZnQtamFkaGF2LWx3aWctbmJyLW1nbXQtcG9s aWN5LTAwJmd0Oy4mbmJzcDtUaGUmbmJzcDtjaGlsZCZuYnNwO3JlZ2lzdGVyL2RlcmVnaXN0ZXIm bmJzcDtpbiZuYnNwO3BhcmVudOKAmXMmbmJzcDtOQ0UmbmJzcDthY2NvcmRpbmcmbmJzcDt0byZu YnNwO0RBTy9OUERBTzxicj4NCiZuYnNwOyhzdG9yaW5nJm5ic3A7bW9kZSkmbmJzcDtvciZuYnNw O05TJiM0MztBUk8vTlMmIzQzO0FST18wbGZ0aW1lJm5ic3A7KG5vbi1zdG9yaW5nJm5ic3A7bW9k ZSkuJm5ic3A7PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCkppYW5xaWFuZzxicj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DD0A994E4D6B3F4080662703C8C7C086A4B84BDGGEMM506MBSchina_-- From nobody Wed Jul 19 06:10:19 2017 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 07710131D0E for ; Wed, 19 Jul 2017 06:10:17 -0700 (PDT) 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 M0PH4QpVDeGD for ; Wed, 19 Jul 2017 06:10:15 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 7CA09131461 for ; Wed, 19 Jul 2017 06:10:15 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l7so178614iof.1 for ; Wed, 19 Jul 2017 06:10:15 -0700 (PDT) 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=gdwX2rYO/JTa3kpJ841w5KgFjsMGLL5w5lYqDucqSVA=; b=SUKUtcK4P53uWTApuCVb3I6jfqEi1Ul6PFcJ5/f9I3vPoHyJ626DdLXPXSC+cPUJYn w8szDNj1rfWoyoFOOUIXNft8Nr5moQyu4DWj7vHESs/+WUm1sBzJBNpLd8H1Tb3McOyn QBTyes9iu5wCd7FmLcZwbiv/gD0lk0H2kCoPCSTQYaDl0q0rxv8y1v6FXZpF4W5PY+mI jjSRBuEveGoJA57XD/GcQDUhRQ7CKScf15ZGvIKvUl9izXGOtwuxxsA9QbPRLSDt+2Bb tVx7B0L/KramZV0pGNe4H+GE0qiQHvMAehnNxrCxsH/67G4dMa3fN8kM214DGWSuUvx/ vreQ== 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=gdwX2rYO/JTa3kpJ841w5KgFjsMGLL5w5lYqDucqSVA=; b=AF1Rg56BpT3nG+DuhRzql73bDvQD2tuQf0T3UGNxzMU/xbnSAxsh79ycynRodYSaTV u0aoNl/pG86jzomKbxQRfOn1zfuCIxi9bhd5APzYLMynYPHT+yLKUQ6P5QiJGVb8otbA i12LUz7nO70dhpBISJgWM1USAg6HIhx9Ac6DZOtflKrNT025rIQLivzSUdqngxXc6E4p leD73jVim5UaIN597Es8L7eLMjYWIybqrKRV4G7ns281uxUzPoM00r9lREXZvVKcIpSJ 5qbpSg2P4TudXugHCcRenGBkrylpP33aE6VojwobEHcVdojS3Io5QzJvg46QYCCTvnev UvOQ== X-Gm-Message-State: AIVw111qN0EnBhDKhkAROxItG+z4jC9uIyn3SBGzZ4C3KHPHN8LTnucm 7ys6UiZqxGmCO/8u+xolDjQwdpVr5Xxg X-Received: by 10.107.3.225 with SMTP id e94mr61137ioi.64.1500469814549; Wed, 19 Jul 2017 06:10:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Wed, 19 Jul 2017 06:10:14 -0700 (PDT) From: Ines Robles Date: Wed, 19 Jul 2017 15:10:14 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a113c6c0e4b05bb0554ab5aa4" Archived-At: Subject: [Roll] Slides IETF 99 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, 19 Jul 2017 13:10:17 -0000 --001a113c6c0e4b05bb0554ab5aa4 Content-Type: text/plain; charset="UTF-8" Dear all, Please find a new version of the slides https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99_roll_slides_02-00.pdf Cheers Ines + Peter 2017-07-17 11:27 GMT+02:00 Ines Robles : > Hi, > > Please find a draft version of the slides for IETF 99 > > https://www.ietf.org/proceedings/99/slides/slides- > 99-roll-ietf_99_roll_slides_v1-01.pdf > > Comments welcome, > > Thanks, > > Ines + Peter > --001a113c6c0e4b05bb0554ab5aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find a new = version of the slides


Cheers

In= es + Peter


2017-07-17 11:27 GMT+02:00 Ines Robles <mariainesrob= les@googlemail.com>:
Hi,

Please find a draft ve= rsion of the slides for IETF 99


=
Comments welcome,

Thanks,
Ines + Peter

--001a113c6c0e4b05bb0554ab5aa4-- From nobody Wed Jul 19 06:47:20 2017 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 03113131D2B; Wed, 19 Jul 2017 06:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 hkBkAfL6uAsE; Wed, 19 Jul 2017 06:47:10 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 9D2F3131D21; Wed, 19 Jul 2017 06:47:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,381,1496095200"; d="scan'208,217";a="284061972" Received: from mail-yw0-f180.google.com ([209.85.161.180]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 19 Jul 2017 15:47:07 +0200 Received: by mail-yw0-f180.google.com with SMTP id v193so569753ywg.2; Wed, 19 Jul 2017 06:47:07 -0700 (PDT) X-Gm-Message-State: AIVw113T/ImgfXKjWO+08BsNUNzpeStE6C9dgRp5lClcjQWyQS6LfJc/ q6VYUHSuEKUBzSAl9ybdeH6NBRr0Sw== X-Received: by 10.129.177.66 with SMTP id p63mr91235ywh.391.1500472026678; Wed, 19 Jul 2017 06:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.225.76 with HTTP; Wed, 19 Jul 2017 06:46:46 -0700 (PDT) In-Reply-To: References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> From: Thomas Watteyne Date: Wed, 19 Jul 2017 15:46:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "consultancy@vanderstok.org" Cc: "Pascal Thubert (pthubert)" , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="94eb2c14624c2569bc0554abde8f" Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 19 Jul 2017 13:47:13 -0000 --94eb2c14624c2569bc0554abde8f Content-Type: text/plain; charset="UTF-8" Thinking about it, I believe it's better to keep draft-munoz-6tisch-examples as a standalone document. I will be easier to maintain, compared to splitting the contents across multiple drafts, or worse, replicating the contents in multiple drafts. On Tue, Jul 18, 2017 at 3:52 PM, peter van der Stok wrote: > Well Pascal, > > The authors should decide, but I recommend some structuring and additional > text. > > Peter > > Pascal Thubert (pthubert) schreef op 2017-07-18 15:23: > > Hell Peter >> >> The document also indicates when to encaps and which artifacts are >> needed. Whereas 6LoRH describes how to compress the artifacts and the >> encaps. >> An annex somewhere that captures the resulting shape of the packets is >> of great help for implementers. I think it does not hurt as annex, all >> the contrary. >> >> Take care, >> >> Pascal >> >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok >> Sent: mardi 18 juillet 2017 10:30 >> To: Ines Robles >> Cc: Michael Richardson ; roll ; >> 6tisch@ietf.org >> Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for >> 6TiSCH Configuration into useofrplinfo draft >> >> Hi Ines, >> >> I don't see the relation between the examples and the rplinfo draft. >> RPLinfo is about routes through the DODAG and the use of IP-in-IP and RPI. >> The examples do not reflect that topic in my opinion. >> >> Peter >> >> Ines Robles schreef op 2017-07-18 10:19: >> >>> Dear all, >>> >>> Yesterday at 6tisch meeting was suggested to add this document, >>> >>> https://tools.ietf.org/html/draft-munoz-6tisch-examples-02 >>> >>> as an Appendix section in useofrplinfo draft. >>> >>> We would like to know your opinion on that, >>> >>> - Should we add this draft as an appendix? or >>> >>> - Should this draft be presented in lwig? or >>> >>> - Additional Suggestions? >>> >>> Thank you, >>> >>> The authors. >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --94eb2c14624c2569bc0554abde8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking about it, I believe it's better to keep=C2=A0= draft-munoz-6tisch-examples as a standalone document. I will be easier to m= aintain, compared to splitting the contents across multiple drafts, or wors= e, replicating the contents in multiple drafts.

On Tue, Jul 18, 2017 at 3:52 PM, peter = van der Stok <stokcons@xs4all.nl> wrote:
Well Pascal,

The authors should decide, but I recommend some structuring and additional = text.

Peter

Pascal Thubert (pthubert) schreef op 2017-07-18 15:23:

Hell Peter

The document also indicates when to encaps and which artifacts are
needed. Whereas 6LoRH describes how to compress the artifacts and the
encaps.
An annex somewhere that captures the resulting shape of the packets is
of great help for implementers. I think it does not hurt as annex, all
the contrary.

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: mardi 18 juillet 2017 10:30
To: Ines Robles <mariainesrobles@googlemail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; roll <roll@ietf.org>;
6tisch@ietf.org Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for
6TiSCH Configuration into useofrplinfo draft

Hi Ines,

I don't see the relation between the examples and the rplinfo draft. RPLinfo is about routes through the DODAG and the use of IP-in-IP and RPI.<= br> The examples do not reflect that topic in my opinion.

Peter

Ines=C2=A0 Robles schreef op 2017-07-18 10:19:
Dear all,

Yesterday at 6tisch meeting was suggested to add this document,

https://tools.ietf.org/html/draft-mu= noz-6tisch-examples-02

as an Appendix section in useofrplinfo draft.

We would like to know your opinion on that,

- Should we add this draft as an appendix? or

- Should this draft be presented in lwig? or

- Additional Suggestions?

Thank you,

The authors.
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

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

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

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



--
=
_______________________________________
=

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria<= /div>
Sr = Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley O= penWSN
Co-chair, IETF 6TiSCH

_____________= __________________________
--94eb2c14624c2569bc0554abde8f-- From nobody Wed Jul 19 10:01:50 2017 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 30EDD131535; Wed, 19 Jul 2017 10:01:42 -0700 (PDT) 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 ZZtS3eMi_-b3; Wed, 19 Jul 2017 10:01:40 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 30B6B129B14; Wed, 19 Jul 2017 10:01:40 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 32so6924603qtv.1; Wed, 19 Jul 2017 10:01:40 -0700 (PDT) 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=rEgqedKnCHsTU8Y37de2hmte8HKFiWd4b9tNkZKsFAo=; b=e+5Bh6nq/G8WhmJKB1UCnf8ju6Ois/hmO7bzqtdH8MBw03ETpIYH85aF3B/WhHKM/q JVargO8TDNyv8XfMor8m12eXGybCejbv/0SgkwbB3f5DjIiuuyf0Q7+Cug35no+DpyRx B78/VDma1e/8iY7nO7rCPQHhhtK6KVPYa4QC3RdNiXUXwyCoN1JQZG1eNYB3JKIn+sD7 +dS1wnCMpdWbERjMe+A89Gs8Zvw39YlVA/qyoeKycd/tGlpuhHwf8NJZwOzaBC/e3NLM T5Z+ko8FFkR4n1/9x0PNUN/bCYF7fh7qj7LD8tVJpP6zbI0tUElVEDnghqINGlgzkx/Q Wo/g== 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=rEgqedKnCHsTU8Y37de2hmte8HKFiWd4b9tNkZKsFAo=; b=jqNT+A/MWnJnYCI+kbQYXT11i+AfFJVtWnww+sOrDkVJHVdPTj5vnUMJqjKH1RKs6B DSwrHxpraG7nmk2ex0J3rozojK2p0eCJBEiQbAITlYhjk6Iqm++QLgM2VDq/pvxIgrDV eU3SK/XV6bRBJSDQcMVLYaXjPKnPdrJ69R+f3gqLrjUHJtuzlTXg4ARppZUpTauv2L3x NpuvWYezwc8DAzJD186xb5xwJh+bwUF7FvoRS4Pddy0W4XAC1LpWuz70EOeoehJCEweR LH6SoJWTlPYoQUfaSO+OIRsFls9k28V1/6cT9S7xJpVqoLcieOeBwLueB6krKbwg9tVz 22Kw== X-Gm-Message-State: AIVw113X0lAssqRlXb5QvHWG5kp+lB3IdvMQkpfNK61uQmPsKdLC5EwA vJ4zSmqaCQpEA0sO0+xMNqlINQ+Wjg== X-Received: by 10.200.13.130 with SMTP id s2mr1038367qti.287.1500483699341; Wed, 19 Jul 2017 10:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.23.139 with HTTP; Wed, 19 Jul 2017 10:01:38 -0700 (PDT) In-Reply-To: References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> From: Abdussalam Baryun Date: Wed, 19 Jul 2017 19:01:38 +0200 Message-ID: To: Thomas Watteyne Cc: "consultancy@vanderstok.org" , "6tisch@ietf.org" <6tisch@ietf.org>, Michael Richardson , "Pascal Thubert (pthubert)" , Ines Robles , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="089e08229fe8e400d70554ae95a0" Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 19 Jul 2017 17:01:42 -0000 --089e08229fe8e400d70554ae95a0 Content-Type: text/plain; charset="UTF-8" +1 On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne wrote: > Thinking about it, I believe it's better to keep draft-munoz-6tisch-examples > as a standalone document. I will be easier to maintain, compared to > splitting the contents across multiple drafts, or worse, replicating the > contents in multiple drafts. > --089e08229fe8e400d70554ae95a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne &l= t;thomas.watt= eyne@inria.fr> wrote:
Th= inking about it, I believe it's better to keep=C2=A0draft-munoz-6tisch-= examples as a standalone document. I will be easier to maintain, compa= red to splitting the contents across multiple drafts, or worse, replicating= the contents in multiple drafts.
--089e08229fe8e400d70554ae95a0-- From nobody Wed Jul 19 10:41:55 2017 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 E507A129461 for ; Wed, 19 Jul 2017 10:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu 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 0nE24Jb0QYIC for ; Wed, 19 Jul 2017 10:41:45 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC64131B39 for ; Wed, 19 Jul 2017 10:41:44 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id y129so3153227pgy.4 for ; Wed, 19 Jul 2017 10:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c3s0DrIpiF3O9r2lUWSphnczUHAThpAVXQfQL92Uk84=; b=XZEYZHUAxdRMB8x1miewa3ibd6NYA7K27emlO6zFMa/sho2Q80Zq23uG0Kxmb9tLRt 60IUCOrIgLKhT/55lwiWG/uQYMNuvg8AA7yj9JddJxrnUSlKUa7KSdYgtmzArdDZpmUv LYHGECE8WQ4Xh/+RU8EudIDlM4irbcyc4fA+M= 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=c3s0DrIpiF3O9r2lUWSphnczUHAThpAVXQfQL92Uk84=; b=bzW+d83u8eursU8Lf2iDQJxSiyx0FujfsKp6767AWPJLrB6uZFWOKDygPUikbgYsVH grcN/5KmB30ZPRJO2FNnZkU5ihiCRx5eJOoEsAu6ybhzDEruQ0fPxLiXblJ2UtSaUu8B zbIjcE9+QNqYk/UoyytiThRNdjhsZB25/FsTc0aO3GyyFkFVs5E0Mw2WBj/xkpXFlbFB tVicQe+dzxGfiTx9iDEzu0WMsSdB4aMmGgxRVUv5AjGwRfLh8zkZPK1q7jO+5wMVO0Vp UMyaVPw7wpM6V9XI7SpDeCBma9eOepDniCUSFyPZ+/bwsRo5PsS9kwe6czt9hoeMWiEA m7Uw== X-Gm-Message-State: AIVw111uCtF6QAtk0lwgTX5WAwcnTcm2FzvH/8tXQbuN/TCAJRyCcNLM kmxTWrqN8JX1r8nuokypeIp5wVZhYvvS X-Received: by 10.84.232.133 with SMTP id i5mr989531plk.240.1500486103864; Wed, 19 Jul 2017 10:41:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.131.87 with HTTP; Wed, 19 Jul 2017 10:41:43 -0700 (PDT) In-Reply-To: <1092432917.892054.1500483740146.JavaMail.root@llavaneres.uoc.es> References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> <1092432917.892054.1500483740146.JavaMail.root@llavaneres.uoc.es> From: Xavi Vilajosana Guillen Date: Wed, 19 Jul 2017 19:41:43 +0200 Message-ID: To: Abdussalam Baryun Cc: Thomas Watteyne , "Pascal Thubert (pthubert)" , "consultancy@vanderstok.org" , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="f4030436195c362d2a0554af25ed" Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 19 Jul 2017 17:41:48 -0000 --f4030436195c362d2a0554af25ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, same opinion here. I am thinking on a developer that needs this to work on the protocol implementation. Having it in a single document is really handy= . regards, X 2017-07-19 19:01 GMT+02:00 Abdussalam Baryun : > +1 > > On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne > wrote: > >> Thinking about it, I believe it's better to keep draft-munoz-6tisch-exam= ples >> as a standalone document. I will be easier to maintain, compared to >> splitting the contents across multiple drafts, or worse, replicating the >> contents in multiple drafts. >> > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --f4030436195c362d2a0554af25ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

same opinion here. I am think= ing on a developer that needs this to work on the protocol implementation. = Having it in a single document is really handy.

re= gards,
X

2017-07-19 19:01 GMT+02:00 Abdussalam Baryun <abduss= alambaryun@gmail.com>:
+1

On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
Thinking about it, I believe it's better to keep=C2=A0draft-= munoz-6tisch-examples as a standalone document. I will be easier to ma= intain, compared to splitting the contents across multiple drafts, or worse= , replicating the contents in multiple drafts.

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



--
=
3D"Universitat=C2=A0=C2=A0=
=C2=AD
--f4030436195c362d2a0554af25ed-- From nobody Wed Jul 19 13:47:48 2017 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 CC1AB1270A3 for ; Wed, 19 Jul 2017 13:47:46 -0700 (PDT) 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 w03YVIaC_AxN for ; Wed, 19 Jul 2017 13:47:45 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034B212702E for ; Wed, 19 Jul 2017 13:47:44 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h199so6732132ith.1 for ; Wed, 19 Jul 2017 13:47:44 -0700 (PDT) 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=GaYLdbXa7fsd40TbTj1LNPFWELmEsqTgvTMgf1w2gO8=; b=IPRuRQ3x1TJ7DwOpF1OnCNtJ1jO6Luax9MybAb6ML1ZRHKLdFfokVOQkcNnOwr/ta/ +K0/VYy0Oxlrcv8G7ilL2oY7jCHnZ7+XE9Z859NL7fBaEV4WPd53mhXclbkwLkcJ4pYI e8ImAMX+olbaat6mWcuWzRpMnZwvB5wYPR+pO4tzHmEWODO4dQ2zrsAUuaYcu1m3/GaW ni+Xp3sK9+ldK6DzPIoECL6MZ4XdzHBzZoHCi1z9YGj4DXUrUnVuClgUFZWQcHfjXoz4 HhY6At3auOtMidpMNLzKc1xP7c8aryzgE56U4N+Q4vMtYhXpTf8ILDIjxfSuYo4J//es lIAg== 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=GaYLdbXa7fsd40TbTj1LNPFWELmEsqTgvTMgf1w2gO8=; b=UjCAy4VYmtwfsGQB/ATAFcP4/EQj37XCnbIAYeMNs+uH8rb6xRHlx9itefLjD/PDqQ 2wP4KxJ2foil2n0OTTswzqxU44MxshkkyEtpT0Id3J7h0+Qni1BrKkMiFL1vItFlaTkb BjAx7mFmGTjibztq5bLkXV/G4GgkbeB/IQWANgGWEvoZtbHaMC8haeptknsOG1BfhQX3 EEXvLF8JDfZhKFuPXnEUh+cdCe/0zeEdGLXaRJFmJHXlNNyFy5kKJEkXEEfdrCpZ/pxZ 2QDCrZTg0jEE9sH3IbNyZfD9a9qAlrcsCbTcYC5Ww2jw0I7MinqKx8KgJ5X2D6UvsKcl SiEw== X-Gm-Message-State: AIVw113+A6eJ9PwdmB1EJEDaMpAEUoWAnhwO5OUFLwh4ddQieSl06ws2 oW+MVQZiHJgypD6/9geelu46xxduZtm/ X-Received: by 10.36.105.82 with SMTP id e79mr1278096itc.118.1500497264210; Wed, 19 Jul 2017 13:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Wed, 19 Jul 2017 13:47:43 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Wed, 19 Jul 2017 22:47:43 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a1145a6b66b7f750554b1bedc" Archived-At: Subject: Re: [Roll] Slides IETF 99 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, 19 Jul 2017 20:47:47 -0000 --001a1145a6b66b7f750554b1bedc Content-Type: text/plain; charset="UTF-8" Hi, Please find an updated version of the slides. https://www.ietf.org/proceedings/99/slides/slides-99-roll-03-00.pdf Cheers, I & P 2017-07-19 15:10 GMT+02:00 Ines Robles : > Dear all, > > Please find a new version of the slides > > https://www.ietf.org/proceedings/99/slides/slides- > 99-roll-ietf99_roll_slides_02-00.pdf > > Cheers > > Ines + Peter > > > 2017-07-17 11:27 GMT+02:00 Ines Robles : > >> Hi, >> >> Please find a draft version of the slides for IETF 99 >> >> https://www.ietf.org/proceedings/99/slides/slides-99-roll- >> ietf_99_roll_slides_v1-01.pdf >> >> Comments welcome, >> >> Thanks, >> >> Ines + Peter >> > > --001a1145a6b66b7f750554b1bedc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find an updated version of t= he slides.


Cheers,<= /div>

I & P
2017-07-19 15:10 GMT+02:00 Ines Robles <mariainesrobles@googlemail.com>:
Dear all,

Ple= ase find a new version of the slides

<= br>
Cheers

Ines + Peter


2017-07-17 11:27 GM= T+02:00 Ines Robles <mariainesrobles@googlemail.com= >:
Hi,

Please find a draft version of the slides f= or IETF 99


Comments welcom= e,

Thanks,

Ines + Peter


--001a1145a6b66b7f750554b1bedc-- From nobody Wed Jul 19 22:32:13 2017 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 4664512783A for ; Wed, 19 Jul 2017 22:32:12 -0700 (PDT) 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 IIzM-w5keMYw for ; Wed, 19 Jul 2017 22:32:10 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB065126B6E for ; Wed, 19 Jul 2017 22:32:09 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud2.xs4all.net with ESMTP id mtY71v00Z25pRQy01tY7DA; Thu, 20 Jul 2017 07:32:07 +0200 Received: from 2001:67c:1232:144:7d47:b574:f1e2:2616 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Jul 2017 07:32:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Jul 2017 07:32:07 +0200 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: References: Message-ID: <9e19b605c986699c48678827cd7550e2@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] Slides IETF 99 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, 20 Jul 2017 05:32:12 -0000 great, thanks Ines Ines Robles schreef op 2017-07-19 22:47: > Hi, > > Please find an updated version of the slides. > > https://www.ietf.org/proceedings/99/slides/slides-99-roll-03-00.pdf > > Cheers, > > I & P > > 2017-07-19 15:10 GMT+02:00 Ines Robles > : > >> Dear all, >> >> Please find a new version of the slides >> >> > https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99_roll_slides_02-00.pdf >> [2] >> >> Cheers >> >> Ines + Peter >> >> 2017-07-17 11:27 GMT+02:00 Ines Robles >> : >> >>> Hi, >>> >>> Please find a draft version of the slides for IETF 99 >>> >>> >> > https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf_99_roll_slides_v1-01.pdf >>> [1] >>> >>> Comments welcome, >>> >>> Thanks, >>> >>> Ines + Peter > > > > Links: > ------ > [1] > https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf_99_roll_slides_v1-01.pdf > [2] > https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99_roll_slides_02-00.pdf > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Jul 20 02:46:09 2017 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 D3736131667 for ; Thu, 20 Jul 2017 02:46:07 -0700 (PDT) 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 W4hJZ8wsy6A5 for ; Thu, 20 Jul 2017 02:46:06 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 252AB12ECCB for ; Thu, 20 Jul 2017 02:46:06 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q2so9639210ioe.3 for ; Thu, 20 Jul 2017 02:46:06 -0700 (PDT) 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=pkoj4Tdft1FC9fS7vwRrzzqD0d0Ui5S5eMCXU0wVG1E=; b=Dy8KlxowAmZNojFsfJ9GHudNZ9vo3EDiW4uwTOdyLvHBCqNwI3wOkC0wXEpVjkbtWx ENHVw+cjr9sK4+ZRxSilUeeWtAvBo/Mhwr/fKcEYB76938WdtKxCguhGAFeY9CgiYkZa o2HYTKUba+oMtubaggiUxkSd4R/4dZDlqoW+cbY/2zSzWBE692k6rd87WKQIy/UwUva9 e8GeSU3FxhNfinO8FIwCmVUPqGFOAKFv1Pg7q2XFtbZ3q5vFOmfLza0DaZl+NX2Dvspf EPHLHistPEzCOh4H3UVXHdBx5u0rMBGLPjxieAegMYuBJ+IvPrbEK4urVpkaUojPbTWQ nkKg== 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=pkoj4Tdft1FC9fS7vwRrzzqD0d0Ui5S5eMCXU0wVG1E=; b=Rm7qmCGJsls+JirfyON/jVjMOmGk/5gjokSfUyUFmGJD6ILfGjpKxn3bIvO79Y8fSK u7QniLldl2PQ5r81380Pz47yMVpXwojpVhdmegpVk300gZQUoGH8heTvUp+c3wOrWfHe aMRR0LQ3aLnRGWGwtGN3btFLOIfNlMSlqCeQa6RycWh3A5MGKGvQ10LLWSeKeYbFuCC7 Zc18S9LSc9qNfHSWrpKEzhGch5jdZFGCfVrJJC/1KQEGGt5D0ZkAN78n/M9HsIvsP1V5 ULlwgLaCqXEMmkkqRrXifd35/imN+DBs/Mvuh+fo5vhq6UD6UvxK32aGzUkmnfMgoySE OEmQ== X-Gm-Message-State: AIVw111h6wOnt+uWvuc/RwYGGOllQWbOxUIjz0zAUdL2BBooYspg2VLz sP6MqNxPeo9eXHkIq85WYppO0FORVE5t X-Received: by 10.107.18.196 with SMTP id 65mr2375192ios.64.1500543965377; Thu, 20 Jul 2017 02:46:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Thu, 20 Jul 2017 02:46:04 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Thu, 20 Jul 2017 11:46:04 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a113f327c06c4780554bc9eed" Archived-At: Subject: Re: [Roll] Slides IETF 99 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, 20 Jul 2017 09:46:08 -0000 --001a113f327c06c4780554bc9eed Content-Type: text/plain; charset="UTF-8" Hi, Please find an updated version (04) of the slides. https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99_roll_slides_04-00.pdf Cheers, I & P 2017-07-19 22:47 GMT+02:00 Ines Robles : > Hi, > > Please find an updated version of the slides. > > https://www.ietf.org/proceedings/99/slides/slides-99-roll-03-00.pdf > > Cheers, > > I & P > > 2017-07-19 15:10 GMT+02:00 Ines Robles : > >> Dear all, >> >> Please find a new version of the slides >> >> https://www.ietf.org/proceedings/99/slides/slides-99-roll- >> ietf99_roll_slides_02-00.pdf >> >> Cheers >> >> Ines + Peter >> >> >> 2017-07-17 11:27 GMT+02:00 Ines Robles : >> >>> Hi, >>> >>> Please find a draft version of the slides for IETF 99 >>> >>> https://www.ietf.org/proceedings/99/slides/slides-99-roll-ie >>> tf_99_roll_slides_v1-01.pdf >>> >>> Comments welcome, >>> >>> Thanks, >>> >>> Ines + Peter >>> >> >> > --001a113f327c06c4780554bc9eed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find an updated version (04)= of the slides.


Cheers,

I &= P

2017-07-1= 9 22:47 GMT+02:00 Ines Robles <mariainesrobles@googlemail.co= m>:
Hi,
Please find an updated version of the slides.

Che= ers,

I & P

2= 017-07-19 15:10 GMT+02:00 Ines Robles <mariainesrobles@googl= email.com>:
Ines + Peter


--001a113f327c06c4780554bc9eed-- From nobody Thu Jul 20 05:58:55 2017 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 82CB012704A for ; Thu, 20 Jul 2017 05:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FJM3E-SkdE0D for ; Thu, 20 Jul 2017 05:58:52 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 0BA72126E3A for ; Thu, 20 Jul 2017 05:58:52 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id d29so12787594uai.2 for ; Thu, 20 Jul 2017 05:58:51 -0700 (PDT) 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=J2UaWfV7ZEsqKWO7EfCBHQpjEn7lmzPv0CjgaXLwrJU=; b=o6NoG+16rwJonXgtZagvb/HtXf648NlN56bNR6nSN9Qd4Rnh1pdPMeYDFeQv2OhakJ LMmK/oQ2cO3W+mCjaaFpR7VRiY0cd6Aawr8NXrEQ63dB4kLU4uxPjWYnnjY8tdQyLJUK DiA/xtUIFsiRuHWkw/NILD30hG7LHKj0vOkMAGdn1OOI2lCBP4wwckUqMcEB8CIGyjoe CFY2Xw8DMX7thiDV6IFYLdlRAgmTJPSRHxJe5vV7V3u8kaAQyJ8hDVP+pJAqDoxIlJm1 x+rb8NNxQhnC4pdo207q2lV8GHu6UwxM/neBSxnrRp+fsW82lFlZeba/3rlHrrXMSPbL UmGw== 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=J2UaWfV7ZEsqKWO7EfCBHQpjEn7lmzPv0CjgaXLwrJU=; b=tTXmc9ClHuE182zn9UVXDiFMUq/ZTTy4gOz+0dGkMrcBaghVHPZPssUKQgSa/u4aiE rqD7mBaBp9mVPCEvWVnBU1ru+O/VogyekFi3Xuz92TQBHJozmRwmoUE+HyJi4y7xd1Lb vnaGk0MAutoSga+lb7aPjRFzkHq+0SwKeupHWuCepMkq4ExTKQnjc2K9ZD/57qJ3v9C5 rcBUR1hLc6HUYUU5AD2L5qq6OfhZV+5/d4u/yUk0lSr7PDzbyvyrv7idu+Z3q/EHRyT1 C4z+A7NHqux9aVexCHJ3VK/LtVoDuAvYmj/ykQLJlaYat7UT9/It7xZhkYRAaLUtt2wc NjuA== X-Gm-Message-State: AIVw112Y5/OjiF5B2EEr+ouoSSliVr70mvsExQ8t5wDgQ3uqOHg+nRx1 OgAW3u75i5SNp9DoJ0sxYpcdm6C3OA== X-Received: by 10.176.71.82 with SMTP id i18mr2306411uac.171.1500555530836; Thu, 20 Jul 2017 05:58:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.71 with HTTP; Thu, 20 Jul 2017 05:58:50 -0700 (PDT) From: Rahul Jadhav Date: Thu, 20 Jul 2017 14:58:50 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="f403045e6328619fe50554bf4f93" Archived-At: Subject: [Roll] 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: Thu, 20 Jul 2017 12:58:54 -0000 --f403045e6328619fe50554bf4f93 Content-Type: text/plain; charset="UTF-8" Hi Charlie, I checked the backup slides and found comparison between Default RPL and AODV-RPL for P2P traffic ... I feel its not fair to compare between these two, since by design default RPL is optimised for MP2P/P2MP traffic ... I suggest to do the comparison between P2P-RPL and AODV-RPL. Regards, Rahul --f403045e6328619fe50554bf4f93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Charlie,

I checked the backup slides= and found comparison between Default RPL and AODV-RPL for P2P traffic ... = I feel its not fair to compare between these two, since by design default R= PL is optimised for MP2P/P2MP traffic ... I suggest to do the comparison be= tween P2P-RPL and AODV-RPL.

Regards,
Rah= ul
--f403045e6328619fe50554bf4f93-- From nobody Fri Jul 21 00:26:37 2017 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 404D7129A92 for ; Fri, 21 Jul 2017 00:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7S9v5jbRvDlK for ; Fri, 21 Jul 2017 00:26:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF6E12714F for ; Fri, 21 Jul 2017 00:26:34 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 206A71F8F6; Fri, 21 Jul 2017 07:26:32 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E070F14E3; Fri, 21 Jul 2017 09:26:20 +0200 (CEST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: Ines Robles In-reply-to: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Tue, 18 Jul 2017 13:23:39 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 09:26:20 +0200 Message-ID: <25395.1500621980@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] rplinfo 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, 21 Jul 2017 07:26:36 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> - it may issue DAO and DIS messages. A leaf node accepts DIO messages >> though it generally ignores DAO and DIS messages (not applied in our >> case) >> > A leaf node accepts DIO messages and is thus RPL-aware in my > understanding; There are two definitions perhaps. RFC6550 says situations in which an RPL-aware node MUST join as a leaf node because it does not speak the correct MOP, or other situations. But, it doesn't actually say what it means to be a leaf node. A leaf node is a node that join using Router Advertisements only. A leaf node is what we normally have called a "host". Only in the situation where it was an incompatible 6550 implementation would the leaf understand RPI. There are potentially many leaf nodes that would join a LLN via RA, etc. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZcaycAAoJEJVM4Vb9/EKQzlIIAI0AOfAND9h5HcESYP1Vtmbs NpG1eLMinMzUFkyp7pOVnxQVNXUoxVqYK95H13/7627JGsIOkppUYJv7JQX6EGPf NYzBx/qNU9ZwfcJbYodqTkl7uXXe+z9gZAvW95o3dMlW1efKoQJ2JAKwN17pz8J4 qCCg8fHOUmFEFRPl1qgT+a7a5zv677xBDZ576auuAzxT0Es98x6zvO/vqzeO8UBo Z3E6bhVrwDmUuLUZGCEbDdtJc+9iUJFZopHK5PI+OduseiXHsLf/kAi3wMYbc2vr wzADQZCnQkoh/tnfxOTQypxCKjpMt4Qw7f0WZ13803GrLVoHNqqTGiv/1xKy1Vg= =DU38 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 01:08:00 2017 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 0A819131AA9; Fri, 21 Jul 2017 01:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n1FAXao6SRcC; Fri, 21 Jul 2017 01:07:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF05C12EB2B; Fri, 21 Jul 2017 01:07:56 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id D0D1B1F8F6; Fri, 21 Jul 2017 08:07:52 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 893011626; Fri, 21 Jul 2017 10:07:43 +0200 (CEST) From: Michael Richardson To: Routing Over Low power and Lossy networks , "6tisch\@ietf.org" <6tisch@ietf.org> In-reply-to: References: <65ebd4a8922641c33865871d76e94c10@xs4all.nl> Comments: In-reply-to Thomas Watteyne message dated "Wed, 19 Jul 2017 15:46:46 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 10:07:43 +0200 Message-ID: <27605.1500624463@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft 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, 21 Jul 2017 08:07:58 -0000 --=-=-= Content-Type: text/plain Thomas Watteyne wrote: > Thinking about it, I believe it's better to keep > draft-munoz-6tisch-examples as a standalone document. I will be easier > to maintain, compared to splitting the contents across multiple drafts, > or worse, replicating the contents in multiple drafts. I don't mind leaving it seperate. I suggest that a well curated wiki would work best here, at least in the short term. Given that the IESG is pulling back on the number of non-standards track documents they want to process, I think that would better. But perhaps we will still want to grab a few example packets both uncompressed and compressed for useofrplinfo. (There is a reason to implement uncompressed RPI, which is because you extend the RPL DODAG across non-constrained media) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZcbZPAAoJEJVM4Vb9/EKQb0oH/1DsEf4wn9UcFQUKUyd5FgsU CMncdKKjWQ5U/sxU6BEchraP7ms2oru9w5JjKaXRp5j9KvchNZmeEtEmaUKmzWoO x41eYzMUE6m+2movngV8z+AW13pUwRAwnHe7FK0BeP4kSk/oWYI2Y+k+w1ckE5bD +Tilkud1noWJdq3GlhLG5ftuWMn4bNWy18VlfnYgZ2uW82gE12/lm6HYG0dy3Rm4 iZx0iJh3vSwaK7Zo2m/RWHNlxwmBftA7EqI67ddOcumvTHe7sh7U0giHcOHcfMvi wlO4scc9pV0/zdaBm95zh+4SVa45TmsYjFPwWuU0iHqLYJG9L7i65IA/NI6ZgMo= =o66N -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 01:15:06 2017 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 89D0712EC51 for ; Fri, 21 Jul 2017 01:15:05 -0700 (PDT) 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 Z5PRripEXw4n for ; Fri, 21 Jul 2017 01:15:03 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A9912EB2B for ; Fri, 21 Jul 2017 01:15:03 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud2.xs4all.net with ESMTP id nLF11v0084CWAV301LF1zx; Fri, 21 Jul 2017 10:15:01 +0200 Received: from 2001:67c:370:128:fd9d:1fa:b33e:78d5 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 21 Jul 2017 10:15:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 21 Jul 2017 10:15:01 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: Ines Robles , Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <25395.1500621980@dooku.sandelman.ca> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <25395.1500621980@dooku.sandelman.ca> Message-ID: <186acf2e5068c3417520bc21178f31d0@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] rplinfo 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, 21 Jul 2017 08:15:05 -0000 > There are two definitions perhaps. RFC6550 says situations in which > an RPL-aware node MUST join as a leaf node because it does not speak > the > correct MOP, or other situations. But, it doesn't actually say what > it means to be a leaf node. > > A leaf node is a node that join using Router Advertisements only. > A leaf node is what we normally have called a "host". Only in the > situation where it was an incompatible 6550 implementation would > the leaf understand RPI. There are potentially many leaf nodes that > would join a LLN via RA, etc. IMO it is good to make that clear in the document and explain the difference between RA leaves and DODAG leaves Peter From nobody Fri Jul 21 01:38:13 2017 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 845B0129B55 for ; Fri, 21 Jul 2017 01:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, RP_MATCHES_RCVD=-0.001, 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 aYQrnQT7Art4 for ; Fri, 21 Jul 2017 01:38:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E50A131748 for ; Fri, 21 Jul 2017 01:38:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRR68028; Fri, 21 Jul 2017 08:38:02 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Jul 2017 09:38:00 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.222]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Fri, 21 Jul 2017 16:37:42 +0800 From: houjianqiang To: "roll@ietf.org" Thread-Topic: Key points of draft-hou-roll-rpl-parent-selection Thread-Index: AdMAiqRkE8PSYNJxTuWXeakLbnfOTQBcfm5d Date: Fri, 21 Jul 2017 08:37:42 +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: Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086A4BC89DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5971BD6A.00EB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.222, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ba398f3df03de757baa41053b0e629ca Archived-At: Subject: Re: [Roll] Key points of draft-hou-roll-rpl-parent-selection 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, 21 Jul 2017 08:38:06 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C086A4BC89DGGEMM506MBSchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgcmVjZWl2ZWQgc29tZSBmZWVkYmFjayBhZnRlciB0aGUgbWVldGlu Zy4gRm9sbG93aW5nIGFyZSBzb21lIHF1ZXN0aW9ucyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgYW5z d2VyczoNCg0KMS4gICAgICBJcyB0aGlzIENOQyBtZXRyaWMgb25seSB1c2VkIGZvciBsZWFmIG5v ZGVzPw0KTm8uIENOQyBtZXRyaWMgY2FuIGJlIHVzZWQgZm9yIGFsbCBub2RlcyBpbiBhIFJQTCBu ZXR3b3JrLiBPbmUtaG9wIGNoaWxkcmVuIChkaXJlY3QgY2hpbGRyZW4pIGFyZSBjb3VudGVkIGZv ciBlYWNoIHBhcmVudCBub2RlLCBidXQgdGhlcmUgY2FuIGJlIGxvdHMgb2YgZ3JhbmRjaGlsZCBu b2RlcyBpbiB0aGUgZG93bnN0cmVhbS4gV2UgYWltIGF0IHRoZSBuZXR3b3JrIHdpdGggbXVsdGlo b3BzLg0KDQoyLiAgICAgIFdoeSBub3QgdXNlIG90aGVyIG1ldHJpY3MsIGUuZy4gdGhyb3VnaHB1 dCwgYXMgcmVwbGFjZW1lbnQ/DQpJbiB0aGUgc21hcnQgbWV0ZXIgc2NlbmFyaW8sIGVhY2ggbm9k ZSB1cGxvYWQgZGF0YSBvbmNlIHBlciBkYXkgb3IgcGVyIG1vbnRoLCBpdCB0YWtlcyBsb25nIHRp bWUgZm9yIG5vZGVzIHRvIGNhbGN1bGF0ZSB0aHJvdWdocHV0IGFuZCBvdGhlciBtZXRyaWNzLiBJ ZiBDTkMgaXMgdXNlZCwgdGhlIGJhbGFuY2VkIG5ldHdvcmsgY2FuIGJlIGZvcm1lZCBmcm9tIHRo ZSB2ZXJ5IGJlZ2lubmluZy4NCg0KMy4gICAgICBXaHkgY2FsY3VsYXRlIHRoZSBkaXJlY3QgY2hp bGRyZW4gcmF0aGVyIHRoYW4gdGhlIHRvdGFsIG51bWJlciBvZiBjaGlsZHJlbj8NClRvdGFsIG51 bWJlciBvZiBjaGlsZHJlbiB3YXMgY29uc2lkZXJlZCBwcmV2aW91c2x5LCBhbmQgdGhlIGRvd253 YXJkIHJvdXRpbmcgdGFibGUgY2FuIGJlIHVzZWQgZm9yIHRoaXMgY2FsY3VsYXRpb24uIEJ1dCBp ZiB0b3RhbCB0aGUgbnVtYmVyIG9mIGNoaWxkcmVuIGlzIHVzZWQsIG5ldyBqb2luaW5nIGRvd25z dHJlYW0gbm9kZXMgd2lsbCBoYXZlIGFuIGVub3Jtb3VzIGltcGFjdCBvbiB0aGUgdXBzdHJlYW0g Y29ubmVjdGlvbiwgdGhlbiBpdCB3aWxsIHRha2UgbG9uZyBsb25nIHRpbWUgZm9yIHRoZSBuZXR3 b3JrIHRvIGJlIHN0YWJsZS4gQWxzbywgdGhlIGNvbXB1dGluZyBvZiB0b3RhbCBudW1iZXIgb2Yg Y2hpbGRyZW4gYWx3YXlzIGV4aXN0cyB0aW1lIGRlbGF5Lg0KDQo0LiAgICAgIFdoeSBmb2N1cyBv biB0aGlzIG5hcnJvdyB0b3BpYz8NClRoZSBSUEwgbmV0d29yayB3aXRoIGh1bmRyZWRzLCB0aG91 c2FuZHMgb2Ygbm9kZXMgaGF2ZSBub3QgYmVlbiB3ZWxsIHN0dWRpZWQgYnV0IHRoZXJlIGFyZSBh bHJlYWR5IHN1Y2ggdXNpbmcgc2NlbmFyaW9zIGluIGRhaWx5IGxpZmUuIEFuZCBtb3Jlb3Zlciwg bm9kZXMgYXJlIGFsbW9zdCB0aGUgc2FtZSBpbiB0aGVzZSBzY2VuYXJpb3MsIGNvbXB1dGluZyBh Y3R1YXRlIHRyYWZmaWMgbG9hZCB0YWtlcyBsb25nZXIgdGltZS4gQ05DIG1ldHJpYyBpcyBlbm91 Z2gsIHNpbXBsZSBhbmQgZWZmZWN0aXZlLg0KDQpDaGVlcnMsDQpKaWFucWlhbmcNCg0Kt6K8/sjL o7ogaG91amlhbnFpYW5nDQrK1bz+yMujuiByb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYu b3JnPg0K1vfM4qO6IEtleSBwb2ludHMgb2YgZHJhZnQtaG91LXJvbGwtcnBsLXBhcmVudC1zZWxl Y3Rpb24NCsqxvOSjuiAyMDE3LTA3LTE5IDE0OjI5OjE5DQoNCkRlYXIgYWxsLA0KDQpJIGFtIGdv aW5nIHRvIHByZXNlbnQgbXkgZHJhZnQgPGRyYWZ0LWhvdS1yb2xsLXJwbC1wYXJlbnQtc2VsZWN0 aW9uLTAwPiBpbiBSb2xsIFdHLiBUaGUgc2xpZGVzIGFyZSBvbmxpbmUgbm93LiBUbyBtYWtlIGl0 IGVhc2llciBmb3IgeW91IHRvIHVuZGVyc3RhbmQgaXQsIGJlbG93IGFyZSBzb21lIGtleSBwb2lu dHMgaW4gdGhlIHByZXNlbnRhdGlvbjoNCg0KSXNzdWU6IFJhbmRvbWx5IFVuYmFsYW5jZWQgTmV0 d29ya2luZw0KDQpHb2FsOiBiYWxhbmNpbmcgdGhlIG51bWJlciBvZiBjaGlsZCBub2Rlcw0KDQpQ b3NzaWJsZSB1c2luZyBzY2VuYXJpbzogU21hcnQgTWV0ZXJzDQoNClNvbHV0aW9uOg0KDQoxLg0K IENvbXB1dGUgdGhlIE51bWJlcl9vZl9DaGlsZHJlbiBmcm9tIE5laWdoYm9yIFRhYmxlIChOZWln aGJvciBDYWNoZSBFbnRyeSkNCg0KMi4NCiBTdG9yZSB0aGUgTnVtYmVyX29mX0NoaWxkcmVuIGlu IGEgbmV3IE1ldHJpYywgYW5kIHNlbmQgaXQgdG8gZG93bnN0cmVhbSBub2RlcyB3aXRoIERJTw0K DQozLg0KIERvd25zdHJlYW0gbm9kZXMgY2hvb3NlIHBhcmVudCBub2RlIGJhc2VkIG9uIE51bWJl cl9vZl9DaGlsZHJlbg0KDQo0Lg0KIENvbWJpbmUgdGhlIE51bWJlcl9vZl9DaGlsZHJlbiB3aXRo IG90aGVyIG1ldHJpY3MvY29uc3RyYWludHMNCg0KVGhlIGRldGFpbHMgb2YgY29tcHV0aW5nIHRo ZSBOdW1iZXJfb2ZfQ2hpbGRyZW4gYXJlIHJlbGF0ZWQgdG8gdGhlIG5laWdoYm9yIHRhYmxlIG1h bmFnZW1lbnQsIGFuZCBSYWh1bCBoYXMgZ2l2ZW4gYSBnb29kIGlsbHVzdHJhdGlvbiBpbiA8ZHJh ZnQtamFkaGF2LWx3aWctbmJyLW1nbXQtcG9saWN5LTAwPi4gVGhlIGNoaWxkIHJlZ2lzdGVyL2Rl cmVnaXN0ZXIgaW4gcGFyZW50oa9zIE5DRSBhY2NvcmRpbmcgdG8gREFPL05QREFPDQogKHN0b3Jp bmcgbW9kZSkgb3IgTlMrQVJPL05TK0FST18wbGZ0aW1lIChub24tc3RvcmluZyBtb2RlKS4NCg0K Q2hlZXJzLA0KSmlhbnFpYW5nDQo= --_000_DD0A994E4D6B3F4080662703C8C7C086A4BC89DGGEMM506MBSchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have received some feedback after the = meeting. Following are some questions and the=  corresponding answers:
 
1.      Is this CNC metric&nbs= p;only used for leaf nodes?
No. CNC metric can be used for all = nodes in a RPL network. One-hop children = ;(direct children) are counted for each paren= t node, but there can be lots of gr= andchild nodes in the downstream. We aim = ;at the network with multihops.  
 
2.      Why not use other = ;metrics, e.g. throughput, as replacement?
In the smart meter scenario, each node u= pload data once per day or per month,&nb= sp;it takes long time for nodes to calcu= late throughput and other metrics. If CNC&nbs= p;is used, the balanced network can be f= ormed from the very beginning. 
 
3.      Why calculate the dire= ct children rather than the total number = ;of children?
Total number of children was considered previ= ously, and the downward routing table can&nbs= p;be used for this calculation. But if t= otal the number of children is used, new=  joining downstream nodes will have an e= normous impact on the upstream connection, th= en it will take long long time for = the network to be stable. Also, the comp= uting of total number of children always = ;exists time delay.
 
4.      Why focus on this = ;narrow topic?
The RPL network with hundreds, thousands of&n= bsp;nodes have not been well studied but = ;there are already such using scenarios in&nb= sp;daily life. And moreover, nodes are almost=  the same in these scenarios, computing = actuate traffic load takes longer time. CNC&n= bsp;metric is enough, simple and effective.
 
Cheers,
Jianqiang

=B7=A2=BC=FE=C8=CB=A3=BA houjianqiang
=D6=F7=CC=E2=A3=BA Key points of draft-hou-roll-rpl-parent-sele= ction
=CA=B1=BC=E4=A3=BA 2017-07-19 14:29:19

Dear all,

I am going to present my draft <draft= -hou-roll-rpl-parent-selection-00> in Roll WG. The&n= bsp;slides are online now. To make it ea= sier for you to understand it, below are=  some key points in the presentation:

Issue: Randomly Unbalanced Networking

Goal: balancing the number of child nodes

Possible using scenario: Smart Meters

Solution:

1.      
 Compute the Number_of_Children from Neighbor = ;Table (Neighbor Cache Entry)

2.      
 Store the Number_of_Children in a new M= etric, and send it to downstream nodes w= ith DIO

3.      
 Downstream nodes choose parent node based&nb= sp;on Number_of_Children

4.      
 Combine the Number_of_Children with other me= trics/constraints

The details of computing the Number_of_Children&nb= sp;are related to the neighbor table manageme= nt, and Rahul has given a good illustrat= ion in <draft-jadhav-lwig-nbr-mgmt-policy-00>. The&nbs= p;child register/deregister in parent=A1=AFs NCE a= ccording to DAO/NPDAO
 (storing mode) or NS+ARO/NS+ARO_0lftime (= non-storing mode). 

Cheers,
Jianqiang
--_000_DD0A994E4D6B3F4080662703C8C7C086A4BC89DGGEMM506MBSchina_-- From nobody Fri Jul 21 02:19:13 2017 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 4B5BE129A96 for ; Fri, 21 Jul 2017 02:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ChFYMgaO44k8 for ; Fri, 21 Jul 2017 02:19:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2BA126D46 for ; Fri, 21 Jul 2017 02:19:09 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 278291F8F6 for ; Fri, 21 Jul 2017 09:19:08 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D313B1662; Fri, 21 Jul 2017 11:18:58 +0200 (CEST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <186acf2e5068c3417520bc21178f31d0@xs4all.nl> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <25395.1500621980@dooku.sandelman.ca> <186acf2e5068c3417520bc21178f31d0@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Fri, 21 Jul 2017 10:15:01 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 11:18:58 +0200 Message-ID: <32276.1500628738@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] rplinfo 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, 21 Jul 2017 09:19:11 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> There are two definitions perhaps. RFC6550 says situations in which >> an RPL-aware node MUST join as a leaf node because it does not speak >> the correct MOP, or other situations. But, it doesn't actually say >> what it means to be a leaf node. >> >> A leaf node is a node that join using Router Advertisements only. A >> leaf node is what we normally have called a "host". Only in the >> situation where it was an incompatible 6550 implementation would the >> leaf understand RPI. There are potentially many leaf nodes that would >> join a LLN via RA, etc. > IMO it is good to make that clear in the document and explain the > difference between RA leaves and DODAG leaves But, when an RPL aware node is forced into a leaf position (due to incompatibility), it does so using RAs, etc. so it really has no effect on the considerations. A storing-mode only RPL node, upon encountering a non-storing mode DODAG, might join as a leaf, but might *not* understand RH3 headers. So rather than explain that there is a difference, I think we should just explain that they are leaves. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEbBAEBAgAGBQJZcccCAAoJEJVM4Vb9/EKQyAgH+MlVc2/2Vczz4Tpxw3qecM9M HqmF5hX0UL/g5oE/ya8QSA6JGDu3kRdww/rO5mJOrR+7YthZ0u3ECO6CdRtG6RgV V/rTp3Vcxz9n1/MqXtb2EjYPJ7oHhR4wYUmIKUqH2FbArwlwUXPYRvPTvFO1v1Wf NkY42/vMQB0ygbxM/OGUvz57FpqMTYKR56ehH22DMTSye0uPelCzXtX4jjHdwC8t 4ek41yP4wh0QGyISCLw9outSYfMe4Hsdp2Jc+rc5P6PeBCJaWIjic7Rrxm/TS6nh v9M/CIu/Ns+4UhI04dBzQERjuRcZyCnDB/yxx5Z/w2EoifPNOnQeEzvHfeXpEQ== =MCbQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 02:23:07 2017 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 DF74C127869 for ; Fri, 21 Jul 2017 02:23:05 -0700 (PDT) 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 viZsTZnzbXAF for ; Fri, 21 Jul 2017 02:23:04 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E8F129A96 for ; Fri, 21 Jul 2017 02:23:04 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud2.xs4all.net with ESMTP id nMP21v00G4CWAV301MP2d8; Fri, 21 Jul 2017 11:23:02 +0200 Received: from 2001:67c:370:128:fd9d:1fa:b33e:78d5 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 21 Jul 2017 11:23:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 21 Jul 2017 11:23:02 +0200 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: <32276.1500628738@dooku.sandelman.ca> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <25395.1500621980@dooku.sandelman.ca> <186acf2e5068c3417520bc21178f31d0@xs4all.nl> <32276.1500628738@dooku.sandelman.ca> Message-ID: <236fed0b3ea960392c6de0f09effeecb@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] rplinfo 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, 21 Jul 2017 09:23:06 -0000 > So rather than explain that there is a difference, I think we should > just > explain that they are leaves. > The document makes a difference between raf and ~raf. Explaining they are leaves in the 2 protocols (ND and RPL) is then the solution? Peter From nobody Mon Jul 24 04:04:15 2017 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 8C18C131C51 for ; Mon, 24 Jul 2017 04:04:13 -0700 (PDT) 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 OJJ0_5aZFidt for ; Mon, 24 Jul 2017 04:04:11 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 0C741131C8B for ; Mon, 24 Jul 2017 04:04:10 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id c74so41590660iod.4 for ; Mon, 24 Jul 2017 04:04:10 -0700 (PDT) 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=WaY1WcI6C6Ho9QiUikDLuTGv3Ymhwq79g+QNCqvl/eg=; b=M/hzuuk61z5QC8D7hvTCdtfGTcnpscBX9TtGFjKRywvc6PW8OyqT0O3NpWyViKgrBq MoVno3q19bCpgCv15oyONmzfx9MLsrhR5XlsTmdkmLtT48aD+CnRq+UROeYDua7NrzXx K/Zu1NdOnDbQIXPhkWfliobFYrbHWi2lNM5kqMP56vygL2Jael7wxPgvgFI0XNEHKKXj Lxf9HYfLeLKYXl/bZwYCppFCmg1jPoRTzP0E4R5O7IVBJIJ9/pizlOYGgEuY/M69VODQ 4I297gDpnh1ylAjZ/Bw/DpinRJehr4qLjHeqNbWXCIvfngPHfTmUlb39F7xkF99cy+XJ c8Ng== 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=WaY1WcI6C6Ho9QiUikDLuTGv3Ymhwq79g+QNCqvl/eg=; b=Ql53d427aOjeey0jooTy93rlF3v0ynCmO7Y8E9uDyOpjXWRnrZwuCAXP5L/unNXDix T07HaBVk5hpU4zFlkDWCWMQyAr/CAmX0dtmI3i5zqeM6GbknAr9iBT98j2MTVkhGvfYL X2RQ55hgl1J2js0eOPg76hSMbOlHEUEYHr644rJmH66iAZMU7tykB5zERJUEAcaCg1gX aXjc+lbAmK+GCGJbt40XF0x2JHpE+BvCdN5dR3yT4148dgBQRHP6ScetaodRsKNc0aHW LDf57ubOBxHbgTP7O9I0eYU3rlQrDoF8AHkCvbO+gWXCaKd3iDmGrio17t/qdiZJ5jQj 1e7Q== X-Gm-Message-State: AIVw113n/OoGpYBy/T8VJG5Xv8VEBVTdgYkqr46k868uMiH8mS7euqCS QRF9u5/+V25d2Pd5nBetcsHaGCa38hzn X-Received: by 10.107.18.196 with SMTP id 65mr15082596ios.64.1500894249226; Mon, 24 Jul 2017 04:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Mon, 24 Jul 2017 04:04:08 -0700 (PDT) From: Ines Robles Date: Mon, 24 Jul 2017 13:04:08 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a113f327c92166b05550e2ca7" Archived-At: Subject: [Roll] Minute - IETF 99 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, 24 Jul 2017 11:04:14 -0000 --001a113f327c92166b05550e2ca7 Content-Type: text/plain; charset="UTF-8" Dear all, First of all, a big THANKS to Dominique and Georgios for being the minute takers and to Rahul for being the Jabber Scriber. Please find the minutes of IETF 99 https://www.ietf.org/proceedings/99/minutes/minutes-99-roll-00.txt Comments welcome until 2017-08-11 Thank you, Ines + Peter --001a113f327c92166b05550e2ca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

First of all= , a big THANKS to Dominique and Georgios for being the minute takers and to= Rahul for being the Jabber Scriber.

Please find t= he minutes of IETF 99


Com= ments welcome until 2017-08-11

Thank you,

Ines + Peter
--001a113f327c92166b05550e2ca7-- From nobody Mon Jul 24 08:14:58 2017 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 34A4E12EC32 for ; Thu, 6 Jul 2017 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 vUueb3GlIe1X for ; Thu, 6 Jul 2017 10:19:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6F5131839 for ; Thu, 6 Jul 2017 10:19:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 63D81B818DC; Thu, 6 Jul 2017 10:18:56 -0700 (PDT) To: yusuke.doi@toshiba.co.jp, matthew.gillmore@itron.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, maria.ines.robles@ericsson.com, consultancy@vanderstok.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jim.list@hotmail.com, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170706171856.63D81B818DC@rfc-editor.org> Archived-At: X-Mailman-Approved-At: Mon, 24 Jul 2017 08:14:58 -0700 Subject: [Roll] [Technical Errata Reported] RFC7774 (5063) 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: , Date: Thu, 06 Jul 2017 17:19:36 -0000 X-Original-Date: Thu, 6 Jul 2017 10:18:56 -0700 (PDT) X-List-Received-Date: Thu, 06 Jul 2017 17:19:36 -0000 The following errata report has been submitted for RFC7774, "Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5063 -------------------------------------- Type: Technical Reported by: James K. Section: 2.1 Original Text ------------- C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and MUST NOT be used. Corrected Text -------------- C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0xffff is reserved and MUST NOT be used. Notes ----- [RFC 7731] states: 9.3. MPL Data Message Processing o If the MPL Control Message Trickle timer is not running and CONTROL_MESSAGE_TIMER_EXPIRATIONS is non-zero, the MPL Forwarder MUST initialize and start the MPL Control Message Trickle timer. 10.2. MPL Control Message Transmission An MPL Forwarder transmits MPL Control Messages using the Trickle algorithm. An MPL Forwarder maintains a single Trickle timer for each MPL Domain. When CONTROL_MESSAGE_TIMER_EXPIRATIONS is 0, the MPL Forwarder does not execute the Trickle algorithm and does not transmit MPL Control Messages. Thus, 0 is a valid configuration for C_T_EXP to disable Reactive Forwarding. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7774 (draft-ietf-roll-mpl-parameter-configuration-08) -------------------------------------- Title : Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Publication Date : March 2016 Author(s) : Y. Doi, M. Gillmore Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Jul 27 09:10:52 2017 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 DC1A4131C2A for ; Thu, 27 Jul 2017 09:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 YwErnDzTdx_f for ; Thu, 27 Jul 2017 09:10:49 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E7C131687 for ; Thu, 27 Jul 2017 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1501171848; x=1502381448; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pSBFkVFgo3FNJmo7uTbiXG2g5VsIat7BBQM8u3lz8AM=; b=KzH+Hb2gHTOEusqgDSsGXbY0ePcJdRqkIeRF2GTOCS9ao13TZefikuKm bpWC3JbZ424zrRIROjETBGT5M6CmzsdQhpBPI1/EoD/4lG/Lqe5M0JiYO +DHdplvoB/YQK/ZpY4JqljR5I9VYBmkSeujvNrPffmz59Jcxds2x2x2t3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAAACEHpZ/5tdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbScHjgaRYZYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?BAiMRQw4EAgEIEQQBAQMCIwMCAgIwFAEGAQEFAwIEEwiKJxCwAIImi0ABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuCHYNNgWGDJIQ9g0mCYQWQZo8AAodNjE2CFVe?= =?us-ascii?q?Ee4pelXEBHziBCncVH4dDdgGIcYEOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="457384828" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 16:10:47 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6RGAl68014526 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Jul 2017 16:10:48 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.1210.3; Thu, 27 Jul 2017 11:10:47 -0500 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.1210.000; Thu, 27 Jul 2017 11:10:47 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: New Version Notification for draft-thubert-roll-bier-00.txt Thread-Index: AQHTBvDzFoaiPDntXESXszPjso9GPqJn1E0A Date: Thu, 27 Jul 2017 16:10:36 +0000 Deferred-Delivery: Thu, 27 Jul 2017 16:10:32 +0000 Message-ID: <6c0a7fecd7e3416a97067acec0ae9452@XCH-RCD-001.cisco.com> References: <150117099635.11495.16369180348964499243.idtracker@ietfa.amsl.com> In-Reply-To: <150117099635.11495.16369180348964499243.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.61.196.89] 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-bier-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: Thu, 27 Jul 2017 16:10:51 -0000 RGVhciBhbGw6DQoNCkNhcnN0ZW4gYW5kIEkgcHJlc2VudGVkIHZhcmlhdGlvbnMgb2YgYml0U3Ry aW5nIHJlcHJlc2VudGF0aW9ucyBvZiBtdWx0aWNhc3QgZGVzdGluYXRpb25zIGZvciBSUEwgKHNl ZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OS9zbGlkZXMvc2xpZGVzLTk5LXJv bGwtaWV0Zjk5X3JvbGxfc2xpZGVzXzA0LTAwLnBkZikgYXQgSUVURiA5OS4NCldlIHdlcmUgYXNr ZWQgdG8gcHJvZHVjZSBhIGRyYWZ0IHRvIHJlZmluZSB0aGUgaWRlYXMuIFNvIHdlIGFyZSBvbiBp dC4gDQoNCkkgcHVzaGVkIGEgZHJhZnQtMDAgdGhhdCBpcyBzdGlsbCBtaXNzaW5nIHRleHQgb24g dGhlIEJsb29tIEZpbHRlciBvcGVyYXRpb247IGJ1dCBhdCBsZWFzdCB0aGUgZHJhZnQgaGFzIHRo ZSBwcm9wb3NlZCBiaXQtYnktYml0IFJQTC1CSUVSIHByb3RvY29sLCBhcyB3ZWxsIGFzIGEgZGVz Y3JpcHRpb24gb2Ygc3RvcmluZyBhbmQgbm9uLXN0b3JpbmcgYml0d2lzZSBvcGVyYXRpb25zLCB3 aGljaCBhcmUgbW9zdGx5IGNvbW1vbiB0byBCbG9vbSBGaWx0ZXJzIGFuZCBiaXQtYnktYml0Lg0K DQpGZWVkYmFjayBpcyB3ZWxjb21lIG9uIHdoZXRoZXIgeW91IHRoaW5rIHRoZSBncm91cCBzaG91 bGQgZGV2ZWxvcCB0aGUgaWRlYSENCg0KQ2hlZXJzOw0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBqZXVkaSAyNyBqdWlsbGV0IDIwMTcgMTc6 NTcNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+DQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtcm9sbC1i aWVyLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LXJvbGwt Ymllci0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1 YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC10 aHViZXJ0LXJvbGwtYmllcg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVJQTC1CSUVSDQpEb2N1bWVu dCBkYXRlOgkyMDE3LTA3LTI3DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 CQkxOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10aHViZXJ0LXJvbGwtYmllci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0LXJvbGwtYmllci8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC1yb2xs LWJpZXItMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1iaWVyLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlz IHNwZWNpZmljYXRpb24gZXh0ZW5kcyBSUEwgdG8gcHJvdmlkZSB1bmljYXN0IGFuZCBtdWx0aWNh c3QNCiAgIHJvdXRpbmcgYmFzZWQgb24gYml0U3RyaW5ncyBzdWNoIGFzIHVzZWQgaW4gQml0IElu ZGV4IEV4cGxpY2l0DQogICBSZXBsaWNhdGlvbiBhbmQgaXRzIHNvdXJjZS1yb3V0ZWQgVHJhZmZp YyBFbmdpbmVlcmluZyB2YXJpYW50LCB3aGljaA0KICAgY29ycmVzcG9uZCB0byBSUEwgc3Rvcmlu ZyBhbmQgbm9uLXN0b3JpbmcgbW9kZXMgcmVzcGVjdGl2ZWx5Lg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo=
Dr. Xavier VilajosanaWireless Networks Lab
Internet Interdisciplinary Institute (IN3)
= Professor
(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org=
http://wine.rdi.u= oc.edu
Parc = Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Buildin= g
08860 Castelldefels (Barcelona). Catalonia. Spain