From nobody Sat Jul 2 16:23:02 2016 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 96D4D12B05E for ; Sat, 2 Jul 2016 16:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=wayne.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 cHMzX-zFUCKj for ; Sat, 2 Jul 2016 16:22:57 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0116.outbound.protection.outlook.com [104.47.36.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F8B12B051 for ; Sat, 2 Jul 2016 16:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wayne.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YEgDXgtKTVeaGz25kE2S0z/sZcbMUEBmK0wbLnN8XXc=; b=P0iTxVmJt0pdtmnAonBUe6R0KEtxFGWCGkBNR2IGJzMwd3GBdrLanBmWfjMPXiismXc+Vgagg0yoDSuyg8qwvUe072RwzH64AojkHxgOoJa9ik0RG3PYiln7qpvYZQA8msKwicCPBnTTVZoUmRVeQ2T0EKIs3cKS8N4rz7mfnX8= Received: from BY1PR11MB0232.namprd11.prod.outlook.com (10.160.202.28) by BY1PR11MB0230.namprd11.prod.outlook.com (10.160.202.26) with Microsoft SMTP Server (TLS) id 15.1.528.16; Sat, 2 Jul 2016 23:22:55 +0000 Received: from BY1PR11MB0232.namprd11.prod.outlook.com ([10.160.202.28]) by BY1PR11MB0232.namprd11.prod.outlook.com ([10.160.202.28]) with mapi id 15.01.0528.022; Sat, 2 Jul 2016 23:22:54 +0000 From: Hongwei Zhang To: "roll@ietf.org" Thread-Topic: IEEE ICNC'17 Wireless Ad Hoc and Sensor Networks Symposium (Registration by July 5, 2016) Thread-Index: AdHUuI1LbfUbmAa6ROOr2d6tsaVH7gAAASHQ Date: Sat, 2 Jul 2016 23:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hongwei@wayne.edu; x-originating-ip: [75.46.16.66] x-ms-office365-filtering-correlation-id: 769911cf-f9fd-4599-1a54-08d3a2cfcb8c x-microsoft-exchange-diagnostics: 1; BY1PR11MB0230; 6:5dZ0qV/erVL32yAfDSc63OuX9dEquW5t7gJlLgZJby40cIeCW0WIyBZKDVSIdzt0atkLo5HUV4OkLTiKVfmaCsS+PsyBKqoD5EmgRZYihp+0TECF2dNnSBSAib1XHR3BVuGht4Q4WSzYZurpMDJUB24QWrva2zllehXzzjBgWL+OyD5zvKb5S6dI7v/HvUuc8iXgqKxLTTcg5g2d/YpxbbRXoT2eLZJGHZxv40eEtQdj8ZFfGmKNsjblP7afa9YOO1njbeH5G8zS8CmaCaIM4QiYD6x/N1dEb085wcsRjZc=; 5:pjfxTLM9L8XK4r5V5sjajGFxI36+SW8ePxoHhd1TRUg7YHxrpBGXRfSFDGGd/7HfKp0GWHI7XeLZMC1Y+KIkFHO2wKznUu/h6CW+SsN4PVJAinIfRuNqmY5EbZdRT1gozMXdjeUpIJU7w/NeNgAOeQ==; 24:W7d6dsN2vMf89thD3G+c73J13C8Y5dem3EKbTllS6AGOLqVRt+fqpuCT6aNInEKWNtnp1SgdhYwYXVpETQ3Va8BiYaY0S8GqEIMO4zOYXMY=; 7:7ROFR1uzTQHRc+hbizya42wssxVPssiZLRUo3A0tUP8yfqnohNoLM76jbgMJ8He8lclC5SJCVXmj5rRPX9n4Mb7J81rO/9UBg74+SgCTGu93FAM3ThkHXHhyOhjldErZiN/sjEopuGujAj6q1Afsk9puGp3FBdBJ484WDwjaBfgGUqVC/RfrXb7s3fpX+TUoFUe3wxLLy3r4DVWXcAmatJnU1CBMqF8eEYGheu7+n83cQnk9Za/ARxDM2tUMV4// x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0230; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(1471388762090)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR11MB0230; BCL:0; PCL:0; RULEID:; SRVR:BY1PR11MB0230; x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(13624006)(199003)(189002)(52044002)(76576001)(19625215002)(101416001)(86362001)(50986999)(16236675004)(75432002)(33656002)(105586002)(106356001)(19580395003)(107886002)(19580405001)(89122001)(2351001)(54356999)(97736004)(19617315012)(19300405004)(5640700001)(66066001)(2906002)(229853001)(122556002)(92566002)(790700001)(3280700002)(189998001)(4001430100002)(2501003)(87936001)(8936002)(102836003)(586003)(1730700003)(3660700001)(81166006)(3846002)(2900100001)(7906003)(7846002)(15975445007)(8676002)(81156014)(6116002)(88552002)(68736007)(77096005)(5003600100003)(7696003)(7736002)(10400500002)(90282001)(4326007)(74316002)(5002640100001)(110136002)(99286002)(9686002)(5630700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR11MB0230; H:BY1PR11MB0232.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: wayne.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR11MB02328F665A86B24C52C371A0B1260BY1PR11MB0232namp_" MIME-Version: 1.0 X-OriginatorOrg: wayne.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2016 23:22:54.4867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e51cdec9-811d-471d-bbe6-dd3d8d54c28b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB0230 Archived-At: Cc: "renjian@egr.msu.edu" , Nathalie Mitton , Hongwei Zhang Subject: [Roll] CFP: IEEE ICNC'17 Wireless Ad Hoc and Sensor Networks Symposium (Registration by July 5, 2016) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 23:22:59 -0000 --_000_BY1PR11MB02328F665A86B24C52C371A0B1260BY1PR11MB0232namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE International Conference on Computing, Networking and Communications (= ICNC) Silicon Valley, USA January 26-29, 2017 http://www.conf-icnc.org/2017/ International Conference on Computing, Networking and Communication (ICNC),= co-sponsored by the IEEE Communication Society and IEEE Computer Society, = is a premier conference in computing, networking, and communications. ICNC = 2017 will be held in Silicon Valley, USA during January 26-29, 2017. The Wireless Ad Hoc and Sensor Networks Symposium of ICNC'17 aims to provid= e an engaging forum for researchers and practitioners to share their latest= results in wireless ad hoc and sensor networking. We solicit papers that p= resent original, unpublished results in various aspects of ad hoc and senso= r networking. Topics include but are not limited to the following: Applications, real-world use cases and experience reports Network architectures Physical Layer Design Medium Access Control Routing Transport Control Cross-Layer Optimization Resource Management Interference Control and Adaptation Real-Time Communication QoS Time Synchronization Energy Efficiency Topology Control Localization Data Management, Data Aggregation, Data Dissemination, and Query Proces= sing Distributed Algorithms Heterogeneous Networks 5G Industrial Wireless Networks Performance Modeling, Optimization, and Evaluation Measurement and Simulation Techniques and Tools Testbeds and Living Labs Cyber-Physical Systems, Internet of Things Wireless Networked Control and Applications Smart and Connected Communities Submission Guidelines Please register your paper via EDAS by July 5; as need be,= a grace period will be given to registered papers. Detailed guidelines on = paper submission can be found at the "AUTHOR GUIDELINES" tab of http://www.= conf-icnc.org/2017/. If you may have any questions about the symposium, ple= ase feel free to contact the symposium co-chairs Nathalie Mitton (nathalie.= mitton@inria.fr) and Hongwei Zhang (hongwe= i@wayne.edu). Important Dates: Paper registration/submission: July 5, 2016 Paper Acceptance: Sept. 20, 2016 Camera-ready paper: Oct. 20, 2016 Symposium Co-chairs Nathalie Mitton, Inria Lille-Nord Europe, France (nathalie.= mitton@inria.fr) Hongwei Zhang, Wayne State University, USA (hongwei@wayne.e= du) --_000_BY1PR11MB02328F665A86B24C52C371A0B1260BY1PR11MB0232namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IEEE International Conference on Computing, Networki= ng and Communications (ICNC)

Silicon Valley, USA

January 26-29, 2017

http://ww= w.conf-icnc.org/2017/

 

 

International Conference on Computing, Networking an= d Communication (ICNC), co-sponsored by the IEEE Communication Society and = IEEE Computer Society, is a premier conference in computing, networking, an= d communications. ICNC 2017 will be held in Silicon Valley, USA during January 26-29, 2017.

 

The Wireless Ad Hoc and Sensor Networks Symposium of= ICNC'17 aims to provide an engaging forum for researchers and practitioner= s to share their latest results in wireless ad hoc and sensor networking. W= e solicit papers that present original, unpublished results in various aspects of ad hoc and sensor networking. To= pics include but are not limited to the following:

    Applications, real-world use case= s and experience reports

    Network architectures =

    Physical Layer Design <= /o:p>

    Medium Access Control <= /o:p>

    Routing

    Transport Control

    Cross-Layer Optimization

    Resource Management

    Interference Control and Ada= ptation

    Real-Time Communication

    QoS

    Time Synchronization

    Energy Efficiency

    Topology Control =

    Localization

    Data Management, Data Aggregation= , Data Dissemination, and Query Processing

    Distributed Algorithms =

    Heterogeneous Networks<= /o:p>

    5G

    Industrial Wireless Networks=

    Performance Modeling, Optimizatio= n, and Evaluation

    Measurement and Simulation T= echniques and Tools

    Testbeds and Living Labs

    Cyber-Physical Systems, Internet = of Things 

    Wireless Networked Control a= nd Applications

    Smart and Connected Communit= ies

 

 

Submission Guidelines

        &nbs= p;        Please register your paper via EDAS= by July 5; as need be, a grace period will be given to registered papers. = Detailed guidelines on paper submission can be found at the "AUTHOR GU= IDELINES" tab of http://www.conf-icnc.org/2017/. If you may have any questions about the symposium, please feel free to = contact the symposium co-chairs Nathalie Mitton (nathalie.mitton@inria.fr) and Hongwei Zhang (hongwei@wayne.edu<= /a>).

 

 

Important Dates:

        &nbs= p;       Paper registration/submission: July 5, 20= 16 

        &nbs= p;       Paper Acceptance: Sept. 20, 2016

        &nbs= p;       Camera-ready paper: Oct. 20, 2016

 

 

Symposium Co-chairs

        &nbs= p;       Nathalie Mitton, Inria Lille-Nord Europe,= France (nathalie.mitton@inria.= fr)

        &nbs= p;       Hongwei Zhang, Wayne State University, US= A (hongwei@wayne.edu)

--_000_BY1PR11MB02328F665A86B24C52C371A0B1260BY1PR11MB0232namp_-- From nobody Mon Jul 4 02:11:19 2016 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 76E7E12D13E for ; Mon, 4 Jul 2016 02:11:17 -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 l72zCyPijHjc for ; Mon, 4 Jul 2016 02:11:14 -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 68C2712D0FA for ; Mon, 4 Jul 2016 02:11:14 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud2.xs4all.net with ESMTP id EZBB1t00F4CYHle01ZBBsQ; Mon, 04 Jul 2016 11:11:12 +0200 Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([92.133.19.197]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 Jul 2016 11:11:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Jul 2016 11:11:11 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20160704090915.2570.5376.idtracker@ietfa.amsl.com> References: <20160704090915.2570.5376.idtracker@ietfa.amsl.com> Message-ID: <25a2e876d73c92c1b9a97ebaced865f0@xs4all.nl> X-Sender: stokcons@xs4all.nl (/E1Or5C4+v7kk2NhOeyBi+5ZZnXdQcvk) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] Fwd: New Version Notification for draft-vanderstok-roll-mpl-forw-select-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 09:11:17 -0000 Dear roll, we have submitted version 0 of the forwarder select draft. As can be seen from the text, the protocol is not finished. Nevertheless, The text gives a good impression of what we try to achieve. Looking forward to your comments, Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-roll-mpl-forw-select-00.txt Datum: 2016-07-04 11:09 Afzender: internet-drafts@ietf.org Ontvanger: "Peter van der Stok" , "Peter Van der Stok" , "Abdur Rashid Sangi" A new version of I-D, draft-vanderstok-roll-mpl-forw-select-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-roll-mpl-forw-select Revision: 00 Title: MPL Forwarder Select (MPLFS) Document date: 2016-07-04 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-roll-mpl-forw-select-00.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-roll-mpl-forw-select/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-roll-mpl-forw-select-00 Abstract: This document describes a Forwarder Selection (MPLFS) protocol for the Multicast Protocol for Low-Power and lossy Networks (MPL) to reduce the density of forwarders such that the number of forwarded messages is reduced. The protocol uses Trickle to distribute link- local information about the identity of the neighbours of the nodes which are enabled for MPL. In the end-state all nodes are connected to a minimum number, N_DUPLICATE, of forwarders, where N_DUPLICATE is application dependent. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 4 06:26:27 2016 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 669E112B009 for ; Mon, 4 Jul 2016 06:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 G4PD-cRT5Yst for ; Mon, 4 Jul 2016 06:26:22 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 2362012B01E for ; Mon, 4 Jul 2016 06:26:22 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id m127so171670674vkb.3 for ; Mon, 04 Jul 2016 06:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IqiyJ7gb97WdF27tDPtqF7TVXxHe3Tw95OcoSlJH8u0=; b=AJuuXX1EfKmv3XbihW5hxuifbzNfhedqzJDJL+t+blkYJ0PyvaMGemD+f+SNbsmtKD hhTH5uLzZTuAW6Ju0o4QoHDLU/CHhXYxKZOGT0UJvcwTjMmHssVsDVuTdoSiqxE/ga8R DXN5NIzHe1mue7KQWoNA7qYf980DoBkIxBvlVNWd0d1dzDgP82BWs+R676snKN/eZ0wK FzumDVAUd5XL3o2TahFAR4jTX647D8AbaVh+8d1Pi3wYktTr0eO1epdAGwb595jzMQ/n oVpnaby8+9OLlLVlI3gxzAkKYdRdiUMGLOGty/yWaisni0uMEtI2sDNIeir0l4BSRf6v xd0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IqiyJ7gb97WdF27tDPtqF7TVXxHe3Tw95OcoSlJH8u0=; b=O3srNAJu7rCwOQS338Hx3O8NCt2Slk4CpsP/U2aDgO7FzzyQHfSTXB3+OM4ldE34pF XnN7RAML0BtOSRP9aDYv6L88m+CW6WWqLVFUtHTfOl0JHzW2gHp22nRwlNTsUrpmqfgw A6juuca26NPuo1y3C+nVlCge86a7rr5p3Tnv41nXslei+Dn8ZaK0r+uIXkMGrNVNQEAm CmRcSb+lP29SV0WoyFvhxJONpg6EUYl3pcLcHowpsoxZbq0xs3aeZykH4wSMuqLxDrs5 pm4ha2MgKdHJY7w9aJQB5P6txLHuubOHsrnMxrWO92uhL+wZuyoL3mWLHv3b+1sR1Dn+ K1Kg== X-Gm-Message-State: ALyK8tIJZw9YHHS/42s6nEjYf2B0WwfJZr3FCszOqxGeOfGV5ozz/eTiHNOM4Vjc7GyTxSsJ3p8NsRguDilksg== X-Received: by 10.31.229.1 with SMTP id c1mr5339908vkh.15.1467638781094; Mon, 04 Jul 2016 06:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.200 with HTTP; Mon, 4 Jul 2016 06:26:20 -0700 (PDT) In-Reply-To: References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> From: Ines Robles Date: Mon, 4 Jul 2016 16:26:20 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a114db7bc34b2eb0536cf48cd Archived-At: Cc: peter van der Stok , Michael Richardson Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:26:25 -0000 --001a114db7bc34b2eb0536cf48cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, Thank you very much for your comments, we send a new version of the charter= . Last changes: a- We would keep the old paragraphs, might them be helpful for newcomers. b- Remove "AD approval is required for each new work item that is proposed." since it is part of the process anyway. c - Two work items were modified: c.1- Old: " Additional protocol to reduce paths for RPL in non-storing mode" New: "Additional protocol elements to reduce packet size and the amount of required routing states" c.2 - Old: " Methods to improve or correct the current RPL behaviour such as DIS modifications and problems associated with DAO messaging in RPL" New: "" Methods to improve or correct the current RPL behaviour and the other protocols defined by the working group. Please comments, Thank you, Peter and Ines ///////////////////////////////////////////////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= //////////////// CHARTER PROPOSAL: Charter for Working Group Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs are characterized as follows, but not limited to: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group (draft-levis-roll-overview-protocols-00) and have in their current form been found to not satisfy all of these specific routing requirements =E2=80=9CRouting Requirements for Urban Low-Power and = Lossy Networks=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing Requirements in Low= -Power and Lossy Networks=E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requirements i= n Low-Power and Lossy Networks=E2=80=9D RFC 5826, Building Automation Routing Requirements = in Low-Power and Lossy Networks RFC 5867. The Working Group is focused on routing issues for LLN and maintaining the protocols developed by the working group. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design. The Working Group focuses on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will document how data packets are routed and encapsulated when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. The Working group will align with the 6man WG when needed. ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication - Data models for RPL and MPL management - Alternative Multicast algorithm based on Bier forwarding. - Methods to improve or correct the current RPL behaviour and the other protocols defined by the working group. Milestones DATE Milestone September 2017 Recharter WG or close March 2017 Initial submission of draft about YANG RPL model to IESG January 2017 Initial submission of draft about MPL selection to IES= G November 2016 Initial submission of draft about Bier Multicast to IESG October 2016 Submit draft about YANG MPL model to IESG August 2016 Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG. May 2016 Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. to the IESG. draft-ietf-roll-routing-dispatch November 2016 Initial Submission of the No-Path DAO Problem Statement to the IESG 2016-06-30 12:11 GMT+03:00 peter van der Stok : > Hi Cenk, > > thanks for your suggestions. > I cannot refrain from reacting, and see below. > > Cenk G=C3=BCndogan schreef op 2016-06-29 17:04: > >> Hello Peter, >> >> I believe Pascal proposed to keep it in a more generic form >> "improvements to the RPL routing protocol". >> >> Otherwise, read on for my comments regarding the former wording: >> I propose we drop any form of uncertainty and change the "and/or" to >> "and". >> > > much better. > > Secondly, "packet size" sounds a little bit too generic, how about >> "control packet sizes", >> or "RPL related packet sizes"? >> > > I was also thinking of the headers, and IP in IP headers; and whatever ma= y > come; so I prefer packet size (NOT to be confused with payload size) > It looks general and still concrete enough. > > Thirdly, would "reduce ... the amount of required routing states" >> be a better choice? It hints to a reduction of memory while still >> providing an >> operational (converged) DODAG. >> The proposed form "reduce ... the amount of accumulated routing >> states" could also >> refer to drop states and decrease the quality of the routing protocol >> while doing so. >> > > required it is > > >> Cenk >> >> > Other suggestions or improvements? > > If not we send new text on monday/tuesday. > > Peter > > On 06/29/2016 09:05 AM, peter van der Stok wrote: >> >>> Hi All, >>> >>> If I understand correctly the discussion, the proposal is to replace >>> >>> "Additional protocol to reduce paths for RPL in non-storing mode." >>> >>> by >>> >>> "Additional protocol elements to reduce packet size and/or the amount o= f >>> accumulated routing states." >>> >>> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a114db7bc34b2eb0536cf48cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

Thank you very much for= your comments, we send a new version of the charter.

<= div>Last changes:

a- We =C2=A0would keep the old p= aragraphs, might them be helpful for newcomers.

b-= Remove "AD approval is required f= or each new work item that is proposed." since it is part of the proce= ss anyway.

=
c - Two work items were modified:=C2=A0

=C2=A0 c.1- =C2=A0Old: "=C2=A0Additional=C2=A0prot= ocol=C2=A0to =C2= =A0reduce=C2=A0paths for RPL in non-storing mode"<= /div>
New: "Additional protocol ele= ments to reduce packet size and the amount of required routing states"=

= c.2 - Old: "=C2=A0Methods to improve or correct =C2=A0the current RPL behaviour such = as DIS modifications and problems associated with DAO messaging in RPL"

New: = "" Methods to improve or correct =C2=A0the current RPL behaviour = and the other protocols defined by the working group.



Please comments,=C2=A0

<= /div>
Thank you,

Peter and Ines

=
////////////////////////////////////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= ///////////////////////////

CHARTER PROPOSAL:=


Charter for Worki= ng Group


Low power and Lossy Networks= (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limi= ted power, memory, and processing resources. They are interconnected by a v= ariety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or= other low power PLC (Powerline Communication) links. LLNs are transitionin= g to an end-to-end IP-based solution to avoid the problem of non-interopera= ble networks interconnected by protocol translation gateways and proxies.


Generally speaking,= LLNs are characterized as follows, but not limited to:


LLNs operate with a hard, very small = bound on state.


In most cases, LLN o= ptimize for saving energy by using small packet headers and reduce amount o= f control packets.


Typical traffic patterns are not simply unicast flows (e.g. in some cases = most if not all traffic can be point to multipoint).


In most cases, LLNs will be employed o= ver link layers with restricted frame-sizes and low bit rates, thus a routi= ng protocol for LLNs should be specifically adapted for such link layers. <= /span>


LLN routing protoc= ols have to be very careful when trading off efficiency for generality; sin= ce LLN nodes do not have resources to waste.


These specific properties cause LLNs to have spe= cific routing requirements.



Existing routing protocols such as OSPF, IS-IS, AODV, and OLS= R have been evaluated by the working group (draft-levis-roll-overview-proto= cols-00) and have in their current form been found to not satisfy all of th= ese specific routing requirements =E2=80=9CRouting Requirements for Urban L= ow-Power and Lossy Networks=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing = Requirements in Low-Power and Lossy Networks=E2=80=9D RFC 5673, =E2=80=9CHo= me Automation Routing Requirements in Low-Power and Lossy Networks=E2=80=9D= RFC 5826, Building Automation Routing Requirements in Low-Power and Lossy = Networks RFC 5867.


The Working Group is focused on routing issues for LLN and maintaining the= protocols developed by the working group.



There is a wide scope of application areas for= LLNs, including industrial monitoring, building automation (HVAC, lighting= , access control, fire), connected homes, health care, environmental monito= ring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working = Group focuses on routing solutions for a subset of these: connected home, b= uilding and urban sensor networks for which routing requirements have been = specified. These application-specific routing requirement documents were us= ed for protocol design.

The Working Group will document how data packets are routed an= d encapsulated when they cross the LLN, and when they enter and exit the LL= N: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 enc= apsulation including how routing loops are detected. In consultation with t= he 6lo WG, the Working Group will design a method to compress these routing= headers into a single block. The WGLC on this work will be shared with 6lo= . The Working group will align with the 6man WG when needed.

ROLL is responsible for maintenance = of the protocols that is has developed, including RPL and MPL.

<= br>

Work Items are:

- Guidance in using RFC6553, RF= C6554, and IPv6-in-IPv6 encapsulation.


- Compression of =C2=A0RFC6553, RFC6554, and IP head= ers in the 6LoWPAN adaptation layer context


- Additional protoco= l elements to reduce packet size and the amount of required routing states<= /span>


- Automatic selection of MPL forwarder= s to reduce message replication


- Data models for RPL and MPL management


- Alternative Multicast algorithm base= d on Bier forwarding.


- Methods to im= prove or correct =C2=A0the current RPL behaviour and the other protocols de= fined by the working group.



Miles= tones


DATE =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Milestone

September 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial submission of draft about YANG RPL model to IESG<= /span>

January 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MPL selection to IES= G

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial submission of draft about Bier Multicast to IESG<= /span>

October 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model to IESG

August 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Initial Submission of the draft about when to use RFC6553, R= FC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the = IESG.

May 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of the d= raft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN = adaptation layer context. =C2=A0to the IESG. draft-ietf-roll-routing-dispat= ch

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial Submission of the No-Path DAO Problem Statement t= o the IESG



2016-06-30 12:11 GMT+03:00 = peter van der Stok <stokcons@xs4all.nl>:
Hi Cenk,

thanks for your suggestions.
I cannot refrain from reacting, and see below.

Cenk G=C3=BCndogan schreef op 2016-06-29 17:04:
Hello Peter,

I believe Pascal proposed to keep it in a more generic form
"improvements to the RPL routing protocol".

Otherwise, read on for my comments regarding the former wording:
I propose we drop any form of uncertainty and change the "and/or"= to "and".

 much better.

Secondly, "packet size" sounds a little bit too generic, how abou= t
"control packet sizes",
or "RPL related packet sizes"?

 I was also thinking of the headers, and IP in IP headers; and whatever may = come; so I prefer packet size (NOT to be confused with payload size)
It looks general and still concrete enough.

Thirdly, would "reduce ... the amount of required routing states"=
be a better choice? It hints to a reduction of memory while still providing= an
operational (converged) DODAG.
The proposed form "reduce ... the amount of accumulated routing
states" could also
refer to drop states and decrease the quality of the routing protocol
while doing so.

 required it is


Cenk


Other suggestions or improvements?

If not we send new text on monday/tuesday.

Peter

On 06/29/2016 09:05 AM, peter van der Stok wrote:
Hi All,

If I understand correctly the discussion, the proposal is to replace

"Additional protocol to=C2=A0 reduce paths for RPL in non-storing mode= ."

by

"Additional protocol elements to reduce packet size and/or the amount = of accumulated routing states."


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

--001a114db7bc34b2eb0536cf48cd-- From nobody Mon Jul 4 06:45:58 2016 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 D75DB12D0E2 for ; Mon, 4 Jul 2016 06:45:57 -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 e9AuE_oAVM2T for ; Mon, 4 Jul 2016 06:45:56 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 20A2712D0C1 for ; Mon, 4 Jul 2016 06:45:56 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id i63so61914271vkb.2 for ; Mon, 04 Jul 2016 06:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=cPHMxtkk+afLau6cpExCWB5ayQg78+KSa/gnKl8ySqk=; b=SmXs/5pccW6tF2X4BclS9tSm9eLaEEjL4AvMf5CIsuQ5L4hvPQ2vx6OzIPzBOTOtqe hMCDhQRsPXelp1kLLD0Q3iiADvUvLFwQFhF+t3CUYlRCc9U/+vnCdYoXGq6Crf/JCGtj Qa67ECy3fdRqYmlkfkJgiym52zYO/7ej0L4Ns0w75Z1b3blZP9nwxWHgcuRUbdZwO1wq lFNZcVeV0d4JZ11X9ZOeh7XJ4/QcHBteoUZXouBViOZy46Q2MD+9H2vyLykDp2SVorYV MINNcciJYfpqR1Ciw6U8f08AAxS5pWrw4hkw11l+R+zlUzKJs8pU5cs6fa8B1YaBJTAQ uzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cPHMxtkk+afLau6cpExCWB5ayQg78+KSa/gnKl8ySqk=; b=CjlmGfvDMaBNvYyWN8YxzIM10stnqF0j1sAuNP01pKnQYOr3GPXFHwZzWiIZlKuCV6 csHVqnehMNw4Fl0ltMk2DpmO97H1rjuc+GGFrtsJV7WHGv+c8PDmrg+aO0cIsdC2UXAK yqFZgPnPBsJly0V/HffEl7QyPmRpLa0yNWgi3iJw9bUlVL6NlDJnILJb1Q2lsWMfx/mh sETaXcpAOugWS29bcftibbAcrfJz3Gsf68ScGmUr3mhSyDw+Ey1oqSeVlewp5UROM4jp Iv6OzdDIBuenFv7klg3RgQjV/zUPXmp7/Er8IxER/Pb4+DvXbmcXmb8ij+xkDQD+Ykkk XfFg== X-Gm-Message-State: ALyK8tLKBJbK8NVbmZWF+aIoeS+Hy/xheZfQ+fsspTuY9+rlZrN5xZ68aHgnKjTLJsV/HevZ+U50YkL6j1hdzg== X-Received: by 10.159.40.201 with SMTP id d67mr5042008uad.28.1467639955233; Mon, 04 Jul 2016 06:45:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.200 with HTTP; Mon, 4 Jul 2016 06:45:54 -0700 (PDT) From: Ines Robles Date: Mon, 4 Jul 2016 16:45:54 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=94eb2c123f1630c8de0536cf8e79 Archived-At: Cc: peter van der Stok Subject: [Roll] Agenda IETF 96 - Request for Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:45:58 -0000 --94eb2c123f1630c8de0536cf8e79 Content-Type: text/plain; charset=UTF-8 Dear all, Please find in the following link the agenda for IETF 96. Please comment. https://www.ietf.org/proceedings/96/agenda/agenda-96-roll To the presenters: Please provide us with the slides before 15 July. Thank you very much, Peter and Ines. --94eb2c123f1630c8de0536cf8e79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find in the following = link the agenda for IETF 96. Please comment.


To the presenters: Please provide us with the slides before 15 July.<= /div>

Thank you very much,

Pete= r and Ines.
--94eb2c123f1630c8de0536cf8e79-- From nobody Wed Jul 6 05:14:29 2016 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 6D7E812D178 for ; Wed, 6 Jul 2016 05:14:28 -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 zNdkChEzKhHI for ; Wed, 6 Jul 2016 05:14:26 -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 E3A9112D149 for ; Wed, 6 Jul 2016 05:14:25 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id FQEP1t00E4h15BW01QEPi4; Wed, 06 Jul 2016 14:14:23 +0200 Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([92.133.19.197]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 06 Jul 2016 14:14:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 06 Jul 2016 14:14:23 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (o4keeXmlQoSGg2t6fydh5z/3qdvI0HZE) User-Agent: XS4ALL Webmail Archived-At: Cc: Kovatsch Matthias , emarobl Subject: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 12:14:28 -0000 Hi Authors, Below my review of the document. Although the subject is tedious, the draft looks important to me to assure inter-operability between implementations This version was much more readable than the first one. So, I mostly signal nits and typos. It is important that someone with more implementation experience also carefully reviews the document to signal missing text. Below my comments, Peter ______________________________________________________________________________________ Review of RPLinfo version 05. Intro, last line, change to: “… type 3 {RFC6554], an efficient IP-in-IP technique, and use cases …”. Section 3, Figure 1 is not referred to in the text. Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed by the phrase “The numbers …” Page 5, line 3: leaf -> leafs Page 5, line 7: “is mentioned as well as” -> “is often named” Page 6, figure 3 is not referred to. Page 7, phrase 2, “This is a fundamental” -> “A fundamental” Page 8, line 8,”to add to remove” -> “to add or remove” Page 8, line 22, “In tables” -> “In table 1” Page 8, line 25, complete -> extensive Section 5, phrase 1 change to: “In storing mode (fully stateful), the sender cannot determine whether the destination is RPL-capable and thus ….” Section 5, line 9, indicates when (when to be added) Page 9, last line; don’t understand: “and are the RPL root node.” Page 10, line 6: remove: “in order to be able to” Section 5.2, line 3, insert -> inserts; send ->sends Section 5.3 and section 5.2: If the 6LBR does not know whether destination is Raf or not_Raf in section 5.3, then this is also the case in section 5.2. Question why is the IPv6-in-IPv6 header not also used in section 5.2. The problem for the 6LBR is the same. The text in section 5.3 seems to suggest that at each 6LR the IPv6-in-IPv6 is removed and then re-added again. I would expect the row re-added headers be filled in under 6LR. Other question: how does the last 6LR know that the next node is a not_Raf? Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers to the following sections 5.x Section 5.8 and section 5.6; same question as for section 5.3 and section 5.2. Section 5.9, line 11, sending 6LN to (“6LN to” added) Section 5.10, line 4, remove “sends” Page 16, “Alternatively, …. Compress.” I miss a lot of context to understand this paragraph. Section 5.11, line 5, addresses -> addressed Section 5.11, line 6, subject of “must send” misses. Section 5.12, The phrase “The IP-in-IP header must be addressed on a hop-by-hop basis” suggests that the header is removed and re-inserted at every hop. Nevertheless, that is not mentioned in the accompanying table. This is the same question I have for earlier sections 5.x. Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the destination! Section 6.2, “the traffic originates with an RPL aware node”. What do you mean? 6LBR is RPL aware? The destination is known to 6LBR because destination is RPL aware? Or something else? Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in each consecutive 6LR until it is fully consumed and removed in the last 6LR. Section 6.3, You cite several alternatives. I suggest to only mention the solution without RPI. Section 6.5, line 3, remoted -> removed Identical to storing mode case (please mention section). Section 6.6 same remark about RPI as section 6.3 Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in earlier section 6.x you use IPv6 node. Why? Section 7.1, line 6, stiaution -> approach Section 7.1, line 10; what is a “single code path”? Section 7.2, line 1, This -> In Section 7.2 line 3, all DODAG nodes, (added DODAG) Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate IPv6 nodes”? If not, I don’t understand the phrase. Section 7.2, line 20, there are -> there is -- Peter van der Stok mailto: consultancy@vanderstok.org From nobody Wed Jul 6 05:41:49 2016 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 62BFC12D774 for ; Wed, 6 Jul 2016 05:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 fHN1FAZ8CbGw for ; Wed, 6 Jul 2016 05:41:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A26A12D626 for ; Wed, 6 Jul 2016 05:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47402; q=dns/txt; s=iport; t=1467808905; x=1469018505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oHQ1EqV8nNn2ZZEWm6H3AOu+xaRWksinblwnlp/mRWo=; b=YNAM/RtOnPSWxeQBxWRrxLnzLKVNUxwhORQhj9jbYG2yP5meg5riviTh c4MOptH4dsKrr5HKEDYYmqqcfU2sXGduUCuetM7ILzVd/gIvz1i+VuoTr TMvWoI0hRz4J6ilFNO/Xykl5Jg8VyTeOqe0HWFuJmmjkdZ3tTlO/vezXG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgB8+3xX/5pdJa1dgnBOVnwGuSuBd?= =?us-ascii?q?yKFdgIcgRA4FAEBAQEBAQFlJ4RMAQEFAQEhCkELEAIBCBEEAQEhAQYDAgICJQs?= =?us-ascii?q?UCQgCBA4FCBOIFQ6sDo93AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNgSKCe?= =?us-ascii?q?goxH4JLgloFk1mFOgGOP4FxhFaDLoU8b48aAR42gggcgUxuhy4HPn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,318,1464652800"; d="scan'208,217";a="120639191" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 12:41:44 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u66CfiJt029673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 12:41:44 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 07:41:43 -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; Wed, 6 Jul 2016 07:41:43 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Request for Comments for ROLL Charter Thread-Index: AQHRy9nVupFNWUgruE+yIgm4tP2235/9MbkggAsl8RGAAxduYA== Date: Wed, 6 Jul 2016 12:41:13 +0000 Deferred-Delivery: Wed, 6 Jul 2016 12:41:07 +0000 Message-ID: References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.21] Content-Type: multipart/alternative; boundary="_000_f7829a0333174a46ba135ed5f803f6faXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , peter van der Stok Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 12:41:48 -0000 --_000_f7829a0333174a46ba135ed5f803f6faXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSW5lczoNCg0KQWJvdXQNCg0KDQoNCi0gICAgICAgICBDb21wcmVzc2lvbiBvZiAgUkZD NjU1MywgUkZDNjU1NCwgYW5kIElQIGhlYWRlcnMgaW4gdGhlIDZMb1dQQU4gYWRhcHRhdGlvbiBs YXllciBjb250ZXh0DQoNCkkgdGhpbmsgaXQgaXMgdGltZSB0byB3b3JrIG9uIGNvbXByZXNzaW5n IFJQTCBESU9zIGFuZCBEQU9zIGFzIHdlbGwsIHdvdWxkbuKAmXQgeW91IHNheT8NCg0KUGFzY2Fs DQoNCkZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBJbmVzIFJvYmxlcw0KU2VudDogbHVuZGkgNCBqdWlsbGV0IDIwMTYgMTU6MjYNClRvOiByb2xs IDxyb2xsQGlldGYub3JnPg0KQ2M6IHBldGVyIHZhbiBkZXIgU3RvayA8c3Rva2NvbnNAeHM0YWxs Lm5sPjsgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQpTdWJqZWN0 OiBSZTogW1JvbGxdIFJlcXVlc3QgZm9yIENvbW1lbnRzIGZvciBST0xMIENoYXJ0ZXINCg0KRGVh ciBhbGwsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMsIHdlIHNlbmQg YSBuZXcgdmVyc2lvbiBvZiB0aGUgY2hhcnRlci4NCg0KTGFzdCBjaGFuZ2VzOg0KDQphLSBXZSAg d291bGQga2VlcCB0aGUgb2xkIHBhcmFncmFwaHMsIG1pZ2h0IHRoZW0gYmUgaGVscGZ1bCBmb3Ig bmV3Y29tZXJzLg0KDQpiLSBSZW1vdmUgIkFEIGFwcHJvdmFsIGlzIHJlcXVpcmVkIGZvciBlYWNo IG5ldyB3b3JrIGl0ZW0gdGhhdCBpcyBwcm9wb3NlZC4iIHNpbmNlIGl0IGlzIHBhcnQgb2YgdGhl IHByb2Nlc3MgYW55d2F5Lg0KDQpjIC0gVHdvIHdvcmsgaXRlbXMgd2VyZSBtb2RpZmllZDoNCg0K ICBjLjEtICBPbGQ6ICIgQWRkaXRpb25hbCBwcm90b2NvbCB0byAgcmVkdWNlIHBhdGhzIGZvciBS UEwgaW4gbm9uLXN0b3JpbmcgbW9kZSINCk5ldzogIkFkZGl0aW9uYWwgcHJvdG9jb2wgZWxlbWVu dHMgdG8gcmVkdWNlIHBhY2tldCBzaXplIGFuZCB0aGUgYW1vdW50IG9mIHJlcXVpcmVkIHJvdXRp bmcgc3RhdGVzIg0KDQoNCmMuMiAtIE9sZDogIiBNZXRob2RzIHRvIGltcHJvdmUgb3IgY29ycmVj dCAgdGhlIGN1cnJlbnQgUlBMIGJlaGF2aW91ciBzdWNoIGFzIERJUyBtb2RpZmljYXRpb25zIGFu ZCBwcm9ibGVtcyBhc3NvY2lhdGVkIHdpdGggREFPIG1lc3NhZ2luZyBpbiBSUEwiDQoNCk5ldzog IiIgTWV0aG9kcyB0byBpbXByb3ZlIG9yIGNvcnJlY3QgIHRoZSBjdXJyZW50IFJQTCBiZWhhdmlv dXIgYW5kIHRoZSBvdGhlciBwcm90b2NvbHMgZGVmaW5lZCBieSB0aGUgd29ya2luZyBncm91cC4N Cg0KDQpQbGVhc2UgY29tbWVudHMsDQoNClRoYW5rIHlvdSwNCg0KUGV0ZXIgYW5kIEluZXMNCg0K Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KDQoN CkNIQVJURVIgUFJPUE9TQUw6DQoNCg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cA0KDQoNCkxv dyBwb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKExMTnMgKSBbUkZDNzEwMl0gW1JGQzcyMjhdIGFy ZSBtYWRlIHVwIG9mIG1hbnkgZW1iZWRkZWQgZGV2aWNlcyB3aXRoIGxpbWl0ZWQgcG93ZXIsIG1l bW9yeSwgYW5kIHByb2Nlc3NpbmcgcmVzb3VyY2VzLiBUaGV5IGFyZSBpbnRlcmNvbm5lY3RlZCBi eSBhIHZhcmlldHkgb2YgbGlua3MsIHN1Y2ggYXMgSUVFRSA4MDIuMTUuNCwgQmx1ZXRvb3RoLCBM b3cgUG93ZXIgV2lGaSwgd2lyZWQgb3Igb3RoZXIgbG93IHBvd2VyIFBMQyAoUG93ZXJsaW5lIENv bW11bmljYXRpb24pIGxpbmtzLiBMTE5zIGFyZSB0cmFuc2l0aW9uaW5nIHRvIGFuIGVuZC10by1l bmQgSVAtYmFzZWQgc29sdXRpb24gdG8gYXZvaWQgdGhlIHByb2JsZW0gb2Ygbm9uLWludGVyb3Bl cmFibGUgbmV0d29ya3MgaW50ZXJjb25uZWN0ZWQgYnkgcHJvdG9jb2wgdHJhbnNsYXRpb24gZ2F0 ZXdheXMgYW5kIHByb3hpZXMuDQoNCg0KR2VuZXJhbGx5IHNwZWFraW5nLCBMTE5zIGFyZSBjaGFy YWN0ZXJpemVkIGFzIGZvbGxvd3MsIGJ1dCBub3QgbGltaXRlZCB0bzoNCg0KDQpMTE5zIG9wZXJh dGUgd2l0aCBhIGhhcmQsIHZlcnkgc21hbGwgYm91bmQgb24gc3RhdGUuDQoNCg0KSW4gbW9zdCBj YXNlcywgTExOIG9wdGltaXplIGZvciBzYXZpbmcgZW5lcmd5IGJ5IHVzaW5nIHNtYWxsIHBhY2tl dCBoZWFkZXJzIGFuZCByZWR1Y2UgYW1vdW50IG9mIGNvbnRyb2wgcGFja2V0cy4NCg0KDQpUeXBp Y2FsIHRyYWZmaWMgcGF0dGVybnMgYXJlIG5vdCBzaW1wbHkgdW5pY2FzdCBmbG93cyAoZS5nLiBp biBzb21lIGNhc2VzIG1vc3QgaWYgbm90IGFsbCB0cmFmZmljIGNhbiBiZSBwb2ludCB0byBtdWx0 aXBvaW50KS4NCg0KDQpJbiBtb3N0IGNhc2VzLCBMTE5zIHdpbGwgYmUgZW1wbG95ZWQgb3ZlciBs aW5rIGxheWVycyB3aXRoIHJlc3RyaWN0ZWQgZnJhbWUtc2l6ZXMgYW5kIGxvdyBiaXQgcmF0ZXMs IHRodXMgYSByb3V0aW5nIHByb3RvY29sIGZvciBMTE5zIHNob3VsZCBiZSBzcGVjaWZpY2FsbHkg YWRhcHRlZCBmb3Igc3VjaCBsaW5rIGxheWVycy4NCg0KDQpMTE4gcm91dGluZyBwcm90b2NvbHMg aGF2ZSB0byBiZSB2ZXJ5IGNhcmVmdWwgd2hlbiB0cmFkaW5nIG9mZiBlZmZpY2llbmN5IGZvciBn ZW5lcmFsaXR5OyBzaW5jZSBMTE4gbm9kZXMgZG8gbm90IGhhdmUgcmVzb3VyY2VzIHRvIHdhc3Rl Lg0KDQoNClRoZXNlIHNwZWNpZmljIHByb3BlcnRpZXMgY2F1c2UgTExOcyB0byBoYXZlIHNwZWNp ZmljIHJvdXRpbmcgcmVxdWlyZW1lbnRzLg0KDQoNCkV4aXN0aW5nIHJvdXRpbmcgcHJvdG9jb2xz IHN1Y2ggYXMgT1NQRiwgSVMtSVMsIEFPRFYsIGFuZCBPTFNSIGhhdmUgYmVlbiBldmFsdWF0ZWQg YnkgdGhlIHdvcmtpbmcgZ3JvdXAgKGRyYWZ0LWxldmlzLXJvbGwtb3ZlcnZpZXctcHJvdG9jb2xz LTAwKSBhbmQgaGF2ZSBpbiB0aGVpciBjdXJyZW50IGZvcm0gYmVlbiBmb3VuZCB0byBub3Qgc2F0 aXNmeSBhbGwgb2YgdGhlc2Ugc3BlY2lmaWMgcm91dGluZyByZXF1aXJlbWVudHMg4oCcUm91dGlu ZyBSZXF1aXJlbWVudHMgZm9yIFVyYmFuIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3PigJ0g UkZDIDU1NDgsIOKAnEluZHVzdHJpYWwgUm91dGluZyBSZXF1aXJlbWVudHMgaW4gTG93LVBvd2Vy IGFuZCBMb3NzeSBOZXR3b3Jrc+KAnSBSRkMgNTY3Mywg4oCcSG9tZSBBdXRvbWF0aW9uIFJvdXRp bmcgUmVxdWlyZW1lbnRzIGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3PigJ0gUkZDIDU4 MjYsIEJ1aWxkaW5nIEF1dG9tYXRpb24gUm91dGluZyBSZXF1aXJlbWVudHMgaW4gTG93LVBvd2Vy IGFuZCBMb3NzeSBOZXR3b3JrcyBSRkMgNTg2Ny4NCg0KDQpUaGUgV29ya2luZyBHcm91cCBpcyBm b2N1c2VkIG9uIHJvdXRpbmcgaXNzdWVzIGZvciBMTE4gYW5kIG1haW50YWluaW5nIHRoZSBwcm90 b2NvbHMgZGV2ZWxvcGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLg0KDQoNClRoZXJlIGlzIGEgd2lk ZSBzY29wZSBvZiBhcHBsaWNhdGlvbiBhcmVhcyBmb3IgTExOcywgaW5jbHVkaW5nIGluZHVzdHJp YWwgbW9uaXRvcmluZywgYnVpbGRpbmcgYXV0b21hdGlvbiAoSFZBQywgbGlnaHRpbmcsIGFjY2Vz cyBjb250cm9sLCBmaXJlKSwgY29ubmVjdGVkIGhvbWVzLCBoZWFsdGggY2FyZSwgZW52aXJvbm1l bnRhbCBtb25pdG9yaW5nLCB1cmJhbiBzZW5zb3IgbmV0d29ya3MgKGUuZy4gU21hcnQgR3JpZCks IGFzc2V0IHRyYWNraW5nLiBUaGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uIHJvdXRpbmcgc29s dXRpb25zIGZvciBhIHN1YnNldCBvZiB0aGVzZTogY29ubmVjdGVkIGhvbWUsIGJ1aWxkaW5nIGFu ZCB1cmJhbiBzZW5zb3IgbmV0d29ya3MgZm9yIHdoaWNoIHJvdXRpbmcgcmVxdWlyZW1lbnRzIGhh dmUgYmVlbiBzcGVjaWZpZWQuIFRoZXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIHJvdXRpbmcgcmVx dWlyZW1lbnQgZG9jdW1lbnRzIHdlcmUgdXNlZCBmb3IgcHJvdG9jb2wgZGVzaWduLg0KDQpUaGUg V29ya2luZyBHcm91cCBmb2N1c2VzIG9uIElQdjYgcm91dGluZyBhcmNoaXRlY3R1cmFsIGZyYW1l d29yayBmb3IgdGhlc2UgYXBwbGljYXRpb24gc2NlbmFyaW9zLiBUaGUgRnJhbWV3b3JrIHdpbGwg dGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdmFyaW91cyBhc3BlY3RzIGluY2x1ZGluZyBoaWdoIHJl bGlhYmlsaXR5IGluIHRoZSBwcmVzZW5jZSBvZiB0aW1lIHZhcnlpbmcgbG9zcyBjaGFyYWN0ZXJp c3RpY3MgYW5kIGNvbm5lY3Rpdml0eSB3aGlsZSBwZXJtaXR0aW5nIGxvdy1wb3dlciBvcGVyYXRp b24gd2l0aCB2ZXJ5IG1vZGVzdCBtZW1vcnkgYW5kIENQVSBwcmVzc3VyZSBpbiBuZXR3b3JrcyBw b3RlbnRpYWxseSBjb21wcmlzaW5nIGEgdmVyeSBsYXJnZSBudW1iZXIgKHNldmVyYWwgdGhvdXNh bmRzKSBvZiBub2Rlcy4NCg0KDQpUaGUgV29ya2luZyBHcm91cCB3aWxsIGRvY3VtZW50IGhvdyBk YXRhIHBhY2tldHMgYXJlIHJvdXRlZCBhbmQgZW5jYXBzdWxhdGVkIHdoZW4gdGhleSBjcm9zcyB0 aGUgTExOLCBhbmQgd2hlbiB0aGV5IGVudGVyIGFuZCBleGl0IHRoZSBMTE46IHRoZSBhcHByb3By aWF0ZSB1c2Ugb2YgUlBJIChSRkM2NTUzKSwgUkgzIChSRkM2NTU0KSBhbmQgSVB2Ni1pbi1JUHY2 IGVuY2Fwc3VsYXRpb24gaW5jbHVkaW5nIGhvdyByb3V0aW5nIGxvb3BzIGFyZSBkZXRlY3RlZC4g SW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIDZsbyBXRywgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBk ZXNpZ24gYSBtZXRob2QgdG8gY29tcHJlc3MgdGhlc2Ugcm91dGluZyBoZWFkZXJzIGludG8gYSBz aW5nbGUgYmxvY2suIFRoZSBXR0xDIG9uIHRoaXMgd29yayB3aWxsIGJlIHNoYXJlZCB3aXRoIDZs by4gVGhlIFdvcmtpbmcgZ3JvdXAgd2lsbCBhbGlnbiB3aXRoIHRoZSA2bWFuIFdHIHdoZW4gbmVl ZGVkLg0KDQpST0xMIGlzIHJlc3BvbnNpYmxlIGZvciBtYWludGVuYW5jZSBvZiB0aGUgcHJvdG9j b2xzIHRoYXQgaXMgaGFzIGRldmVsb3BlZCwgaW5jbHVkaW5nIFJQTCBhbmQgTVBMLg0KDQoNCldv cmsgSXRlbXMgYXJlOg0KDQotIEd1aWRhbmNlIGluIHVzaW5nIFJGQzY1NTMsIFJGQzY1NTQsIGFu ZCBJUHY2LWluLUlQdjYgZW5jYXBzdWxhdGlvbi4NCg0KDQotIENvbXByZXNzaW9uIG9mICBSRkM2 NTUzLCBSRkM2NTU0LCBhbmQgSVAgaGVhZGVycyBpbiB0aGUgNkxvV1BBTiBhZGFwdGF0aW9uIGxh eWVyIGNvbnRleHQNCg0KDQotIEFkZGl0aW9uYWwgcHJvdG9jb2wgZWxlbWVudHMgdG8gcmVkdWNl IHBhY2tldCBzaXplIGFuZCB0aGUgYW1vdW50IG9mIHJlcXVpcmVkIHJvdXRpbmcgc3RhdGVzDQoN Cg0KLSBBdXRvbWF0aWMgc2VsZWN0aW9uIG9mIE1QTCBmb3J3YXJkZXJzIHRvIHJlZHVjZSBtZXNz YWdlIHJlcGxpY2F0aW9uDQoNCg0KLSBEYXRhIG1vZGVscyBmb3IgUlBMIGFuZCBNUEwgbWFuYWdl bWVudA0KDQoNCi0gQWx0ZXJuYXRpdmUgTXVsdGljYXN0IGFsZ29yaXRobSBiYXNlZCBvbiBCaWVy IGZvcndhcmRpbmcuDQoNCg0KLSBNZXRob2RzIHRvIGltcHJvdmUgb3IgY29ycmVjdCAgdGhlIGN1 cnJlbnQgUlBMIGJlaGF2aW91ciBhbmQgdGhlIG90aGVyIHByb3RvY29scyBkZWZpbmVkIGJ5IHRo ZSB3b3JraW5nIGdyb3VwLg0KDQoNCk1pbGVzdG9uZXMNCg0KDQpEQVRFICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1pbGVzdG9uZQ0KDQpTZXB0ZW1iZXIgMjAxNyAgICAgICAgICAgIFJlY2hh cnRlciBXRyBvciBjbG9zZQ0KDQpNYXJjaCAyMDE3ICAgICAgICAgICBJbml0aWFsIHN1Ym1pc3Np b24gb2YgZHJhZnQgYWJvdXQgWUFORyBSUEwgbW9kZWwgdG8gSUVTRw0KDQpKYW51YXJ5IDIwMTcg ICAgICAgICBJbml0aWFsIHN1Ym1pc3Npb24gb2YgZHJhZnQgYWJvdXQgTVBMIHNlbGVjdGlvbiB0 byBJRVNHDQoNCk5vdmVtYmVyIDIwMTYgICAgICAgIEluaXRpYWwgc3VibWlzc2lvbiBvZiBkcmFm dCBhYm91dCBCaWVyIE11bHRpY2FzdCB0byBJRVNHDQoNCk9jdG9iZXIgMjAxNiAgICAgICAgIFN1 Ym1pdCBkcmFmdCBhYm91dCBZQU5HIE1QTCBtb2RlbCB0byBJRVNHDQoNCkF1Z3VzdCAyMDE2ICAg ICAgICAgIEluaXRpYWwgU3VibWlzc2lvbiBvZiB0aGUgZHJhZnQgYWJvdXQgd2hlbiB0byB1c2Ug UkZDNjU1MywgUkZDNjU1NCwgYW5kIElQdjYtaW4tSVB2NiBlbmNhcHN1bGF0aW9uIERyYWZ0LWll dGYtcm9sbC11c2VvZnJwbGluZm8gdG8gdGhlIElFU0cuDQoNCk1heSAyMDE2ICAgICAgICAgICAg IEluaXRpYWwgc3VibWlzc2lvbiBvZiB0aGUgZHJhZnQgYWJvdXQgaG93IHRvIGNvbXByZXNzIFJG QzY1NTMsIFJGQzY1NTQsIGFuZCBJUCBoZWFkZXJzIGluIHRoZSA2TG9XUEFOIGFkYXB0YXRpb24g bGF5ZXIgY29udGV4dC4gIHRvIHRoZSBJRVNHLiBkcmFmdC1pZXRmLXJvbGwtcm91dGluZy1kaXNw YXRjaA0KTm92ZW1iZXIgMjAxNiAgICAgICAgSW5pdGlhbCBTdWJtaXNzaW9uIG9mIHRoZSBOby1Q YXRoIERBTyBQcm9ibGVtIFN0YXRlbWVudCB0byB0aGUgSUVTRw0KDQoNCg0KMjAxNi0wNi0zMCAx MjoxMSBHTVQrMDM6MDAgcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw8bWFp bHRvOnN0b2tjb25zQHhzNGFsbC5ubD4+Og0KSGkgQ2VuaywNCg0KdGhhbmtzIGZvciB5b3VyIHN1 Z2dlc3Rpb25zLg0KSSBjYW5ub3QgcmVmcmFpbiBmcm9tIHJlYWN0aW5nLCBhbmQgc2VlIGJlbG93 Lg0KDQpDZW5rIEfDvG5kb2dhbiBzY2hyZWVmIG9wIDIwMTYtMDYtMjkgMTc6MDQ6DQpIZWxsbyBQ ZXRlciwNCg0KSSBiZWxpZXZlIFBhc2NhbCBwcm9wb3NlZCB0byBrZWVwIGl0IGluIGEgbW9yZSBn ZW5lcmljIGZvcm0NCiJpbXByb3ZlbWVudHMgdG8gdGhlIFJQTCByb3V0aW5nIHByb3RvY29sIi4N Cg0KT3RoZXJ3aXNlLCByZWFkIG9uIGZvciBteSBjb21tZW50cyByZWdhcmRpbmcgdGhlIGZvcm1l ciB3b3JkaW5nOg0KSSBwcm9wb3NlIHdlIGRyb3AgYW55IGZvcm0gb2YgdW5jZXJ0YWludHkgYW5k IGNoYW5nZSB0aGUgImFuZC9vciIgdG8gImFuZCIuDQoNCm11Y2ggYmV0dGVyLg0KU2Vjb25kbHks ICJwYWNrZXQgc2l6ZSIgc291bmRzIGEgbGl0dGxlIGJpdCB0b28gZ2VuZXJpYywgaG93IGFib3V0 DQoiY29udHJvbCBwYWNrZXQgc2l6ZXMiLA0Kb3IgIlJQTCByZWxhdGVkIHBhY2tldCBzaXplcyI/ DQoNCkkgd2FzIGFsc28gdGhpbmtpbmcgb2YgdGhlIGhlYWRlcnMsIGFuZCBJUCBpbiBJUCBoZWFk ZXJzOyBhbmQgd2hhdGV2ZXIgbWF5IGNvbWU7IHNvIEkgcHJlZmVyIHBhY2tldCBzaXplIChOT1Qg dG8gYmUgY29uZnVzZWQgd2l0aCBwYXlsb2FkIHNpemUpDQpJdCBsb29rcyBnZW5lcmFsIGFuZCBz dGlsbCBjb25jcmV0ZSBlbm91Z2guDQpUaGlyZGx5LCB3b3VsZCAicmVkdWNlIC4uLiB0aGUgYW1v dW50IG9mIHJlcXVpcmVkIHJvdXRpbmcgc3RhdGVzIg0KYmUgYSBiZXR0ZXIgY2hvaWNlPyBJdCBo aW50cyB0byBhIHJlZHVjdGlvbiBvZiBtZW1vcnkgd2hpbGUgc3RpbGwgcHJvdmlkaW5nIGFuDQpv cGVyYXRpb25hbCAoY29udmVyZ2VkKSBET0RBRy4NClRoZSBwcm9wb3NlZCBmb3JtICJyZWR1Y2Ug Li4uIHRoZSBhbW91bnQgb2YgYWNjdW11bGF0ZWQgcm91dGluZw0Kc3RhdGVzIiBjb3VsZCBhbHNv DQpyZWZlciB0byBkcm9wIHN0YXRlcyBhbmQgZGVjcmVhc2UgdGhlIHF1YWxpdHkgb2YgdGhlIHJv dXRpbmcgcHJvdG9jb2wNCndoaWxlIGRvaW5nIHNvLg0KDQpyZXF1aXJlZCBpdCBpcw0KDQpDZW5r DQoNCk90aGVyIHN1Z2dlc3Rpb25zIG9yIGltcHJvdmVtZW50cz8NCg0KSWYgbm90IHdlIHNlbmQg bmV3IHRleHQgb24gbW9uZGF5L3R1ZXNkYXkuDQoNClBldGVyDQpPbiAwNi8yOS8yMDE2IDA5OjA1 IEFNLCBwZXRlciB2YW4gZGVyIFN0b2sgd3JvdGU6DQpIaSBBbGwsDQoNCklmIEkgdW5kZXJzdGFu ZCBjb3JyZWN0bHkgdGhlIGRpc2N1c3Npb24sIHRoZSBwcm9wb3NhbCBpcyB0byByZXBsYWNlDQoN CiJBZGRpdGlvbmFsIHByb3RvY29sIHRvICByZWR1Y2UgcGF0aHMgZm9yIFJQTCBpbiBub24tc3Rv cmluZyBtb2RlLiINCg0KYnkNCg0KIkFkZGl0aW9uYWwgcHJvdG9jb2wgZWxlbWVudHMgdG8gcmVk dWNlIHBhY2tldCBzaXplIGFuZC9vciB0aGUgYW1vdW50IG9mIGFjY3VtdWxhdGVkIHJvdXRpbmcg c3RhdGVzLiINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg== --_000_f7829a0333174a46ba135ed5f803f6faXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56 Yjt9DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MTI3OTM5MDcwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo5ODMwNzg3OCAtMTc3MjA1NjY2MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjkuNXB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiM1MDAwNTA7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkhlbGxvIEluZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5BYm91dA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4w cHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1 MDAwNTAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5Db21wcmVzc2lvbiBvZiAmbmJzcDtSRkM2NTUz LCBSRkM2NTU0LCBhbmQgSVAgaGVhZGVycyBpbiB0aGUgNkxvV1BBTiBhZGFwdGF0aW9uIGxheWVy IGNvbnRleHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgaXQgaXMgdGltZSB0byB3b3JrIG9uIGNvbXByZXNzaW5nIFJQTCBESU9zIGFuZCBEQU9zIGFz IHdlbGwsIHdvdWxkbuKAmXQgeW91IHNheT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9sbCBb bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SW5lcyBS b2JsZXM8YnI+DQo8Yj5TZW50OjwvYj4gbHVuZGkgNCBqdWlsbGV0IDIwMTYgMTU6MjY8YnI+DQo8 Yj5Ubzo8L2I+IHJvbGwgJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBwZXRl ciB2YW4gZGVyIFN0b2sgJmx0O3N0b2tjb25zQHhzNGFsbC5ubCZndDs7IE1pY2hhZWwgUmljaGFy ZHNvbiAmbHQ7bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtSb2xsXSBSZXF1ZXN0IGZvciBDb21tZW50cyBmb3IgUk9MTCBDaGFydGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxs LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cywgd2Ugc2VuZCBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5MYXN0IGNoYW5nZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEtIFdlICZuYnNwO3dvdWxkIGtlZXAgdGhlIG9sZCBw YXJhZ3JhcGhzLCBtaWdodCB0aGVtIGJlIGhlbHBmdWwgZm9yIG5ld2NvbWVycy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yi0gUmVtb3ZlICZx dW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5BRCBhcHByb3ZhbCBpcyByZXF1aXJlZCBm b3IgZWFjaCBuZXcgd29yayBpdGVtIHRoYXQgaXMgcHJvcG9zZWQuJnF1b3Q7IHNpbmNlIGl0IGlz IHBhcnQgb2YgdGhlIHByb2Nlc3MgYW55d2F5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YyAtIFR3byB3b3JrIGl0ZW1zIHdlcmUg bW9kaWZpZWQ6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyBjLjEtICZuYnNwO09sZDogJnF1b3Q7PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdDtjb2xvcjojNTAwMDUwIj4mbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+QWRkaXRpb25hbDwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+cHJvdG9jb2w8L3NwYW4+Jm5ic3A7dG8gJm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPnJlZHVjZTwvc3Bhbj4mbmJzcDtwYXRocyBmb3IgUlBMIGluIG5vbi1zdG9yaW5n IG1vZGU8L3NwYW4+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5OZXc6ICZxdW90O0Fk ZGl0aW9uYWwgcHJvdG9jb2wgZWxlbWVudHMgdG8gcmVkdWNlIHBhY2tldCBzaXplIGFuZCB0aGUg YW1vdW50IG9mIHJlcXVpcmVkIHJvdXRpbmcgc3RhdGVzJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Yy4yIC0gT2xkOiAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7TWV0aG9kcyB0byBpbXByb3ZlIG9yIGNvcnJlY3Qg Jm5ic3A7dGhlIGN1cnJlbnQgUlBMIGJlaGF2aW91ciBzdWNoIGFzIERJUyBtb2RpZmljYXRpb25z IGFuZCBwcm9ibGVtcyBhc3NvY2lhdGVkDQogd2l0aCBEQU8gbWVzc2FnaW5nIGluIFJQTDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OZXc6ICZxdW90 OyZxdW90OyBNZXRob2RzIHRvIGltcHJvdmUgb3IgY29ycmVjdCAmbmJzcDt0aGUgY3VycmVudCBS UEwgYmVoYXZpb3VyIGFuZCB0aGUgb3RoZXIgcHJvdG9jb2xzIGRlZmluZWQgYnkgdGhlIHdvcmtp bmcgZ3JvdXAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBjb21tZW50cywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91LDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXRlciBhbmQgSW5l czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q0hBUlRFUiBQUk9Q T1NBTDo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5DaGFydGVyIGZvciBXb3JraW5nIEdy b3VwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+TG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcyApIFtSRkM3 MTAyXSBbUkZDNzIyOF0gYXJlIG1hZGUgdXAgb2YgbWFueSBlbWJlZGRlZCBkZXZpY2VzIHdpdGgg bGltaXRlZCBwb3dlciwgbWVtb3J5LCBhbmQgcHJvY2Vzc2luZyByZXNvdXJjZXMuIFRoZXkNCiBh cmUgaW50ZXJjb25uZWN0ZWQgYnkgYSB2YXJpZXR5IG9mIGxpbmtzLCBzdWNoIGFzIElFRUUgODAy LjE1LjQsIEJsdWV0b290aCwgTG93IFBvd2VyIFdpRmksIHdpcmVkIG9yIG90aGVyIGxvdyBwb3dl ciBQTEMgKFBvd2VybGluZSBDb21tdW5pY2F0aW9uKSBsaW5rcy4gTExOcyBhcmUgdHJhbnNpdGlv bmluZyB0byBhbiBlbmQtdG8tZW5kIElQLWJhc2VkIHNvbHV0aW9uIHRvIGF2b2lkIHRoZSBwcm9i bGVtIG9mIG5vbi1pbnRlcm9wZXJhYmxlIG5ldHdvcmtzDQogaW50ZXJjb25uZWN0ZWQgYnkgcHJv dG9jb2wgdHJhbnNsYXRpb24gZ2F0ZXdheXMgYW5kIHByb3hpZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NTAwMDUwIj5HZW5lcmFsbHkgc3BlYWtpbmcsIExMTnMgYXJlIGNoYXJhY3Rlcml6ZWQgYXMgZm9s bG93cywgYnV0IG5vdCBsaW1pdGVkIHRvOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+TExOcyBv cGVyYXRlIHdpdGggYSBoYXJkLCB2ZXJ5IHNtYWxsIGJvdW5kIG9uIHN0YXRlLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+SW4gbW9zdCBjYXNlcywgTExOIG9wdGltaXplIGZvciBzYXZpbmcgZW5lcmd5IGJ5IHVzaW5n IHNtYWxsIHBhY2tldCBoZWFkZXJzIGFuZCByZWR1Y2UgYW1vdW50IG9mIGNvbnRyb2wgcGFja2V0 cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDAwNTAiPlR5cGljYWwgdHJhZmZpYyBwYXR0ZXJucyBhcmUg bm90IHNpbXBseSB1bmljYXN0IGZsb3dzIChlLmcuIGluIHNvbWUgY2FzZXMgbW9zdCBpZiBub3Qg YWxsIHRyYWZmaWMgY2FuIGJlIHBvaW50IHRvIG11bHRpcG9pbnQpLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzUwMDA1MCI+SW4gbW9zdCBjYXNlcywgTExOcyB3aWxsIGJlIGVtcGxveWVkIG92ZXIgbGluayBs YXllcnMgd2l0aCByZXN0cmljdGVkIGZyYW1lLXNpemVzIGFuZCBsb3cgYml0IHJhdGVzLCB0aHVz IGEgcm91dGluZyBwcm90b2NvbCBmb3IgTExOcyBzaG91bGQNCiBiZSBzcGVjaWZpY2FsbHkgYWRh cHRlZCBmb3Igc3VjaCBsaW5rIGxheWVycy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBj bTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5MTE4g cm91dGluZyBwcm90b2NvbHMgaGF2ZSB0byBiZSB2ZXJ5IGNhcmVmdWwgd2hlbiB0cmFkaW5nIG9m ZiBlZmZpY2llbmN5IGZvciBnZW5lcmFsaXR5OyBzaW5jZSBMTE4gbm9kZXMgZG8gbm90IGhhdmUg cmVzb3VyY2VzIHRvIHdhc3RlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+VGhlc2Ugc3BlY2lm aWMgcHJvcGVydGllcyBjYXVzZSBMTE5zIHRvIGhhdmUgc3BlY2lmaWMgcm91dGluZyByZXF1aXJl bWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDAw NTAiPkV4aXN0aW5nIHJvdXRpbmcgcHJvdG9jb2xzIHN1Y2ggYXMgT1NQRiwgSVMtSVMsIEFPRFYs IGFuZCBPTFNSIGhhdmUgYmVlbiBldmFsdWF0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgKGRyYWZ0 LWxldmlzLXJvbGwtb3ZlcnZpZXctcHJvdG9jb2xzLTAwKQ0KIGFuZCBoYXZlIGluIHRoZWlyIGN1 cnJlbnQgZm9ybSBiZWVuIGZvdW5kIHRvIG5vdCBzYXRpc2Z5IGFsbCBvZiB0aGVzZSBzcGVjaWZp YyByb3V0aW5nIHJlcXVpcmVtZW50cyDigJxSb3V0aW5nIFJlcXVpcmVtZW50cyBmb3IgVXJiYW4g TG93LVBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrc+KAnSBSRkMgNTU0OCwg4oCcSW5kdXN0cmlhbCBS b3V0aW5nIFJlcXVpcmVtZW50cyBpbiBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtz4oCdIFJG QyA1NjczLCDigJxIb21lIEF1dG9tYXRpb24NCiBSb3V0aW5nIFJlcXVpcmVtZW50cyBpbiBMb3ct UG93ZXIgYW5kIExvc3N5IE5ldHdvcmtz4oCdIFJGQyA1ODI2LCBCdWlsZGluZyBBdXRvbWF0aW9u IFJvdXRpbmcgUmVxdWlyZW1lbnRzIGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgUkZD IDU4NjcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5UaGUgV29ya2luZyBHcm91cCBpcyBmb2N1 c2VkIG9uIHJvdXRpbmcgaXNzdWVzIGZvciBMTE4gYW5kIG1haW50YWluaW5nIHRoZSBwcm90b2Nv bHMgZGV2ZWxvcGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5UaGVyZSBpcyBhIHdpZGUgc2NvcGUgb2Yg YXBwbGljYXRpb24gYXJlYXMgZm9yIExMTnMsIGluY2x1ZGluZyBpbmR1c3RyaWFsIG1vbml0b3Jp bmcsIGJ1aWxkaW5nIGF1dG9tYXRpb24gKEhWQUMsIGxpZ2h0aW5nLCBhY2Nlc3MgY29udHJvbCwN CiBmaXJlKSwgY29ubmVjdGVkIGhvbWVzLCBoZWFsdGggY2FyZSwgZW52aXJvbm1lbnRhbCBtb25p dG9yaW5nLCB1cmJhbiBzZW5zb3IgbmV0d29ya3MgKGUuZy4gU21hcnQgR3JpZCksIGFzc2V0IHRy YWNraW5nLiBUaGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uIHJvdXRpbmcgc29sdXRpb25zIGZv ciBhIHN1YnNldCBvZiB0aGVzZTogY29ubmVjdGVkIGhvbWUsIGJ1aWxkaW5nIGFuZCB1cmJhbiBz ZW5zb3IgbmV0d29ya3MgZm9yIHdoaWNoIHJvdXRpbmcNCiByZXF1aXJlbWVudHMgaGF2ZSBiZWVu IHNwZWNpZmllZC4gVGhlc2UgYXBwbGljYXRpb24tc3BlY2lmaWMgcm91dGluZyByZXF1aXJlbWVu dCBkb2N1bWVudHMgd2VyZSB1c2VkIGZvciBwcm90b2NvbCBkZXNpZ24uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+VGhlIFdvcmtpbmcgR3JvdXAgZm9jdXNlcyBvbiBJUHY2 IHJvdXRpbmcgYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgZm9yIHRoZXNlIGFwcGxpY2F0aW9uIHNj ZW5hcmlvcy4gVGhlIEZyYW1ld29yayB3aWxsIHRha2UgaW50byBjb25zaWRlcmF0aW9uDQogdmFy aW91cyBhc3BlY3RzIGluY2x1ZGluZyBoaWdoIHJlbGlhYmlsaXR5IGluIHRoZSBwcmVzZW5jZSBv ZiB0aW1lIHZhcnlpbmcgbG9zcyBjaGFyYWN0ZXJpc3RpY3MgYW5kIGNvbm5lY3Rpdml0eSB3aGls ZSBwZXJtaXR0aW5nIGxvdy1wb3dlciBvcGVyYXRpb24gd2l0aCB2ZXJ5IG1vZGVzdCBtZW1vcnkg YW5kIENQVSBwcmVzc3VyZSBpbiBuZXR3b3JrcyBwb3RlbnRpYWxseSBjb21wcmlzaW5nIGEgdmVy eSBsYXJnZSBudW1iZXIgKHNldmVyYWwgdGhvdXNhbmRzKQ0KIG9mIG5vZGVzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBkb2N1 bWVudCBob3cgZGF0YSBwYWNrZXRzIGFyZSByb3V0ZWQgYW5kIGVuY2Fwc3VsYXRlZCB3aGVuIHRo ZXkgY3Jvc3MgdGhlIExMTiwgYW5kIHdoZW4gdGhleSBlbnRlciBhbmQgZXhpdCB0aGUgTExOOiB0 aGUgYXBwcm9wcmlhdGUNCiB1c2Ugb2YgUlBJIChSRkM2NTUzKSwgUkgzIChSRkM2NTU0KSBhbmQg SVB2Ni1pbi1JUHY2IGVuY2Fwc3VsYXRpb24gaW5jbHVkaW5nIGhvdyByb3V0aW5nIGxvb3BzIGFy ZSBkZXRlY3RlZC4gSW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIDZsbyBXRywgdGhlIFdvcmtpbmcg R3JvdXAgd2lsbCBkZXNpZ24gYSBtZXRob2QgdG8gY29tcHJlc3MgdGhlc2Ugcm91dGluZyBoZWFk ZXJzIGludG8gYSBzaW5nbGUgYmxvY2suIFRoZSBXR0xDIG9uIHRoaXMgd29yaw0KIHdpbGwgYmUg c2hhcmVkIHdpdGggNmxvLiBUaGUgV29ya2luZyBncm91cCB3aWxsIGFsaWduIHdpdGggdGhlIDZt YW4gV0cgd2hlbiBuZWVkZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+ Uk9MTCBpcyByZXNwb25zaWJsZSBmb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHByb3RvY29scyB0aGF0 IGlzIGhhcyBkZXZlbG9wZWQsIGluY2x1ZGluZyBSUEwgYW5kIE1QTC4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj5Xb3JrIEl0ZW1zIGFyZTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj4tIEd1aWRhbmNlIGluIHVzaW5n IFJGQzY1NTMsIFJGQzY1NTQsIGFuZCBJUHY2LWluLUlQdjYgZW5jYXBzdWxhdGlvbi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM1MDAwNTAiPi0gQ29tcHJlc3Npb24gb2YgJm5ic3A7UkZDNjU1MywgUkZDNjU1 NCwgYW5kIElQIGhlYWRlcnMgaW4gdGhlIDZMb1dQQU4gYWRhcHRhdGlvbiBsYXllciBjb250ZXh0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+LQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkFkZGl0 aW9uYWwgcHJvdG9jb2wgZWxlbWVudHMgdG8gcmVkdWNlIHBhY2tldCBzaXplIGFuZCB0aGUgYW1v dW50IG9mIHJlcXVpcmVkIHJvdXRpbmcgc3RhdGVzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+LSBBdXRvbWF0aWMgc2VsZWN0 aW9uIG9mIE1QTCBmb3J3YXJkZXJzIHRvIHJlZHVjZSBtZXNzYWdlIHJlcGxpY2F0aW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNTAwMDUwIj4tIERhdGEgbW9kZWxzIGZvciBSUEwgYW5kIE1QTCBtYW5hZ2Vt ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNTAwMDUwIj4tIEFsdGVybmF0aXZlIE11bHRpY2FzdCBhbGdv cml0aG0gYmFzZWQgb24gQmllciBmb3J3YXJkaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0gTWV0aG9kcyB0byBp bXByb3ZlIG9yIGNvcnJlY3QgJm5ic3A7dGhlIGN1cnJlbnQgUlBMIGJlaGF2aW91ciBhbmQgdGhl IG90aGVyIHByb3RvY29scyBkZWZpbmVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRBVEUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWlsZXN0b25l PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNlcHRlbWJlciAyMDE3ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JlY2hhcnRl ciBXRyBvciBjbG9zZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NYXJjaCAyMDE3ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luaXRp YWwgc3VibWlzc2lvbiBvZiBkcmFmdCBhYm91dCBZQU5HIFJQTCBtb2RlbCB0byBJRVNHPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkphbnVhcnkgMjAxNyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbml0aWFsIHN1Ym1pc3Npb24gb2YgZHJhZnQgYWJvdXQg TVBMIHNlbGVjdGlvbiB0byBJRVNHPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdmVtYmVyIDIw MTYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW5pdGlhbCBzdWJt aXNzaW9uIG9mIGRyYWZ0IGFib3V0IEJpZXIgTXVsdGljYXN0IHRvIElFU0c8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+T2N0b2JlciAyMDE2ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1N1Ym1pdCBkcmFmdCBhYm91dCBZQU5HIE1QTCBtb2RlbCB0byBJRVNH PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkF1Z3VzdCAyMDE2ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luaXRpYWwgU3VibWlzc2lvbiBvZiB0 aGUgZHJhZnQgYWJvdXQgd2hlbiB0byB1c2UgUkZDNjU1MywgUkZDNjU1NCwgYW5kIElQdjYtaW4t SVB2NiBlbmNhcHN1bGF0aW9uIERyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8gdG8NCiB0aGUg SUVTRy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWF5IDIwMTYgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW5p dGlhbCBzdWJtaXNzaW9uIG9mIHRoZSBkcmFmdCBhYm91dCBob3cgdG8gY29tcHJlc3MgUkZDNjU1 MywgUkZDNjU1NCwgYW5kIElQIGhlYWRlcnMgaW4gdGhlIDZMb1dQQU4gYWRhcHRhdGlvbiBsYXll ciBjb250ZXh0LiAmbmJzcDt0bw0KIHRoZSBJRVNHLiBkcmFmdC1pZXRmLXJvbGwtcm91dGluZy1k aXNwYXRjaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+Tm92ZW1iZXIgMjAxNiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtJbml0aWFsIFN1Ym1pc3Npb24gb2YgdGhlIE5vLVBhdGggREFPIFByb2JsZW0gU3Rh dGVtZW50IHRvIHRoZSBJRVNHPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIwMTYtMDYtMzAgMTI6MTEgR01UJiM0MzswMzowMCBwZXRlciB2 YW4gZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0B4czRhbGwubmwiIHRhcmdl dD0iX2JsYW5rIj5zdG9rY29uc0B4czRhbGwubmw8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBDZW5rLDxicj4NCjxicj4NCnRoYW5r cyBmb3IgeW91ciBzdWdnZXN0aW9ucy48YnI+DQpJIGNhbm5vdCByZWZyYWluIGZyb20gcmVhY3Rp bmcsIGFuZCBzZWUgYmVsb3cuPGJyPg0KPGJyPg0KQ2VuayBHw7xuZG9nYW4gc2NocmVlZiBvcCAy MDE2LTA2LTI5IDE3OjA0OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlbGxvIFBldGVyLDxicj4NCjxicj4NCkkgYmVsaWV2ZSBQYXNjYWwgcHJvcG9z ZWQgdG8ga2VlcCBpdCBpbiBhIG1vcmUgZ2VuZXJpYyBmb3JtPGJyPg0KJnF1b3Q7aW1wcm92ZW1l bnRzIHRvIHRoZSBSUEwgcm91dGluZyBwcm90b2NvbCZxdW90Oy48YnI+DQo8YnI+DQpPdGhlcndp c2UsIHJlYWQgb24gZm9yIG15IGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgZm9ybWVyIHdvcmRpbmc6 PGJyPg0KSSBwcm9wb3NlIHdlIGRyb3AgYW55IGZvcm0gb2YgdW5jZXJ0YWludHkgYW5kIGNoYW5n ZSB0aGUgJnF1b3Q7YW5kL29yJnF1b3Q7IHRvICZxdW90O2FuZCZxdW90Oy48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KbXVjaCBiZXR0ZXIuPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kbHksICZxdW90O3BhY2tldCBzaXplJnF1b3Q7 IHNvdW5kcyBhIGxpdHRsZSBiaXQgdG9vIGdlbmVyaWMsIGhvdyBhYm91dDxicj4NCiZxdW90O2Nv bnRyb2wgcGFja2V0IHNpemVzJnF1b3Q7LDxicj4NCm9yICZxdW90O1JQTCByZWxhdGVkIHBhY2tl dCBzaXplcyZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSSB3YXMgYWxzbyB0 aGlua2luZyBvZiB0aGUgaGVhZGVycywgYW5kIElQIGluIElQIGhlYWRlcnM7IGFuZCB3aGF0ZXZl ciBtYXkgY29tZTsgc28gSSBwcmVmZXIgcGFja2V0IHNpemUgKE5PVCB0byBiZSBjb25mdXNlZCB3 aXRoIHBheWxvYWQgc2l6ZSk8YnI+DQpJdCBsb29rcyBnZW5lcmFsIGFuZCBzdGlsbCBjb25jcmV0 ZSBlbm91Z2guPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcmRseSwgd291bGQgJnF1b3Q7cmVkdWNlIC4uLiB0aGUgYW1vdW50IG9mIHJlcXVpcmVk IHJvdXRpbmcgc3RhdGVzJnF1b3Q7PGJyPg0KYmUgYSBiZXR0ZXIgY2hvaWNlPyBJdCBoaW50cyB0 byBhIHJlZHVjdGlvbiBvZiBtZW1vcnkgd2hpbGUgc3RpbGwgcHJvdmlkaW5nIGFuPGJyPg0Kb3Bl cmF0aW9uYWwgKGNvbnZlcmdlZCkgRE9EQUcuPGJyPg0KVGhlIHByb3Bvc2VkIGZvcm0gJnF1b3Q7 cmVkdWNlIC4uLiB0aGUgYW1vdW50IG9mIGFjY3VtdWxhdGVkIHJvdXRpbmc8YnI+DQpzdGF0ZXMm cXVvdDsgY291bGQgYWxzbzxicj4NCnJlZmVyIHRvIGRyb3Agc3RhdGVzIGFuZCBkZWNyZWFzZSB0 aGUgcXVhbGl0eSBvZiB0aGUgcm91dGluZyBwcm90b2NvbDxicj4NCndoaWxlIGRvaW5nIHNvLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpyZXF1aXJlZCBpdCBpczxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KQ2VuazxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPdGhlciBz dWdnZXN0aW9ucyBvciBpbXByb3ZlbWVudHM/PGJyPg0KPGJyPg0KSWYgbm90IHdlIHNlbmQgbmV3 IHRleHQgb24gbW9uZGF5L3R1ZXNkYXkuPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4N Cjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlBldGVyPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFz cz0iaW0iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAwNi8yOS8yMDE2IDA5OjA1IEFNLCBwZXRlciB2YW4gZGVyIFN0b2sgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBBbGwsPGJyPg0KPGJyPg0KSWYgSSB1bmRlcnN0YW5k IGNvcnJlY3RseSB0aGUgZGlzY3Vzc2lvbiwgdGhlIHByb3Bvc2FsIGlzIHRvIHJlcGxhY2U8YnI+ DQo8YnI+DQomcXVvdDtBZGRpdGlvbmFsIHByb3RvY29sIHRvJm5ic3A7IHJlZHVjZSBwYXRocyBm b3IgUlBMIGluIG5vbi1zdG9yaW5nIG1vZGUuJnF1b3Q7PGJyPg0KPGJyPg0KYnk8YnI+DQo8YnI+ DQomcXVvdDtBZGRpdGlvbmFsIHByb3RvY29sIGVsZW1lbnRzIHRvIHJlZHVjZSBwYWNrZXQgc2l6 ZSBhbmQvb3IgdGhlIGFtb3VudCBvZiBhY2N1bXVsYXRlZCByb3V0aW5nIHN0YXRlcy4mcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f7829a0333174a46ba135ed5f803f6faXCHRCD001ciscocom_-- From nobody Wed Jul 6 07:54:14 2016 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 5BDA912D108 for ; Wed, 6 Jul 2016 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 oEq6_-e0L2lr for ; Wed, 6 Jul 2016 07:54:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6FA12D106 for ; Wed, 6 Jul 2016 07:54:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 406052002A; Wed, 6 Jul 2016 11:02:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC1D3638D1; Wed, 6 Jul 2016 10:54:08 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Routing Over Low power and Lossy networks , peter van der Stok Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:54:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context > I think it is time to work on compressing RPL DIOs and DAOs as well, > wouldn=E2=80=99t you say? I did some work some time ago (2012?) using GHC on RPL messages, and the re= sult was very encouraging. To me, it just fits into the maintenance of the specification. We don't need to list every single thing unless there will be a series of milestones associated with the work. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV30bjYCLcPvd0N1lAQJeCwf+LJC/y69dPoQAIwb/IcbOb+GO0JyHNW0v e9T3ugtrRY+1vYGfXy98TWof/q26rFfgUcCT5Mr8peLANzihLjwc9wxsCHxTvAeJ g18udV84uxh4Pfj2pl7mI0ZfQkB2ZW55zTydZNlD0pUc0ORbxBn+87PUXRKacLRW xMKAMkBlYgK9vU6VP7rHZzQ2f4oBHuChyWh1xqp43d52Q/h4Z1a3hHUviMVkBqPn XxZoNpA6oM5Z+sBoxRYoAnJD9DJpJm88lsgoyQ/CkHBPVYJtQrMAaZHG0Net/cCC K/8E+ApS6+eKMVQneTOc+FtsZ4D8jVqcbCloafzElpapko6nYUEI9A== =NwHF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 6 08:14:52 2016 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 B636F12D151 for ; Wed, 6 Jul 2016 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 wjqYdVN5lKWX for ; Wed, 6 Jul 2016 08:14:45 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 3148412D091 for ; Wed, 6 Jul 2016 08:14:45 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id z126so115668512wme.0 for ; Wed, 06 Jul 2016 08:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DGgEJeyuOzNtaZdbaz6CNncCdB/CRjpBUEwA1wASHWs=; b=AwrB0Q2WinqhNBLWGFKmcDzjOs0HXQDEmNbUOvmtBVbzGObsvaqUYXQKHTv9NlQ+bR gHEs+EKmQZx/E8/pMnfDYD8/2WaLIr96Ud9vEV+DHYFWbm6xPJ/Zec8KMczrBIrwbCGq 9akDlA/JbvgQ1Q6yuvj0h/yLuYl73VizA9Do5P7SNGhE6GlZ2zBBaaXrBHDvWtW3uLXS UHKWzu2DbjuQ6bPq8r9P+tqfqUVa8GRMeDF3fOSpN7hK/b1eebizdRdsFqMlNPpqXxOb HWuIxSRhc1yaMDi9AXsJtjBeO/KS6B5srpGNZBGTBUgsuQhA5rc8/BIUbE6xnzeSrrON 47WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DGgEJeyuOzNtaZdbaz6CNncCdB/CRjpBUEwA1wASHWs=; b=M42wmDoii7ny4DlWZX1bTzmVcuOvVMMdSMLU6mgRNiKWQwEUSETLiyrMPcUk1ZpjQg B8A5G87WppTukr5BA+PWyjOa5ygZTTPbGLmIeaFdlm1nB/gr6BbQLYGlEG1HAQvYemI1 MuLFlE/NiVQh9Hi/uj/FYDEUXK6j1bVP+pPV+fOBybXnwuHVhmgJqeIq52WBirYzRig8 wTIFnXHuw7WaUlBdqAnPMIdvQvN8KrtAbwi4VzbgfaeoDzAjEDocecOhH5rK36RpFuHv Nt2SaHPcxxS83w0JD54f7o9wfVQKzj/nRf0MkW18FpRSK0GmjTU12mqxdW1XCXZ9cmse 7bBg== X-Gm-Message-State: ALyK8tIj3LMp5ucD5+A5c7BYDvCadVPqpKw6ET8mdhITCSdrechP4e97T1XhuwNje3dqRw== X-Received: by 10.28.86.214 with SMTP id k205mr20882897wmb.17.1467818083451; Wed, 06 Jul 2016 08:14:43 -0700 (PDT) Received: from [192.26.176.176] ([192.26.176.176]) by smtp.googlemail.com with ESMTPSA id i74sm6995686wmg.21.2016.07.06.08.14.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 08:14:42 -0700 (PDT) To: roll@ietf.org References: From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: Date: Wed, 6 Jul 2016 17:14:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 15:14:51 -0000 Hey *, --- 5.3) The question in this scenario is how the root knows how to address the IPv6-in-IPv6 header. It can not know that the destination isn't RPL aware, so it must insert an IPv6 header that can be removed on the last RPL aware node. Since the root can not know in a storing network where the last RPL aware node is, the IPv6-in-IPv6 header must be added hop-by-hop along the path from root to leaf. --- in section 5.3 it is said that the sender does not know whether the destinationaddress is rpl-aware or not. This might be true for P2P traffic, but for root->leaf traffic, I would expect that the root knows that. There is the Transit Option for DAOs with the 'E' flag to indicate that the target address was not learned from rpl. I would expect that this 'E' flag is set for all Transit Options in DAOs until it reaches the root node (recursively). So the root node should actually be aware which address was learned from RPL and which not. IMO, the actual problem why we need IPIP is _not_ that the root node isn't aware whether the destination is rpl aware or not, but rather that the root node does not know which node the last rpl-aware router is, in case the destination is ~raf. So, I would suggest to remove the sentence `` It can not know that the destination isn't RPL aware, so it must insert an IPv6 header that can be removed on the last RPL aware node. `` Secondly, Figure 1 is not used like Peter pointed out. I would suggest to remove this figure, because it is not very related to the content of this document. Cenk On 07/06/2016 02:14 PM, peter van der Stok wrote: > Hi Authors, > > Below my review of the document. > > Although the subject is tedious, the draft looks important to me to > assure inter-operability between implementations > > This version was much more readable than the first one. So, I mostly > signal nits and typos. > It is important that someone with more implementation experience also > carefully reviews the document to signal missing text. > > Below my comments, > > Peter > > ______________________________________________________________________________________ > > > Review of RPLinfo version 05. > Intro, last line, change to: “… type 3 {RFC6554], an efficient > IP-in-IP technique, and use cases …”. > Section 3, Figure 1 is not referred to in the text. > Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed > by the phrase “The numbers …” > Page 5, line 3: leaf -> leafs > Page 5, line 7: “is mentioned as well as” -> “is often named” > Page 6, figure 3 is not referred to. > Page 7, phrase 2, “This is a fundamental” -> “A fundamental” > Page 8, line 8,”to add to remove” -> “to add or remove” > Page 8, line 22, “In tables” -> “In table 1” > Page 8, line 25, complete -> extensive > Section 5, phrase 1 change to: “In storing mode (fully stateful), the > sender cannot determine whether the destination is RPL-capable and > thus ….” > Section 5, line 9, indicates when (when to be added) > Page 9, last line; don’t understand: “and are the RPL root node.” > Page 10, line 6: remove: “in order to be able to” > Section 5.2, line 3, insert -> inserts; send ->sends > Section 5.3 and section 5.2: If the 6LBR does not know whether > destination is Raf or not_Raf in section 5.3, then this is also the > case in section 5.2. Question why is the IPv6-in-IPv6 header not also > used in section 5.2. The problem for the 6LBR is the same. > The text in section 5.3 seems to suggest that at each 6LR the > IPv6-in-IPv6 is removed and then re-added again. I would expect the > row re-added headers be filled in under 6LR. > Other question: how does the last 6LR know that the next node is a > not_Raf? > Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also > refers to the following sections 5.x > Section 5.8 and section 5.6; same question as for section 5.3 and > section 5.2. > Section 5.9, line 11, sending 6LN to (“6LN to” added) > Section 5.10, line 4, remove “sends” > Page 16, “Alternatively, …. Compress.” I miss a lot of context to > understand this paragraph. > Section 5.11, line 5, addresses -> addressed > Section 5.11, line 6, subject of “must send” misses. > Section 5.12, The phrase “The IP-in-IP header must be addressed on a > hop-by-hop basis” suggests that the header is removed and re-inserted > at every hop. Nevertheless, that is not mentioned in the accompanying > table. This is the same question I have for earlier sections 5.x. > Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the > destination! > Section 6.2, “the traffic originates with an RPL aware node”. What do > you mean? 6LBR is RPL aware? The destination is known to 6LBR because > destination is RPL aware? Or something else? > Section 6.3, My interpretation: In 6LBR the RH3 is added and modified > in each consecutive 6LR until it is fully consumed and removed in the > last 6LR. > Section 6.3, You cite several alternatives. I suggest to only mention > the solution without RPI. > Section 6.5, line 3, remoted -> removed > Identical to storing mode case (please mention section). > Section 6.6 same remark about RPI as section 6.3 > Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in > earlier section 6.x you use IPv6 node. Why? > Section 7.1, line 6, stiaution -> approach > Section 7.1, line 10; what is a “single code path”? > Section 7.2, line 1, This -> In > Section 7.2 line 3, all DODAG nodes, (added DODAG) > Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate > IPv6 nodes”? If not, I don’t understand the phrase. > Section 7.2, line 20, there are -> there is > > From nobody Wed Jul 6 08:51:54 2016 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 CCFB012D60C for ; Wed, 6 Jul 2016 08:51:51 -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 o0VoqkWMOfhI for ; Wed, 6 Jul 2016 08:51:48 -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 1A9B312D1AD for ; Wed, 6 Jul 2016 08:51:47 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id FTrl1t00E4h15BW01TrlSM; Wed, 06 Jul 2016 17:51:45 +0200 Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([92.133.19.197]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 06 Jul 2016 17:51:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Jul 2016 17:51:45 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <18245.1467816848@obiwan.sandelman.ca> References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> <18245.1467816848@obiwan.sandelman.ca> Message-ID: <6c6ec0d6be3b1f474e1deaea7aace0d2@xs4all.nl> X-Sender: stokcons@xs4all.nl (4wVssSu49EO4dtY7OVX6FzpHaMf007lu) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 15:51:52 -0000 > > To me, it just fits into the maintenance of the specification. > We don't need to list every single thing unless there will be a series > of > milestones associated with the work. > I sympathize with Michael's remark. Is there an associated milestone before June 2017? The idea is to have a limited set of concrete subjects with corresponding realistic milestones Peter From nobody Wed Jul 6 11:02:20 2016 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 51AA612D523 for ; Wed, 6 Jul 2016 11:02:19 -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 FwIV51gM4yfC for ; Wed, 6 Jul 2016 11:02:17 -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 7892812D528 for ; Wed, 6 Jul 2016 11:02:06 -0700 (PDT) Received: from sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 9E0CE1F8EF; Wed, 6 Jul 2016 18:02:04 +0000 (UTC) Received: by sandelman.ca (Postfix, from userid 179) id 58A5D6A571; Wed, 6 Jul 2016 14:02:03 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-reply-to: <6c6ec0d6be3b1f474e1deaea7aace0d2@xs4all.nl> References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> <18245.1467816848@obiwan.sandelman.ca> <6c6ec0d6be3b1f474e1deaea7aace0d2@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Wed, 06 Jul 2016 17:51:45 +0200." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jul 2016 14:02:03 -0400 Message-ID: <3031.1467828123@dooku.sandelman.ca> Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:02:19 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> To me, it just fits into the maintenance of the specification. We >> don't need to list every single thing unless there will be a series of >> milestones associated with the work. > I sympathize with Michael's remark. Is there an associated milestone > before June 2017? The idea is to have a limited set of concrete > subjects with corresponding realistic milestones I'm not sure if I'm answering your ? or just emphasizing the point... I said: "series of milestones" here. If we are taking on work that is more than a single document, then I think we need IESG and charter support. If it's just a single document, and it shows up, then when we adopt it, we insert a milestone. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXfUeZAAoJEKD0KQ7Gj3P2n3wIAIeDemhoG2oBecrjv1fkkfxy YsDukEBIyzTtY+bnCleYj5wd94K6SoJm/tvL+GUYNyOgvqeJ0vTuR8BJ8Lu1bUf/ fBVoyy4GbBAgD6MLNvjdxAih6YkuAGTkA/98nPudfUZP/+QEXs0ej6pFGOe+OibD PNNslGmsnAey83fENcVRCZeC9iooJjdFE1QN2KIU0R9VzKqfypk9ho/xOOKS1Umk tKUPB0awxKz9vjB+ONrGrygzLHkRCdv3ti6hWS0lX8rWgi7NxSAjuvBXBzgyNONC XB5hawiB+zyTdppJSoqb3+iSSOuGCnCEOKpBm+ApO+dO0X+hIKHtW+wAq9qtbHg= =HYWH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 7 00:21:55 2016 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 EBFF912D131 for ; Thu, 7 Jul 2016 00:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 aPf3T6r98hNi for ; Thu, 7 Jul 2016 00:21:52 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA8012B04B for ; Thu, 7 Jul 2016 00:21:52 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id FjMp1t0074WfiVN01jMpzX; Thu, 07 Jul 2016 09:21:50 +0200 Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([92.133.19.197]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 07 Jul 2016 09:21:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2016 09:21:49 +0200 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3031.1467828123@dooku.sandelman.ca> References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> <18245.1467816848@obiwan.sandelman.ca> <6c6ec0d6be3b1f474e1deaea7aace0d2@xs4all.nl> <3031.1467828123@dooku.sandelman.ca> Message-ID: <30bd9ca12b47cacd94910a387cda4fb4@xs4all.nl> X-Sender: stokcons@xs4all.nl (6BZfk8OI5PLMQwKpbmM0ESP+gk/ROGQD) User-Agent: XS4ALL Webmail Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 07:21:55 -0000 We seem to be in agreement. I just wanted to emphasize that when detailed concrete subjects with associated draft turn up, we make this clear in the milestones. Which means that the list of subjects can be more general. And indeed, not everything we have in mind needs a milestone now. I was not thinking about IESG approval procedures. Peter Michael Richardson schreef op 2016-07-06 20:02: > peter van der Stok wrote: > >> To me, it just fits into the maintenance of the specification. > We > >> don't need to list every single thing unless there will be a > series of > >> milestones associated with the work. > > > > I sympathize with Michael's remark. Is there an associated > milestone > > before June 2017? The idea is to have a limited set of concrete > > subjects with corresponding realistic milestones > > I'm not sure if I'm answering your ? or just emphasizing the point... > > I said: "series of milestones" here. > > If we are taking on work that is more than a single document, then I > think we > need IESG and charter support. If it's just a single document, and it > shows > up, then when we adopt it, we insert a milestone. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Jul 7 01:07:38 2016 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 B98A312D1AF for ; Thu, 7 Jul 2016 01:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 UZODdknuoTEI for ; Thu, 7 Jul 2016 01:07:36 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 9C07412D0F4 for ; Thu, 7 Jul 2016 01:07:35 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id z126so138183131wme.0 for ; Thu, 07 Jul 2016 01:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=LH7uc73KlqfQLouEhGjUy0HhdCEmr42LvXpYe3UQ7Ss=; b=qqAKxa27jAhMB1gg4aBo4hUQhEbArVTopcSk49q8oPl8GI1UmKf8Q2zg26nJ0tb/Ah 84y1SJAJkm1ezx/Uhph2cQoZHPZuMkJgEAHULoIU5bAsZi2lRPTHucZp8tRshQJBsISB hyZxYiH5vE69nUyJw/WGays7fbQl7vaQfQLBZo1sZRxexUm5ax8HtZWp7/XEssnKGj4c m0KAH+Lcvba8OtVqgJBuNfaYw87edaErRE6WjWjJSP7s/jDkDGbfVGZZyNRIpRWSD44E /9nZU3PeyunzqOKdpF493zjt+6nJD0OwUPisrmv5XOxtD+zBldz0Z3nns78XowuAuOl5 SWKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LH7uc73KlqfQLouEhGjUy0HhdCEmr42LvXpYe3UQ7Ss=; b=kLPxfoDe+h8snJbWGcvfMMffzU1ubHdgtTMc3rf7LjrcZrH9kruUZQCvnw74hGQJdi VyZK4EzFwwuqJ4Ys4CjIYwx5b/HwxHzlkKyuRsye4kzLx2yLN6pE2B7Kifz5wPbXyXMO OA12/ZvJ1IJeetPrFYH7rmtwE+ozDjwqGodANEWKBC0vz2l3WLTW2TBwc4iTcj7TLQ3A c6p3D7RUZK77Z2hcnIeKZzIz4odYNy8lkhHmRpGb1seNlgoCZkYWkynXWVs+hqRZ6NRd 35+r1AES2gMOIx2obQ/zXPITz8ySnjydaG2KfBdyw1rKcCWqeZTePTlCj5DBh/aHZ3Ar n9DQ== X-Gm-Message-State: ALyK8tIYbuKabK+tqgYSOmLhIU8uyucX+vs6MCTey4lHC0Yr2qW8KJ+omUKcE/E9PTJZqw== X-Received: by 10.28.228.69 with SMTP id b66mr24099043wmh.25.1467878853849; Thu, 07 Jul 2016 01:07:33 -0700 (PDT) Received: from [192.26.176.176] ([192.26.176.176]) by smtp.googlemail.com with ESMTPSA id l1sm2683523wjy.17.2016.07.07.01.07.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2016 01:07:33 -0700 (PDT) To: roll@ietf.org References: From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <8bd985a5-ded0-b5f3-8750-e0fb24c852ef@gmail.com> Date: Thu, 7 Jul 2016 10:07:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 08:07:38 -0000 Hello Peter, > Other question: how does the last 6LR know that the next node is a not_Raf? I would try to answer this question in the following way: I expect routes that were found _not_ with RPL, but e.g. configured manually or through any other mechanism to be marked somehow differently than routes that were accumulated with DAOs. How to mark routes "differently" seems to be implementation specific. (but this information would be used to fill in the `E` flag of Transit Options in DAOs later). So, if a rpl router forwards a packet downwards (storing-mode), it somehow needs to know whether the (dst;next-hop) pair in a forwarding table is rpl-born or not. If it is not rpl-born, then the IPIP header containing the RPI must be removed before continuing the forwarding process, otherwise the IPIP+RPI is re-added and targeted to the next-hop. You probably noticed that I used many "somehows" and generalized a lot in the text above, but this process looks very blurry to me. Any RPL veterans available to make things clearer? Cenk On 07/06/2016 02:14 PM, peter van der Stok wrote: > Hi Authors, > > Below my review of the document. > > Although the subject is tedious, the draft looks important to me to > assure inter-operability between implementations > > This version was much more readable than the first one. So, I mostly > signal nits and typos. > It is important that someone with more implementation experience also > carefully reviews the document to signal missing text. > > Below my comments, > > Peter > > ______________________________________________________________________________________ > > > Review of RPLinfo version 05. > Intro, last line, change to: “… type 3 {RFC6554], an efficient > IP-in-IP technique, and use cases …”. > Section 3, Figure 1 is not referred to in the text. > Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed > by the phrase “The numbers …” > Page 5, line 3: leaf -> leafs > Page 5, line 7: “is mentioned as well as” -> “is often named” > Page 6, figure 3 is not referred to. > Page 7, phrase 2, “This is a fundamental” -> “A fundamental” > Page 8, line 8,”to add to remove” -> “to add or remove” > Page 8, line 22, “In tables” -> “In table 1” > Page 8, line 25, complete -> extensive > Section 5, phrase 1 change to: “In storing mode (fully stateful), the > sender cannot determine whether the destination is RPL-capable and > thus ….” > Section 5, line 9, indicates when (when to be added) > Page 9, last line; don’t understand: “and are the RPL root node.” > Page 10, line 6: remove: “in order to be able to” > Section 5.2, line 3, insert -> inserts; send ->sends > Section 5.3 and section 5.2: If the 6LBR does not know whether > destination is Raf or not_Raf in section 5.3, then this is also the > case in section 5.2. Question why is the IPv6-in-IPv6 header not also > used in section 5.2. The problem for the 6LBR is the same. > The text in section 5.3 seems to suggest that at each 6LR the > IPv6-in-IPv6 is removed and then re-added again. I would expect the > row re-added headers be filled in under 6LR. > Other question: how does the last 6LR know that the next node is a > not_Raf? > Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also > refers to the following sections 5.x > Section 5.8 and section 5.6; same question as for section 5.3 and > section 5.2. > Section 5.9, line 11, sending 6LN to (“6LN to” added) > Section 5.10, line 4, remove “sends” > Page 16, “Alternatively, …. Compress.” I miss a lot of context to > understand this paragraph. > Section 5.11, line 5, addresses -> addressed > Section 5.11, line 6, subject of “must send” misses. > Section 5.12, The phrase “The IP-in-IP header must be addressed on a > hop-by-hop basis” suggests that the header is removed and re-inserted > at every hop. Nevertheless, that is not mentioned in the accompanying > table. This is the same question I have for earlier sections 5.x. > Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the > destination! > Section 6.2, “the traffic originates with an RPL aware node”. What do > you mean? 6LBR is RPL aware? The destination is known to 6LBR because > destination is RPL aware? Or something else? > Section 6.3, My interpretation: In 6LBR the RH3 is added and modified > in each consecutive 6LR until it is fully consumed and removed in the > last 6LR. > Section 6.3, You cite several alternatives. I suggest to only mention > the solution without RPI. > Section 6.5, line 3, remoted -> removed > Identical to storing mode case (please mention section). > Section 6.6 same remark about RPI as section 6.3 > Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in > earlier section 6.x you use IPv6 node. Why? > Section 7.1, line 6, stiaution -> approach > Section 7.1, line 10; what is a “single code path”? > Section 7.2, line 1, This -> In > Section 7.2 line 3, all DODAG nodes, (added DODAG) > Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate > IPv6 nodes”? If not, I don’t understand the phrase. > Section 7.2, line 20, there are -> there is > > From nobody Thu Jul 7 04:18:39 2016 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 DF89D12D0B2 for ; Thu, 7 Jul 2016 04:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 oiyW_l-x2n8K for ; Thu, 7 Jul 2016 04:18:35 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC3612D17B for ; Thu, 7 Jul 2016 04:18:35 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id FnJZ1t0024aYjWA01nJZTD; Thu, 07 Jul 2016 13:18:33 +0200 Received: from AMontpellier-654-1-251-68.w92-133.abo.wanadoo.fr ([92.133.142.68]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 07 Jul 2016 13:18:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2016 13:18:32 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <4fad9a644c561d0a2f632edad1d4beb3@xs4all.nl> X-Sender: stokcons@xs4all.nl (4OGv67COX3ELF6LpkgVO0iAwW0E9QVxv) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 11:18:38 -0000 HI Cenk, > There is the Transit Option for DAOs with the 'E' flag > to indicate that the target address was not learned from rpl. > I would expect that this 'E' flag is set for all Transit Options in > DAOs > until it reaches the root node (recursively). > So the root node should actually be aware which > address was learned from RPL and which not. It is probably worthwhile to describe (remind) in the draft this procedure for the root to learn RPL associated addresses. Peter From nobody Thu Jul 7 04:20:17 2016 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 4DF5C12D190 for ; Thu, 7 Jul 2016 04:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 t2cmwc8-Kkog for ; Thu, 7 Jul 2016 04:20:15 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E2E12D197 for ; Thu, 7 Jul 2016 04:20:14 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id FnLD1t0034aYjWA01nLDnR; Thu, 07 Jul 2016 13:20:13 +0200 Received: from AMontpellier-654-1-251-68.w92-133.abo.wanadoo.fr ([92.133.142.68]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 07 Jul 2016 13:20:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2016 13:20:13 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8bd985a5-ded0-b5f3-8750-e0fb24c852ef@gmail.com> References: <8bd985a5-ded0-b5f3-8750-e0fb24c852ef@gmail.com> Message-ID: X-Sender: stokcons@xs4all.nl (kbC4BBJ32tB0Irof7kSYXsNMSK1Nmufa) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 11:20:16 -0000 Hi Cenk > You probably noticed that I used many "somehows" and generalized a lot > in the text above, > but this process looks very blurry to me. > Any RPL veterans available to make things clearer? > So, this certainly warrant extra text in the draft. Peter From nobody Fri Jul 8 06:31:00 2016 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 7F1EA12D5C2 for ; Fri, 8 Jul 2016 06:30:58 -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 AXI4lHQVGVBv for ; Fri, 8 Jul 2016 06:30:55 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 8186112D114 for ; Fri, 8 Jul 2016 06:30:55 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id r135so5379441vkf.3 for ; Fri, 08 Jul 2016 06:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qzhqwxOZkQzjcdNDE3d7QVWteRQ5y6hDL98GKyQHZXc=; b=NuKBbpbzMf963I/9wOTuafJwcBnsxCDx8wnzHAIOZqJK6JlxbSM0eCOM1lydqq3AUU JdPp2ldgGF50j9POAB+czxdYpMSbpfBPHjAt0ooT0DhQG2ajZmMFsed+uU80gRQQ0aOI YiK4noj9fbw/LoPUMsMm552AKB1D6cWn4ZADywgt51Xl/Odo31ar3yYAeJE1Ss830vRH qHcYoJUMRSUEOLsS2CHTF4tj1z2G5FB3p0Oi/TsCr1RW8VBw9lzPo1sqbsJLrzkmgldj ytaJCyfQTDzuDRy5jmbsZXET1ffC4oXniWuCfe9GX8w98t3ZvEHK/qZ1mN5niMcYvu94 Egqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qzhqwxOZkQzjcdNDE3d7QVWteRQ5y6hDL98GKyQHZXc=; b=Ghw+9RsX9JDbpDhucXcoUonCeHbCfN78s3vq3qJckYHa12yfAr6vHl18gyI+Wvcc6p R3Blo0tDtNWLrEgORdqt0EV0vO2P8itiYDDKROelHWHRJl0iptSb94IilDpck7CFBDGt g7MG7fjyukw9+vG+IgRSXcu1Z726brXlEcmiA1Flnp3enfmJ58z/O18jv1LKEeqnyyd+ 0ene5NN3ih+0gHOrCl6I/oKVXWVpH7+11VNOJP+wsWWJvXhJP/oVgWpGmQG+99Ei1jGr yF9RI7m/d1Uj+vsL5/C5h17jMvdV3CC5Mpx5Fll/F1SETO2SJK/v/PtiMxkG7h6J+Mcu 3T9g== X-Gm-Message-State: ALyK8tIC5i6r+y17RWjzqpQuwexE2DOr83j36cVz1A6oHnRa6JthXJoiJot7VeIGcRIMjhOKfPRjUYB8U832mQ== X-Received: by 10.31.86.69 with SMTP id k66mr2777637vkb.7.1467984654219; Fri, 08 Jul 2016 06:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Fri, 8 Jul 2016 06:30:53 -0700 (PDT) In-Reply-To: <30bd9ca12b47cacd94910a387cda4fb4@xs4all.nl> References: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com> <17987.1467118035@obiwan.sandelman.ca> <7887a2c930bd4eb3b90da72e2bbe914b@XCH-RCD-001.cisco.com> <18245.1467816848@obiwan.sandelman.ca> <6c6ec0d6be3b1f474e1deaea7aace0d2@xs4all.nl> <3031.1467828123@dooku.sandelman.ca> <30bd9ca12b47cacd94910a387cda4fb4@xs4all.nl> From: Ines Robles Date: Fri, 8 Jul 2016 16:30:53 +0300 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a114e50f6d9bf4c05371fcf4b Archived-At: Cc: Michael Richardson , Routing Over Low power and Lossy networks Subject: Re: [Roll] Request for Comments for ROLL Charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:30:58 -0000 --001a114e50f6d9bf4c05371fcf4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Pascal, about this: "I think it is time to work on compressing RPL DIOs and DAOs as well, wouldn=E2=80=99t you say?" - Very nice would be to have some work on that := -) Would it be inside of this proposed work item: "Additional protocol elements to reduce packet size and the amount of required routing states"?. I think it agrees what Michael suggested. Additionally, about milestones/work-items: "...Every WG has milestones that the WG is supposed to meet, such as the publication of a particular Internet- Draft or the beginning of discussion on a particular topic. A WG's charter has several parts; one of those parts is the milestones. Changing milestones currently requires Area Director (AD) approval, but changing the charter text requires IESG approval..... ... ...While most milestones map one-to-one with Internet-Drafts, some milestones do not map to any Internet-Draft (such as those that say when a general discussion will begin or finish), and other milestones map to multiple Internet-Drafts (such as a milestone that covers a topic that has multiple related Internet-Drafts). Some Internet-Drafts are part of more than one milestone." [RFC 6433] In here: "...Goals and milestones The working group charter MUST establish a timetable for specific work items. While this may be renegotiated over time, the list of milestones and dates facilitates the Area Director's tracking of working group progress and status, and it is indispensable to potential participants identifying the critical moments for input. Milestones shall consist of deliverables that can be qualified as showing specific achievement; e.g., "Internet-Draft finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. This milestone list is expected to be updated periodically..." [RFC 2418] -- I understand here that milestones and work items are the same. Cheers, Ines. 2016-07-07 10:21 GMT+03:00 peter van der Stok : > We seem to be in agreement. > I just wanted to emphasize that when detailed concrete subjects with > associated draft turn up, we make this clear in the milestones. > Which means that the list of subjects can be more general. > And indeed, not everything we have in mind needs a milestone now. > > I was not thinking about IESG approval procedures. > > Peter > > Michael Richardson schreef op 2016-07-06 20:02: > > peter van der Stok wrote: >> >> To me, it just fits into the maintenance of the specification. W= e >> >> don't need to list every single thing unless there will be a >> series of >> >> milestones associated with the work. >> >> >> > I sympathize with Michael's remark. Is there an associated >> milestone >> > before June 2017? The idea is to have a limited set of concrete >> > subjects with corresponding realistic milestones >> >> I'm not sure if I'm answering your ? or just emphasizing the point... >> >> I said: "series of milestones" here. >> >> If we are taking on work that is more than a single document, then I >> think we >> need IESG and charter support. If it's just a single document, and it >> shows >> up, then when we adopt it, we insert a milestone. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a114e50f6d9bf4c05371fcf4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Pascal, about this:

"I think it is time to work on compressing RPL DI= Os and DAOs as well, wouldn=E2=80=99t you say?" - Very nice would be t= o have some work on that :-)

Would it be inside of= this proposed work item: "Additional protocol elements to reduce pack= et size and the amount of required routing states"?. I think it agrees= what Michael suggested.


Additional= ly, about milestones/work-items:=C2=A0

"...Ev= ery WG has milestones that the WG is
=C2=A0 =C2=A0supposed to mee= t, such as the publication of a particular Internet-
=C2=A0 =C2= =A0Draft or the beginning of discussion on a particular topic.=C2=A0 A WG&#= 39;s
=C2=A0 =C2=A0charter has several parts; one of those parts i= s the milestones.
=C2=A0 =C2=A0Changing milestones currently requ= ires Area Director (AD) approval,
=C2=A0 =C2=A0but changing the c= harter text requires IESG approval.....
=C2=A0 =C2=A0...
=C2=A0...While most milestones map one-to-one with Internet-Drafts,
=
=C2=A0 =C2=A0some milestones do not map to any Internet-Draft (such as= those that
=C2=A0 =C2=A0say when a general discussion will begin= or finish), and other
=C2=A0 =C2=A0milestones map to multiple In= ternet-Drafts (such as a milestone that
=C2=A0 =C2=A0covers a top= ic that has multiple related Internet-Drafts).=C2=A0 Some
=C2=A0 = =C2=A0Internet-Drafts are part of more than one milestone." [RFC 6433]= =C2=A0

In here:

"...= Goals and milestones
=C2=A0 =C2=A0 =C2=A0 The working group chart= er MUST establish a timetable for specific
=C2=A0 =C2=A0 =C2=A0 w= ork items.=C2=A0 While this may be renegotiated over time, the list of
=C2=A0 =C2=A0 =C2=A0 milestones and dates facilitates the Area Direct= or's tracking of
=C2=A0 =C2=A0 =C2=A0 working group progress = and status, and it is indispensable to
=C2=A0 =C2=A0 =C2=A0 poten= tial participants identifying the critical moments for input.
=C2= =A0 =C2=A0 =C2=A0 Milestones shall consist of deliverables that can be qual= ified as
=C2=A0 =C2=A0 =C2=A0 showing specific achievement; e.g.,= "Internet-Draft finished" is
=C2=A0 =C2=A0 =C2=A0 fine= , but "discuss via email" is not. It is helpful to specify
<= div>=C2=A0 =C2=A0 =C2=A0 milestones for every 3-6 months, so that progress = can be gauged
=C2=A0 =C2=A0 =C2=A0 easily.=C2=A0 This milestone l= ist is expected to be updated
=C2=A0 =C2=A0 =C2=A0 periodically..= ." [RFC 2418] -- I understand here that milestones and work items are = the same.

Cheers,

Ines.

2016-07-07 10= :21 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">We seem to be in agreement.
I just wanted to emphasize that when detailed concrete subjects with associ= ated draft turn up, we make this clear in the milestones.
Which means that the list of subjects can be more general.
And indeed, not everything we have in mind needs a milestone now.

I was not thinking about IESG approval procedures.

Peter

Michael Richardson schreef op 2016-07-06 20:02:

peter van der Stok <stokcons@xs4all.nl> wrote:
=C2=A0 =C2=A0 >> To me, it just fits into the maintenance of the spec= ification.=C2=A0 We
=C2=A0 =C2=A0 >> don't need to list every single thing unless the= re will be a series of
=C2=A0 =C2=A0 >> milestones associated with the work.


=C2=A0 =C2=A0 > I sympathize with Michael's remark.=C2=A0 Is there a= n associated milestone
=C2=A0 =C2=A0 > before June 2017?=C2=A0 The idea is to have a limited se= t of concrete
=C2=A0 =C2=A0 > subjects with corresponding realistic milestones

I'm not sure if I'm answering your ? or just emphasizing the point.= ..

I said: "series of milestones" here.

If we are taking on work that is more than a single document, then I think = we
need IESG and charter support.=C2=A0 If it's just a single document, an= d it shows
up, then when we adopt it, we insert a milestone.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-

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

--001a114e50f6d9bf4c05371fcf4b-- From nobody Mon Jul 11 07:54:07 2016 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 470AC12D51D for ; Mon, 11 Jul 2016 07:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 IJguVXkD9Mbv for ; Mon, 11 Jul 2016 07:54:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1960612D51B for ; Mon, 11 Jul 2016 07:54:05 -0700 (PDT) Received: from localhost ([::1]:55743 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bMcay-0000d2-Hf; Mon, 11 Jul 2016 07:54:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-richardson-roll-applicability-template@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 11 Jul 2016 14:54:04 -0000 X-URL: https://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/roll/trac/ticket/169#comment:1 Message-ID: <083.336d9088e9743dbfe13d81b9e17918e7@trac.tools.ietf.org> References: <068.cc19fb0606bb8fa414dd1ec2580c6837@trac.tools.ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <068.cc19fb0606bb8fa414dd1ec2580c6837@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-richardson-roll-applicability-template@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-richardson-roll-applicability-template@ietf.org Resent-Message-Id: <20160711145405.1960612D51B@ietfa.amsl.com> Resent-Date: Mon, 11 Jul 2016 07:54:05 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #169 (draft-richardson-roll-applicability-template): Work Item Proposals X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 14:54:06 -0000 #169: Work Item Proposals Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed Comment: Items can be discuss for a proposed new charter in IETF 96. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-richardson-roll- mariainesrobles@gmail.com | applicability- Type: task | template@tools.ietf.org Priority: minor | Status: closed Component: draft-richardson-roll- | Milestone: applicability-template | Version: Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Tue Jul 12 23:56:56 2016 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 0EE1B12B028 for ; Tue, 12 Jul 2016 23:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 MrholGw_UtZz for ; Tue, 12 Jul 2016 23:56:52 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 AEF6A128E19 for ; Tue, 12 Jul 2016 23:56:51 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id f7so52914301vkb.3 for ; Tue, 12 Jul 2016 23:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=jUZ7ZJd4zN+XX88zvmacBgZh5r7p4h5OOrJ24dAp0Ss=; b=JYrYHq60U2NsBFNrJch5XlK8HrXmv3mEJq4eSVZemnjdFeaX5lz9REChs8UrhnR/3F wlTbyG/ozVAtTxgrHomza1uBkolTvWsLIM26jnZ5pox14tcK3WNRnj2ln6ay6rWix34H Vf266sb2FUD0HVYUyzr9kpPNdeNKM5vHZbUEaOvnHh6VvojAmG2qEFYR5jdhkbx+Q35p l0pUL3tUFSwPWQM6AZeZSqNOq2nsH32tB8IKT8M8hpAxeKBuCbGP9mIHNMzo7XcJlcu9 jyZOsX5stK+EZS8jiBn86X6NpDsZHuqmtWrnZPzu0RnA5BFUQSZtES96fvGLU/g3sb1A LURA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=jUZ7ZJd4zN+XX88zvmacBgZh5r7p4h5OOrJ24dAp0Ss=; b=MBaV2eN2M2+lSLoLRyB97qw3XyNOWZuFT2LXfmeHd5k7//3P4ULOlJv6Almgi43zfZ +zHKrwwbiErSQmSq1HdVxXFvOLlIOWgeC3q/HsR4db9WSc5GpqTg/QUqBBlOs0qOL98A EI1mGckDct72Y52YRQgJpJO7heiI+WE+1HTt5hFDqixWq9+S1h9cmjvfrEKmnYj/Y+cj rYo5IrwyqPaRiqeFotH8k6/1J7USmLKNCY4i/Usvx1Fg3HhHQkRN8zdKsdIhK5bIRulx Ogs05Wp54L8df1GcMJLzpYq+eL2y5JKo6NHCVm6qkKTMQKW6KAA+Sfa86YyaphgodxC+ nu3w== X-Gm-Message-State: ALyK8tIkqI4nOUgSS1nNVdnuUWnhLbcjbagVhj5WW9Tt9sUGD/KeKDcop4t3tCKJsM/hUtCWJ392JvaI8ZMY6g== X-Received: by 10.159.35.40 with SMTP id 37mr3164529uae.118.1468393010682; Tue, 12 Jul 2016 23:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Tue, 12 Jul 2016 23:56:50 -0700 (PDT) From: Ines Robles Date: Wed, 13 Jul 2016 09:56:50 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a113bcc7ecae30405377ee3e5 Archived-At: Cc: peter van der Stok , Samita Chakrabarti Subject: [Roll] Request for Comments for ROLL Charter - version 4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 06:56:54 -0000 --001a113bcc7ecae30405377ee3e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, Please find a new version of the charter. Thanks to Samita for the suggestions. Last changes: A- Old: "The Working group will align with the 6man WG when needed." New: " ROLL will coordinate closely with the working groups in other areas that focus on constrained node networks, such as 6lo (Internet) and CoRE (APP).The Working group will align with the 6man WG when needed." B- Old: " Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context" New: " Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context" (co-ordinated with 6lo WG). Comments are welcome. Thank you, Peter and Ines ///////////////////////////////////////////////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= ///////// CHARTER PROPOSAL: Charter for Working Group Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs are characterized as follows, but not limited to: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group (draft-levis-roll-overview-protocols-00) and have in their current form been found to not satisfy all of these specific routing requirements =E2=80=9CRouting Requirements for Urban Low-Power and = Lossy Networks=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing Requirements in Low= -Power and Lossy Networks=E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requirements i= n Low-Power and Lossy Networks=E2=80=9D RFC 5826, Building Automation Routing Requirements = in Low-Power and Lossy Networks RFC 5867. The Working Group is focused on routing issues for LLN and maintaining the protocols developed by the working group. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design. The Working Group focuses on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will document how data packets are routed and encapsulated when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. ROLL will coordinate closely with the working groups in other areas that focus on constrained node networks, such as 6lo (Internet) and CoRE (APP).T= he Working group will align with the 6man WG when needed. ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. (co-ordinated with 6lo WG). - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication - Data models for RPL and MPL management - Alternative Multicast algorithm based on Bier forwarding. - Methods to improve or correct the current RPL behaviour and the other protocols defined by the working group. Milestones DATE Milestone September 2017 Recharter WG or close March 2017 Initial submission of draft about YANG RPL model to IESG January 2017 Initial submission of draft about MPL selection to IES= G November 2016 Initial submission of draft about Bier Multicast to IESG October 2016 Submit draft about YANG MPL model to IESG August 2016 Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG. May 2016 Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. to the IESG. draft-ietf-roll-routing-dispatch November 2016 Initial Submission of the No-Path DAO Problem Statement to the IESG --001a113bcc7ecae30405377ee3e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find a new version of = the charter. Thanks to Samita for the suggestions.

Last changes:

A-

Old: "Th= e Working group will align with the 6man WG when needed."
=

N= ew: "=C2=A0ROLL=C2=A0will coordinate clo= sely with the working groups in other=C2=A0areas that focus on constrained node networks, such as 6lo (Internet) = and=C2=A0CoRE (APP).The Working group will align with the 6man WG whe= n needed."=C2=A0
B-

Old: "=C2=A0Compre= ssion of =C2=A0RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation l= ayer context"

New: "=C2=A0<= /span>Compression of =C2=A0RFC6553, RFC6554, and IP he= aders in the 6LoWPAN adaptation layer context"=C2=A0(co-ordinated with 6lo WG).


Comme= nts are welcome.

Thank you,

Peter and Ines

////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= ////////////////////////////////////////////////////

= CHARTER PROPOSAL:


= Charter for Working Group


Low power a= nd Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded = devices with limited power, memory, and processing resources. They are inte= rconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Pow= er WiFi, wired or other low power PLC (Powerline Communication) links. LLNs= are transitioning to an end-to-end IP-based solution to avoid the problem = of non-interoperable networks interconnected by protocol translation gatewa= ys and proxies.


Ge= nerally speaking, LLNs are characterized as follows, but not limited to:


LLNs operate with a = hard, very small bound on state.


In = most cases, LLN optimize for saving energy by using small packet headers an= d reduce amount of control packets.


Typical traffic patterns are not simply unicast flows (e.= g. in some cases most if not all traffic can be point to multipoint).


In most cases, LLNs wil= l be employed over link layers with restricted frame-sizes and low bit rate= s, thus a routing protocol for LLNs should be specifically adapted for such= link layers.


LLN= routing protocols have to be very careful when trading off efficiency for = generality; since LLN nodes do not have resources to waste.


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12.6667px;font-family:Arial;color:rgb(80,0,80);vert= ical-align:baseline;white-space:pre-wrap">These specific properties cause L= LNs to have specific routing requirements.



Existing routing protocols such as OSPF, IS-IS= , AODV, and OLSR have been evaluated by the working group (draft-levis-roll= -overview-protocols-00) and have in their current form been found to not sa= tisfy all of these specific routing requirements =E2=80=9CRouting Requireme= nts for Urban Low-Power and Lossy Networks=E2=80=9D RFC 5548, =E2=80=9CIndu= strial Routing Requirements in Low-Power and Lossy Networks=E2=80=9D RFC 56= 73, =E2=80=9CHome Automation Routing Requirements in Low-Power and Lossy Ne= tworks=E2=80=9D RFC 5826, Building Automation Routing Requirements in Low-P= ower and Lossy Networks RFC 5867.


The Working Group is focused on routing issues for LLN and = maintaining the protocols developed by the working group.


There is a wide scope of applic= ation areas for LLNs, including industrial monitoring, building automation = (HVAC, lighting, access control, fire), connected homes, health care, envir= onmental monitoring, urban sensor networks (e.g. Smart Grid), asset trackin= g. The Working Group focuses on routing solutions for a subset of these: co= nnected home, building and urban sensor networks for which routing requirem= ents have been specified. These application-specific routing requirement do= cuments were used for protocol design.

The Working Group focuses on IPv6 routing architectural fr= amework for these application scenarios. The Framework will take into consi= deration various aspects including high reliability in the presence of time= varying loss characteristics and connectivity while permitting low-power o= peration with very modest memory and CPU pressure in networks potentially c= omprising a very large number (several thousands) of nodes.


<= br>

The Working Group will document how data packets= are routed and encapsulated when they cross the LLN, and when they enter a= nd exit the LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IP= v6-in-IPv6 encapsulation including how routing loops are detected. In consu= ltation with the 6lo WG, the Working Group will design a method to compress= these routing headers into a single block. The WGLC on this work will be s= hared with 6lo.


ROLL=C2=A0will coordinate c= losely with the working groups in other=C2=A0areas that focus on constrained node networks, such as 6lo (Inter= net) and=C2=A0CoRE (APP).The Working group will= align with the 6man WG when needed.


<= /span>

ROLL is responsible fo= r maintenance of the protocols that is has developed, including RPL and MPL= .



Work Items = are:

- Guidance in usi= ng RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.


- Compression of =C2=A0RFC6553, RFC655= 4, and IP headers in the 6LoWPAN adaptation layer context. (co-ordinated with 6lo WG).


- Additional protocol = elements to reduce packet size and the amount of required routing states


- Automatic selection of MPL forwarder= s to reduce message replication


- Data models for RPL and MPL management


- Alternative Multicast algorithm base= d on Bier forwarding.


- Methods to im= prove or correct =C2=A0the current RPL behaviour and the other protocols de= fined by the working group.



Miles= tones


DATE =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Milestone

September 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial submission of draft about YANG RPL model to IESG<= /span>

January 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MPL selection to IES= G

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial submission of draft about Bier Multicast to IESG<= /span>

October 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model to IESG

August 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Initial Submission of the draft about when to use RFC6553, R= FC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the = IESG.

May 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of the d= raft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN = adaptation layer context. =C2=A0to the IESG. draft-ietf-roll-routing-dispat= ch

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Initial Submission of the No-Path DAO Problem Statement t= o the IESG
--001a113bcc7ecae30405377ee3e5-- From nobody Wed Jul 13 02:35:19 2016 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 4FC3F12D69F for ; Wed, 13 Jul 2016 02:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OAZlOFU2_aZ9 for ; Wed, 13 Jul 2016 02:35:14 -0700 (PDT) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (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 AB58012D0E7 for ; Wed, 13 Jul 2016 02:35:14 -0700 (PDT) Received: by mail-vk0-f42.google.com with SMTP id v6so57275031vkb.2 for ; Wed, 13 Jul 2016 02:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtOihCXcGi4X7WmskMnGaHAQurLan6p2A5BhBk4E8Es=; b=hA9MXmy3KErxXbU/bExoUHvGU1jQWdccI5SWsANh/0Z+v4yxu+jgaVZXD3z6ZtNHV/ IBbt1AeV0K0V3AB168Uv8yACqXKHbyRMwCXURsVYVAo/CvwPRQfrlPVo+vJjrDwrRFR1 X2qtahJwS6n7dYsFl9j3lxNgIMDh+mqT4G4sgvRFgES+QrihAWL7TqH/xxBJA9aa4Vk1 S7d5VxQL0lVtiKYl22+xnG6U20RIzmXVvoJ8lnr/UVvpqvwWH2ZCwmyOX7nPhk+asUsh kVfSf1WFzCH4Hp0MYXNO2eMgtFa0bQfbQ5AKrK9oc2IA0jIB5URKqQptMEzyst4BcY2T MgWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PtOihCXcGi4X7WmskMnGaHAQurLan6p2A5BhBk4E8Es=; b=HH6Rs66psz7NPJJgr70NStem65oWGa/w65MOEMnirByRlkix0UVXQxi7nZzKDpkIOk aewgkZNaGrnRNNwjcjL0yeU2q0raGbHQv97PNodh9D49D+4Hs6s8xcxyK2fc+XQhf16e 2l1LEOf+ABDgdYwTim4KVnsEfAWul0jaLZi8zHNEdqA+/4gc3ym0Xa962cdQf9DGkzzl 1Mf+ZccqkhYFw41QxjGHfND+JkqS7bB8JlLkzGFv4YDlTp0Va0TqOb9mx7S6RQD4EzFg KNkaEfT24DVVbDie8hgVkyqID4Qu8BLFtbv0DujSxqydi4bgOdp08EnIhjbo5TCljkPa M+Jg== X-Gm-Message-State: ALyK8tJXz7C5w+7+cvKTrA+6Besi/ED2LoEZgrv1Xbo64+XchFUfp0yQEC27z0uZ6Q8JLM9NRZu4PUv7l5SeEQ== X-Received: by 10.176.65.71 with SMTP id j65mr3421548uad.103.1468402453704; Wed, 13 Jul 2016 02:34:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Wed, 13 Jul 2016 02:34:13 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Wed, 13 Jul 2016 12:34:13 +0300 Message-ID: To: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=94eb2c124708a3fa9a05378116c2 Archived-At: Cc: Kovatsch Matthias Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:35:17 -0000 --94eb2c124708a3fa9a05378116c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much Peter for your comments, We are going to address the nits/typos in the next version About your questions. P: Section 5.3 and section 5.2: If the 6LBR does not know whether destination is Raf or not_Raf in section 5.3, then this is also the case in section 5.2. Question why is the IPv6-in-IPv6 header not also used in section 5.2. The problem for the 6LBR is the same. -Thanks for the correction. Here, the text should say: "6LBR knows that the destination is not_Raf". We have to describe how 6LBR does know it. We need help in here. The 6LBR knows when a node is raf, since the downward route is built with DAOs. What do you think? -Other question: how does the last 6LR know that the next node is a not_Raf= ? thank you very much to Cenk for answering this. as he said, it would be good to have more comments on that. Cheers, Ines. 2016-07-06 15:14 GMT+03:00 peter van der Stok : > Hi Authors, > > Below my review of the document. > > Although the subject is tedious, the draft looks important to me to assur= e > inter-operability between implementations > > This version was much more readable than the first one. So, I mostly > signal nits and typos. > It is important that someone with more implementation experience also > carefully reviews the document to signal missing text. > > Below my comments, > > Peter > > > _________________________________________________________________________= _____________ > > Review of RPLinfo version 05. > Intro, last line, change to: =E2=80=9C=E2=80=A6 type 3 {RFC6554], an effi= cient IP-in-IP > technique, and use cases =E2=80=A6=E2=80=9D. > Section 3, Figure 1 is not referred to in the text. > Page 5: Reorder phrases: first the phrase =E2=80=9CIn the figure 2,=E2=80= =A6=E2=80=9D followed by > the phrase =E2=80=9CThe numbers =E2=80=A6=E2=80=9D > Page 5, line 3: leaf -> leafs > Page 5, line 7: =E2=80=9Cis mentioned as well as=E2=80=9D -> =E2=80=9Cis = often named=E2=80=9D > Page 6, figure 3 is not referred to. > Page 7, phrase 2, =E2=80=9CThis is a fundamental=E2=80=9D -> =E2=80=9CA f= undamental=E2=80=9D > Page 8, line 8,=E2=80=9Dto add to remove=E2=80=9D -> =E2=80=9Cto add or r= emove=E2=80=9D > Page 8, line 22, =E2=80=9CIn tables=E2=80=9D -> =E2=80=9CIn table 1=E2=80= =9D > Page 8, line 25, complete -> extensive > Section 5, phrase 1 change to: =E2=80=9CIn storing mode (fully stateful),= the > sender cannot determine whether the destination is RPL-capable and thus = =E2=80=A6.=E2=80=9D > Section 5, line 9, indicates when (when to be added) > Page 9, last line; don=E2=80=99t understand: =E2=80=9Cand are the RPL roo= t node.=E2=80=9D > Page 10, line 6: remove: =E2=80=9Cin order to be able to=E2=80=9D > Section 5.2, line 3, insert -> inserts; send ->sends > Section 5.3 and section 5.2: If the 6LBR does not know whether destinatio= n > is Raf or not_Raf in section 5.3, then this is also the case in section > 5.2. Question why is the IPv6-in-IPv6 header not also used in section 5.2= . > The problem for the 6LBR is the same. > The text in section 5.3 seems to suggest that at each 6LR the IPv6-in-IPv= 6 > is removed and then re-added again. I would expect the row re-added heade= rs > be filled in under 6LR. > Other question: how does the last 6LR know that the next node is a not_Ra= f? > Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers t= o > the following sections 5.x > Section 5.8 and section 5.6; same question as for section 5.3 and section > 5.2. > Section 5.9, line 11, sending 6LN to (=E2=80=9C6LN to=E2=80=9D added) > Section 5.10, line 4, remove =E2=80=9Csends=E2=80=9D > Page 16, =E2=80=9CAlternatively, =E2=80=A6. Compress.=E2=80=9D I miss a l= ot of context to > understand this paragraph. > Section 5.11, line 5, addresses -> addressed > Section 5.11, line 6, subject of =E2=80=9Cmust send=E2=80=9D misses. > Section 5.12, The phrase =E2=80=9CThe IP-in-IP header must be addressed o= n a > hop-by-hop basis=E2=80=9D suggests that the header is removed and re-inse= rted at > every hop. Nevertheless, that is not mentioned in the accompanying table. > This is the same question I have for earlier sections 5.x. > Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the > destination! > Section 6.2, =E2=80=9Cthe traffic originates with an RPL aware node=E2=80= =9D. What do you > mean? 6LBR is RPL aware? The destination is known to 6LBR because > destination is RPL aware? Or something else? > Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in > each consecutive 6LR until it is fully consumed and removed in the last 6= LR. > Section 6.3, You cite several alternatives. I suggest to only mention the > solution without RPI. > Section 6.5, line 3, remoted -> removed > Identical to storing mode case (please mention section). > Section 6.6 same remark about RPI as section 6.3 > Sections 6.7 =E2=80=93 6.12, Here you use 6LN for not-RPL aware node, whi= le in > earlier section 6.x you use IPv6 node. Why? > Section 7.1, line 6, stiaution -> approach > Section 7.1, line 10; what is a =E2=80=9Csingle code path=E2=80=9D? > Section 7.2, line 1, This -> In > Section 7.2 line 3, all DODAG nodes, (added DODAG) > Section 7.2, line 12, =E2=80=9Cintermediate 6LN nodes=E2=80=9D should be = =E2=80=9Cintermediate > IPv6 nodes=E2=80=9D? If not, I don=E2=80=99t understand the phrase. > Section 7.2, line 20, there are -> there is > > > -- > Peter van der Stok > mailto: consultancy@vanderstok.org > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --94eb2c124708a3fa9a05378116c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much Peter for your comments,

We are going to address the nits/typos in the next version
=
About your questions.

P: Secti= on 5.3 and section 5.2: If the 6LBR does not know whether destination is Ra= f or not_Raf in section 5.3, then this is also the case in section 5.2. Que= stion why is the IPv6-in-IPv6 header not also used in section 5.2. The prob= lem for the 6LBR is the same.

-Thanks for the corr= ection. Here, the text should say: "6LBR knows that the destination is= not_Raf". We have to describe how 6LBR does know it. We need help in = here.

The 6LBR knows when a node is raf, since the= downward route is built with DAOs.

What do you th= ink?

-Other question: how does the last 6LR know t= hat the next node is a not_Raf?

thank you very muc= h to Cenk for answering this. as he said, it would be good to have more com= ments on that.

Cheers,

<= div>Ines.


2016-07-06 15:14 GMT+03:00 peter van der Stok <stokcons@xs4a= ll.nl>:
Hi Authors,

Below my review of the document.

Although the subject is tedious, the draft looks important to me to assure = inter-operability between implementations

This version was much more readable than the first one. So, I mostly signal= nits and typos.
It is important that someone with more implementation experience also caref= ully reviews the document to signal missing text.

Below my comments,

Peter

___________________________________________________________________________= ___________

Review of RPLinfo version 05.
Intro, last line, change to: =E2=80=9C=E2=80=A6 type 3 {RFC6554], an effici= ent IP-in-IP technique, and use cases =E2=80=A6=E2=80=9D.
Section 3, Figure 1 is not referred to in the text.
Page 5: Reorder phrases: first the phrase =E2=80=9CIn the figure 2,=E2=80= =A6=E2=80=9D followed by the phrase =E2=80=9CThe numbers =E2=80=A6=E2=80=9D=
Page 5, line 3: leaf -> leafs
Page 5, line 7: =E2=80=9Cis mentioned as well as=E2=80=9D -> =E2=80=9Cis= often named=E2=80=9D
Page 6, figure 3 is not referred to.
Page 7, phrase 2, =E2=80=9CThis is a fundamental=E2=80=9D -> =E2=80=9CA = fundamental=E2=80=9D
Page 8, line 8,=E2=80=9Dto add to remove=E2=80=9D -> =E2=80=9Cto add or = remove=E2=80=9D
Page 8, line 22, =E2=80=9CIn tables=E2=80=9D -> =E2=80=9CIn table 1=E2= =80=9D
Page 8, line 25, complete -> extensive
Section 5, phrase 1 change to: =E2=80=9CIn storing mode (fully stateful), t= he sender cannot determine whether the destination is RPL-capable and thus = =E2=80=A6.=E2=80=9D
Section 5, line 9, indicates when (when to be added)
Page 9, last line; don=E2=80=99t understand: =E2=80=9Cand are the RPL root = node.=E2=80=9D
Page 10, line 6: remove: =E2=80=9Cin order to be able to=E2=80=9D
Section 5.2, line 3, insert -> inserts; send ->sends
Section 5.3 and section 5.2: If the 6LBR does not know whether destination = is Raf or not_Raf in section 5.3, then this is also the case in section 5.2= . Question why is the IPv6-in-IPv6 header not also used in section 5.2. The= problem for the 6LBR is the same.
The text in section 5.3 seems to suggest that at each 6LR the IPv6-in-IPv6 = is removed and then re-added again. I would expect the row re-added headers= be filled in under 6LR.
Other question: how does the last 6LR know that the next node is a not_Raf?=
Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers to = the following sections 5.x
Section 5.8 and section 5.6; same question as for section 5.3 and section 5= .2.
Section 5.9, line 11, sending 6LN to (=E2=80=9C6LN to=E2=80=9D added)
Section 5.10, line 4, remove =E2=80=9Csends=E2=80=9D
Page 16, =E2=80=9CAlternatively, =E2=80=A6. Compress.=E2=80=9D I miss a lot= of context to understand this paragraph.
Section 5.11, line 5, addresses -> addressed
Section 5.11, line 6, subject of =E2=80=9Cmust send=E2=80=9D misses.
Section 5.12, The phrase =E2=80=9CThe IP-in-IP header must be addressed on = a hop-by-hop basis=E2=80=9D suggests that the header is removed and re-inse= rted at every hop. Nevertheless, that is not mentioned in the accompanying = table. This is the same question I have for earlier sections 5.x.
Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the destinati= on!
Section 6.2, =E2=80=9Cthe traffic originates with an RPL aware node=E2=80= =9D. What do you mean? 6LBR is RPL aware? The destination is known to 6LBR = because destination is RPL aware? Or something else?
Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in ea= ch consecutive 6LR until it is fully consumed and removed in the last 6LR.<= br> Section 6.3, You cite several alternatives. I suggest to only mention the s= olution without RPI.
Section 6.5, line 3, remoted -> removed
Identical to storing mode case (please mention section).
Section 6.6 same remark about RPI as section 6.3
Sections 6.7 =E2=80=93 6.12, Here you use 6LN for not-RPL aware node, while= in earlier section 6.x you use IPv6 node. Why?
Section 7.1, line 6, stiaution -> approach
Section 7.1, line 10; what is a =E2=80=9Csingle code path=E2=80=9D?
Section 7.2, line 1, This -> In
Section 7.2 line 3, all DODAG nodes, (added DODAG)
Section 7.2, line 12, =E2=80=9Cintermediate 6LN nodes=E2=80=9D should be = =E2=80=9Cintermediate IPv6 nodes=E2=80=9D? If not, I don=E2=80=99t understa= nd the phrase.
Section 7.2, line 20, there are -> there is


--
Peter van der Stok
mailto: con= sultancy@vanderstok.org

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

--94eb2c124708a3fa9a05378116c2-- From nobody Wed Jul 13 02:39:53 2016 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 2B0A612D5D6 for ; Wed, 13 Jul 2016 02:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 60GWgT5emQWY for ; Wed, 13 Jul 2016 02:39:51 -0700 (PDT) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) (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 DD78412D0E7 for ; Wed, 13 Jul 2016 02:39:50 -0700 (PDT) Received: by mail-vk0-f45.google.com with SMTP id o63so57496595vkg.1 for ; Wed, 13 Jul 2016 02:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FHKaZfzZZb/4E9rci2W6/ec24+P/wzuhUcmOKHteaBk=; b=lJpaIbW3QNcPy4aPN2SiTFOIfI7vK2Fxhih5w+PccHgvDVrdJM1zICp73QIjLEt0FZ Banj0mySA60msl9mWXPVr/34bnWx1ndY/xURE4G23WCkMoHRI6xVnX+8Wv61PBaBTvDs uzjAI/1QxUuhbcvW3S2yf9eLYk8YyTJ0Uo1/fCo52SdAYx93gxnM+b85VTd/YbyyTc6B Rq0qtsPjt2UrCNTRwHha25mMgOrIuSTwhxy4nJJ4Ih81178o8gLw78Ip1iNWVUZzjEfS qn+pkqM0PZXAgoGIlIuBY8MHWTNCcNtO+dRHUNLjd5sD+rehjI96YGw0hkKR3iwf12rk W1HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FHKaZfzZZb/4E9rci2W6/ec24+P/wzuhUcmOKHteaBk=; b=hEr5eQ63vtrhebLn0mwNSnyZ4R2kKGWdoeraYZ4GIJznwAgcRcl886NVygqipcX0pv 4HaIp3ZJavos+TYW2zLjNy1DbEfct340MFtZ63LewrqAbqup9xar7+ZCUkifLdnNbxmA Buf+lrCF74PObKp4sVtweN5vVTJrdMNQEu6nNkOy1VAAfreoogGoPsSQ2rwwawQYaNKy r6kvbTnB4uP6tfohZhgprowl8WDLBw+X3pp4TwYe0QMPkvylAlIqcjwjwyN4D97Fg2Z1 1dWSRllM5rR421/1VfYAwSax2U9zWYZSqkLdJ4wFhb14v5mnI6UrYwGba/6A1O6APD0S Pf+w== X-Gm-Message-State: ALyK8tJhUnauqnYt6bGNcwzl7H7uPQ1E5DUcY3ToZTnWBAW14r+o9RAKUMUx3wvZSbdQfxjs8r4Nyvv61JL1DA== X-Received: by 10.176.4.162 with SMTP id 31mr3512968uaw.81.1468402730074; Wed, 13 Jul 2016 02:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Wed, 13 Jul 2016 02:38:49 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Wed, 13 Jul 2016 12:38:49 +0300 Message-ID: To: =?UTF-8?Q?Cenk_G=C3=BCndogan?= Content-Type: multipart/alternative; boundary=94eb2c1252901d09d90537812705 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:39:52 -0000 --94eb2c1252901d09d90537812705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Cenk, Thank you very much for your suggestions. :-) 2016-07-06 18:14 GMT+03:00 Cenk G=C3=BCndogan : > Hey *, > > --- > .... > > So, I would suggest to remove the sentence > `` > It can not know that the destination isn't > RPL aware, so it must insert an IPv6 header that can be removed on > the last RPL aware node. > Ok, we need to rephrase that section. > `` > > Secondly, Figure 1 is not used like Peter pointed out. > I would suggest to remove this figure, because it is not very > related to the content of this document. I think you mean here Figure 3, and Ok, I think we could keep only the figure that describes the uses cases. Cheers, Ines. > > > Cenk > > > >> --94eb2c1252901d09d90537812705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Cenk,

Thank you very much for your s= uggestions. :-)

2016-07-06 18:14 GMT+03:00 Cenk G=C3=BCndogan <cnkgndgn@gmail.com= >:
Hey *,

---
....

So, I would suggest to remove the sentence
``
It can not know that the destination isn't
=C2=A0 =C2=A0RPL aware, so it must insert an IPv6 header that can be remove= d on
=C2=A0 =C2=A0the last RPL aware node.

O= k, we need to rephrase that section.
``

Secondly, Figure 1 is not used like Peter pointed out.
I would suggest to remove this figure, because it is not very
related to the content of this document.

I = think you mean here Figure 3, and Ok, I think we could keep only the figure= that describes the uses cases.

Cheers,
=
Ines.=C2=A0


Cenk



--94eb2c1252901d09d90537812705-- From nobody Thu Jul 14 06:44:12 2016 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 0095212D128; Thu, 14 Jul 2016 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 klvNKPkYgN7j; Thu, 14 Jul 2016 06:43:39 -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 1A72E12D10B; Thu, 14 Jul 2016 06:43:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,362,1464645600"; d="scan'208,217";a="226719268" Received: from mail-lf0-f51.google.com ([209.85.215.51]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 14 Jul 2016 15:43:35 +0200 Received: by mail-lf0-f51.google.com with SMTP id b199so64332846lfe.0; Thu, 14 Jul 2016 06:43:35 -0700 (PDT) X-Gm-Message-State: ALyK8tLjetIjQNFOKHsI1bc2fSEEiTxKkQ2bdsHDWiueESUORHQJaPNxOPLYKVpIMhFEKuR+r+SqBOS/EF+Aww== X-Received: by 10.46.5.213 with SMTP id 204mr6956284ljf.64.1468503815362; Thu, 14 Jul 2016 06:43:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Thu, 14 Jul 2016 06:43:15 -0700 (PDT) From: Thomas Watteyne Date: Thu, 14 Jul 2016 15:43:15 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lwig@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a114a683e44263e053798b068 Archived-At: Subject: [Roll] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 13:43:42 -0000 --001a114a683e44263e053798b068 Content-Type: text/plain; charset=UTF-8 All, We are organizing an information meeting about F-Interop, an online platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I. F-Interop (www.f-interop.eu) is a platform for online and remote conformance and interoperability testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, ...) The purpose of this info session is to give you a technical overview of the platform, describe how the IETF community can use and contribute to it, and get feedback. The platform is built as part of the 2016-2018 F-Interop H2020 European project. As part of that project, we will have an open call for entities to contribute additional tools and test descriptions to the platform. Selected projects will be funded; we will explain the process during the info session as well. Looking forward to seeing you there, Thomas --001a114a683e44263e053798b068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

We are organizing an in= formation meeting about F-Interop, an online platform for remote interopera= bility testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I.
<= br>
F-Interop (www.f-interop.= eu) is a platform for online and remote conformance and interoperabilit= y testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, .= ..)

The purpose of this info session is to give yo= u a technical overview of the platform, describe how the IETF community can= use and contribute to it, and get feedback.

The p= latform is built as part of the 2016-2018 F-Interop H2020 European project.= As part of that project, we will have an open call for entities to contrib= ute additional tools and test descriptions to the platform. Selected projec= ts will be funded; we will explain the process during the info session as w= ell.

Looking forward to seeing you there,

Thomas
--001a114a683e44263e053798b068-- From nobody Thu Jul 14 07:50:24 2016 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 A6A4F12D7CE; Thu, 14 Jul 2016 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 swjnPcjfccZK; Thu, 14 Jul 2016 07:49:00 -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 DB2C812D7C8; Thu, 14 Jul 2016 07:49:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B75C7B809C9; Thu, 14 Jul 2016 07:49:00 -0700 (PDT) To: mcr@sandelman.ca, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160714144900.B75C7B809C9@rfc-editor.org> Date: Thu, 14 Jul 2016 07:49:00 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 14 Jul 2016 07:50:24 -0700 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6550 (4654) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 14:49:02 -0000 The following errata report has been held for document update for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4654 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Michael Richardson Date Reported: 2016-04-04 Held by: Alvaro Retana (IESG) Section: 2, 5.1, 6.3 Original Text ------------- Section 2 defines DODAGID: DODAGID: A DODAGID is the identifier of a DODAG root. The DODAGID is unique within the scope of a RPL Instance in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. Corrected Text -------------- DODAGID: A DODAGID is the identifier of a DODAG root. The DODAGID MUST be a reachable IPv6 address of the root node. The DODAG MUST be unique within the scope of a RPL Instance in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. Notes ----- section 5.1, and 6.3 also offered definitions of DODAGID, the above text summarizes those sections. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Jul 17 06:55:34 2016 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 10CF212D16D for ; Sun, 17 Jul 2016 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 WBfxeA9jkrNJ for ; Sun, 17 Jul 2016 06:55:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F3712D0C4 for ; Sun, 17 Jul 2016 06:55:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A05912015D for ; Sun, 17 Jul 2016 10:04:50 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 81CB3638D1 for ; Sun, 17 Jul 2016 09:55:29 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Request for Comments for ROLL Charter - version 4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 13:55:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have read the charter, and I do not find anything more to tweak. I would prefer to cut some of the history out, or move it to the end, but I recognize that this may have value to new comers. Do we presently have people willing to contribute to a YANG model? Ines Robles wrote: > CHARTER PROPOSAL: > Charter for Working Group > Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up = of > many embedded devices with limited power, memory, and processing > resources. They are interconnected by a variety of links, such as IEEE > 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC > (Powerline Communication) links. LLNs are transitioning to an > end-to-end IP-based solution to avoid the problem of non-interoperable > networks interconnected by protocol translation gateways and proxies. > Generally speaking, LLNs are characterized as follows, but not limited > to: > LLNs operate with a hard, very small bound on state. > In most cases, LLN optimize for saving energy by using small packet > headers and reduce amount of control packets. > Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if not all traffic can be point to multipoint). > In most cases, LLNs will be employed over link layers with restricted > frame-sizes and low bit rates, thus a routing protocol for LLNs should > be specifically adapted for such link layers. > LLN routing protocols have to be very careful when trading off > efficiency for generality; since LLN nodes do not have resources to > waste. > These specific properties cause LLNs to have specific routing > requirements. > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have > been evaluated by the working group > (draft-levis-roll-overview-protocols-00) and have in their current fo= rm > been found to not satisfy all of these specific routing requirements > =E2=80=9CRouting Requirements for Urban Low-Power and Lossy Networks= =E2=80=9D RFC 5548, > =E2=80=9CIndustrial Routing Requirements in Low-Power and Lossy Netwo= rks=E2=80=9D RFC > 5673, =E2=80=9CHome Automation Routing Requirements in Low-Power and = Lossy > Networks=E2=80=9D RFC 5826, Building Automation Routing Requirements = in > Low-Power and Lossy Networks RFC 5867. > The Working Group is focused on routing issues for LLN and maintaining > the protocols developed by the working group. > There is a wide scope of application areas for LLNs, including > industrial monitoring, building automation (HVAC, lighting, access > control, fire), connected homes, health care, environmental monitorin= g, > urban sensor networks (e.g. Smart Grid), asset tracking. The Working > Group focuses on routing solutions for a subset of these: connected > home, building and urban sensor networks for which routing requiremen= ts > have been specified. These application-specific routing requirement > documents were used for protocol design. > The Working Group focuses on IPv6 routing architectural framework for > these application scenarios. The Framework will take into considerati= on > various aspects including high reliability in the presence of time > varying loss characteristics and connectivity while permitting > low-power operation with very modest memory and CPU pressure in > networks potentially comprising a very large number (several thousand= s) > of nodes. > The Working Group will document how data packets are routed and > encapsulated when they cross the LLN, and when they enter and exit the > LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and > IPv6-in-IPv6 encapsulation including how routing loops are detected. > In consultation with the 6lo WG, the Working Group will design a meth= od > to compress these routing headers into a single block. The WGLC on th= is > work will be shared with 6lo. > ROLL will coordinate closely with the working groups in other areas > that focus on constrained node networks, such as 6lo (Internet) and > CoRE (APP).The Working group will align with the 6man WG when needed. > ROLL is responsible for maintenance of the protocols that is has > developed, including RPL and MPL. > Work Items are: > - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. > - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context. (co-ordinated with 6lo WG). > - Additional protocol elements to reduce packet size and the amount of > required routing states > - Automatic selection of MPL forwarders to reduce message replication > - Data models for RPL and MPL management > - Alternative Multicast algorithm based on Bier forwarding. > - Methods to improve or correct the current RPL behaviour and the oth= er > protocols defined by the working group. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4uOS4CLcPvd0N1lAQIJtQgAhfHKu6nzYayDCVfvEV79EaoIpm59Z7Go w1eYAjLblTa6xMG3mbx3oxSq5fHitSBPuBhCMG1ZYGU9gR/OwZDS7Y7Yzi/0C+7V sUyaGMNZb+oGAguE11cEswTi0IWDOjl0zj38m9C6NKSEptzhf9b51VCmBNgIlB8F cJqEmNQrAyoSQ4e5Lh6vsRoGL2uwtN3a4jmSmeyYVbUm8blwVGYwTvXjA/opOuQL E947wkeKPaa3UVgz/9Hg3dIXepuvZfQr3BpKpBGwNM0+xgNMVyrFWt8o3clublxp XU1ziN5A5JlG2LISTLyhRwypk05rlgzmi23nidZhCdecpZ/XotqeIw== =vX38 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 17 07:07:53 2016 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 4BABD12B051 for ; Sun, 17 Jul 2016 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 58YICjktlDzM for ; Sun, 17 Jul 2016 07:07:49 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 616AE12D0E7 for ; Sun, 17 Jul 2016 07:07:48 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id s189so1397103vkh.1 for ; Sun, 17 Jul 2016 07:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=y/XHAtdpvRGvw3xvEiI3Ge2TYSl4w3ssGW/ZjxK7fUw=; b=sf9iwel3pnO1my0wv8W2o0lujXsEQOfSwywx3xSwWtrFktPqAqCMTOgJu8MqFqYSXN OGCcFlsQaFTpWozSB9RB19XxcpKpykWYsZJ4eEyj0reiXU8ej2vxqu0Ss6jHpA6xZQlW BlPcvGDF7/RybYgN9UhacPXml8P94vKYw8MTayncGYc24PAbuAKmu6/1/oziKRPTiqMZ r5BZx5KuJLv833BNiaMxSltrh51UuhMWmIEUPeXKqpvO/NySf3hcXaUpSxBJB3+B2jwj Nu95skJUYJoTksAvrze7lRpKRV2B8J+Fc29QIDBG3v4fP5gV3uY20eyUQF8bTI6g7q2D A2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=y/XHAtdpvRGvw3xvEiI3Ge2TYSl4w3ssGW/ZjxK7fUw=; b=VFl58yGANzirIXmTmcKMoXhWLF8MAlcOwORbsbicidxT/Y2hFaaKHaHBD5pCZfx36i jBLHg+U3oX2u35fwW0/obPTiptYO5frDi4XyBKseztJ6Yo8z2rMI67uCXhzZyLXhf3VO HaN7o8SynrYvZQV+3O61aiB6w13C88cRMJpCZ5XyUUN1NW4Fk5l/rKVwaZWyqii/lquI qBvMHdb1zb405mJrYTneAB6LYpoWQyg5PlaWuL5oLL9bVR5ASVP6k7y3uNwidW7EDzen CZlzFhHU/xGUhjYq2LSq4Hw1WjSIeb3AWu6BdKuODw324+qaQ6gCPeS8SlIBlvWhTFty K3WA== X-Gm-Message-State: ALyK8tJZz0ZdyDaYPKR16jXVBAuT7FltTQY+9RaTayEG5+7zTu+ha3AfPXNlsye8b3pVwgue3Tcq+JkHD8Bxjg== X-Received: by 10.176.0.108 with SMTP id 99mr15247718uai.71.1468764467067; Sun, 17 Jul 2016 07:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Sun, 17 Jul 2016 07:07:46 -0700 (PDT) From: Ines Robles Date: Sun, 17 Jul 2016 17:07:46 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a113f2ba0517ff50537d560ce Archived-At: Subject: [Roll] Request for Comments for ROLL Charter - version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 14:07:52 -0000 --001a113f2ba0517ff50537d560ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, Please find a new version of the charter. Thanks to Michael for the suggestions. Last changes: A- Old: "Alternative Multicast algorithm based on Bier forwarding.." New: " Alternative Multicast algorithm such as Bier forwarding." Comments are welcome. Thank you, Peter and Ines ///////////////////////////////////////////////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= ///////// CHARTER PROPOSAL: Charter for Working Group Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs are characterized as follows, but not limited to: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group (draft-levis-roll-overview-protocols-00) and have in their current form been found to not satisfy all of these specific routing requirements =E2=80=9CRouting Requirements for Urban Low-Power and = Lossy Networks=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing Requirements in Low= -Power and Lossy Networks=E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requirements i= n Low-Power and Lossy Networks=E2=80=9D RFC 5826, Building Automation Routing Requirements = in Low-Power and Lossy Networks RFC 5867. The Working Group is focused on routing issues for LLN and maintaining the protocols developed by the working group. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design. The Working Group focuses on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will document how data packets are routed and encapsulated when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. ROLL will coordinate closely with the working groups in other areas that focus on constrained node networks, such as 6lo (Internet) and CoRE (APP).T= he Working group will align with the 6man WG when needed. ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. (co-ordinated with 6lo WG). - Additional protocol elements to reduce packet size and the amount of required routing states - Automatic selection of MPL forwarders to reduce message replication - Data models for RPL and MPL management - Alternative Multicast algorithm such as Bier forwarding. - Methods to improve or correct the current RPL behaviour and the other protocols defined by the working group. Milestones DATE Milestone September 2017 Recharter WG or close March 2017 Initial submission of draft about YANG RPL model to IESG January 2017 Initial submission of draft about MPL selection to IES= G November 2016 Initial submission of draft about Bier Multicast to IESG October 2016 Submit draft about YANG MPL model to IESG August 2016 Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplin= fo to the IESG. May 2016 Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. to the IESG. draft-ietf-roll-routing-dispatch November 2016 Initial Submission of the No-Path DAO Problem Statement to the IESG 2016-07-13 9:56 GMT+03:00 Ines Robles : > Dear all, > > Please find a new version of the charter. Thanks to Samita for the > suggestions. > > Last changes: > > A- > > Old: "The Working group will align with the 6man WG when needed." > > New: " ROLL will coordinate closely with the working groups in other area= s > that focus on constrained node networks, such as 6lo (Internet) and CoRE > (APP).The Working group will align with the 6man WG when needed." > > B- > > Old: " Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context" > > New: " Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context" (co-ordinated with 6lo WG). > > > Comments are welcome. > > Thank you, > > Peter and Ines > > > /////////////////////////////////////////////////////////////////////////= ///////////////////////////////////////////////////////////////////////////= /////////// > > CHARTER PROPOSAL: > > Charter for Working Group > > Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of > many embedded devices with limited power, memory, and processing resource= s. > They are interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline > Communication) links. LLNs are transitioning to an end-to-end IP-based > solution to avoid the problem of non-interoperable networks interconnecte= d > by protocol translation gateways and proxies. > > Generally speaking, LLNs are characterized as follows, but not limited to= : > > LLNs operate with a hard, very small bound on state. > > In most cases, LLN optimize for saving energy by using small packet > headers and reduce amount of control packets. > > Typical traffic patterns are not simply unicast flows (e.g. in some cases > most if not all traffic can be point to multipoint). > > In most cases, LLNs will be employed over link layers with restricted > frame-sizes and low bit rates, thus a routing protocol for LLNs should be > specifically adapted for such link layers. > > LLN routing protocols have to be very careful when trading off efficiency > for generality; since LLN nodes do not have resources to waste. > > These specific properties cause LLNs to have specific routing requirement= s. > > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group (draft-levis-roll-overview-protocols-00) a= nd > have in their current form been found to not satisfy all of these specifi= c > routing requirements =E2=80=9CRouting Requirements for Urban Low-Power an= d Lossy > Networks=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing Requirements in L= ow-Power and Lossy > Networks=E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requirements= in Low-Power and > Lossy Networks=E2=80=9D RFC 5826, Building Automation Routing Requirement= s in > Low-Power and Lossy Networks RFC 5867. > > The Working Group is focused on routing issues for LLN and maintaining th= e > protocols developed by the working group. > > > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, health care, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > routing solutions for a subset of these: connected home, building and urb= an > sensor networks for which routing requirements have been specified. These > application-specific routing requirement documents were used for protocol > design. > > The Working Group focuses on IPv6 routing architectural framework for > these application scenarios. The Framework will take into consideration > various aspects including high reliability in the presence of time varyin= g > loss characteristics and connectivity while permitting low-power operatio= n > with very modest memory and CPU pressure in networks potentially comprisi= ng > a very large number (several thousands) of nodes. > > > The Working Group will document how data packets are routed and > encapsulated when they cross the LLN, and when they enter and exit the LL= N: > the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 > encapsulation including how routing loops are detected. In consultation > with the 6lo WG, the Working Group will design a method to compress these > routing headers into a single block. The WGLC on this work will be shared > with 6lo. > > > ROLL will coordinate closely with the working groups in other areas that > focus on constrained node networks, such as 6lo (Internet) and CoRE (APP)= .The > Working group will align with the 6man WG when needed. > > > ROLL is responsible for maintenance of the protocols that is has > developed, including RPL and MPL. > > > Work Items are: > > - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. > > - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context. (co-ordinated with 6lo WG). > > - Additional protocol elements to reduce packet size and the amount of > required routing states > > - Automatic selection of MPL forwarders to reduce message replication > > - Data models for RPL and MPL management > > - Alternative Multicast algorithm based on Bier forwarding. > > - Methods to improve or correct the current RPL behaviour and the other > protocols defined by the working group. > > > Milestones > > DATE Milestone > > September 2017 Recharter WG or close > > March 2017 Initial submission of draft about YANG RPL model to > IESG > > January 2017 Initial submission of draft about MPL selection to > IESG > > November 2016 Initial submission of draft about Bier Multicast to > IESG > > October 2016 Submit draft about YANG MPL model to IESG > > August 2016 Initial Submission of the draft about when to use > RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation > Draft-ietf-roll-useofrplinfo to the IESG. > > May 2016 Initial submission of the draft about how to compres= s > RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. > to the IESG. draft-ietf-roll-routing-dispatch > November 2016 Initial Submission of the No-Path DAO Problem > Statement to the IESG > --001a113f2ba0517ff50537d560ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please fin= d a new=C2=A0version=C2=A0of the=C2=A0charter. Thanks to Michael =C2=A0for the suggestions.

Last= changes:

A-

Old: "Alternative Multicast algorithm based on Bier = forwarding.."
=

N= ew: "=C2=A0Alternative Multicast algorithm such as= Bier forwarding."= =C2=A0

Comments=C2=A0are= welcome.

<= div style=3D"font-size:12.8px">Thank you,

Peter and Ines

//////////= ///////////////////////////////////////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////<= /div>

CHARTER PROPOSAL:


Charter for Wo= rking Group


Low power and Lossy Netwo= rks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with l= imited power, memory, and processing resources. They are interconnected by = a variety of links, such as IEEE 802.15.4, Bluetoot= h, Low Power WiFi, wired or other low power PLC (Powerline Communication) l= inks. LLNs are transitioning to an end-to-end IP-based solution to avoid th= e problem of non-interoperable networks interconnected by protocol translat= ion gateways and proxies.


Generally speaking, LLNs are characterized as follows, but not limi= ted to:


LLNs opera= te with a hard, very small bound on state.


In most cases, LLN optimize for saving energy by using small packet = headers and reduce amount of control packets.


Typical traffic patterns are not simply unicast= flows (e.g. in some cases most if not all traffic can be point to multipoi= nt).


In most cases= , LLNs will be employed over link layers with restricted frame-sizes and lo= w bit rates, thus a routing protocol for LLNs should be specifically adapte= d for such link layers.


LLN routing protocols have to be very careful when trading off effic= iency for generality; since LLN nodes do not have resources to waste.


These specific properti= es cause LLNs to have specific routing requirements.



Existing routing protocols such as O= SPF, IS-IS, AODV, and OLSR have been evaluated by the working group (draft-= levis-roll-overview-protocols-00) and have in their= current form been found to not satisfy all of these specific routing requi= rements =E2=80=9CRouting Requirements for Urban Low-Power and Lossy Network= s=E2=80=9D RFC 5548, =E2=80=9CIndustrial Routing Requirements in Low-Power = and Lossy Networks=E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requ= irements in Low-Power and Lossy Networks=E2=80=9D RFC 5826, Building Automa= tion Routing Requirements in Low-Power and Lossy Networks RFC 5867.<= /p>

The Working Group is focu= sed on routing issues for LLN and maintaining the protocols developed by th= e working group.



There is a wide scope of application areas for LLNs, including industria= l monitoring, building automation (HVAC, lighting, access control, fire), c= onnected homes, health care, environmental monitoring, urban sensor network= s (e.g. Smart Grid), asset tracking. The Working Group focuses on routing s= olutions for a subset of these: connected home, building and urban sensor n= etworks for which routing requirements have been specified. These applicati= on-specific routing requirement documents were used for protocol design.

The Working Group focuse= s on IPv6 routing architectural framework for these application scenarios. = The Framework will take into consideration various aspects including high r= eliability in the presence of time varying loss characteristics and connect= ivity while permitting low-power operation with very modest memory and CPU = pressure in networks potentially comprising a very large number (several th= ousands) of nodes.



The Working Gr= oup will document how data packets are routed and encapsulated when they cr= oss the LLN, and when they enter and exit the LLN: the appropriate use of R= PI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6 encapsulation including how ro= uting loops are detected. In consultation with the 6lo WG, the Working Grou= p will design a method to compress these routing headers into a single bloc= k. The WGLC on this work will be shared with 6lo.


ROLL=C2=A0will coordinate closely with the= working groups in other=C2=A0areas= that focus on constrained node networks, such as 6lo (Internet) and= =C2=A0CoRE (APP).The Working group will align with the= 6man WG when needed.


ROLL is respo= nsible for maintenance of the protocols that is has developed, including RP= L and MPL.



Wo= rk Items are:

- Guidan= ce in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.

- Compression of =C2=A0RFC6553,= RFC6554, and IP headers in the 6LoWPAN adaptation layer context. (co-ordinated with 6lo WG).


- Additional p= rotocol elements to reduce packet size and the amount of required routing s= tates


=

= - Automatic selection of MPL for= warders to reduce message replication


- Data models for RPL and MPL management


=

= - Alternative Multicast algorith= m such as Bier forwarding.


- Methods= to improve or correct =C2=A0the current RPL behaviour and the other protoc= ols defined by the working group.



Milestones


DATE =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Milest= one

September 2017 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about YANG RPL model to= IESG

January 2017 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MPL selection = to IESG

November 2016 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about Bier Multicast to= IESG

October 2016 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model to IESG=

August 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Initial Submission of the draft about when to use RFC6= 553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-ro= ll-useofrplinfo to the IESG.

May 2= 016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Initial submission of the draft about how to compress RFC6553, RFC6554, = and IP headers in the 6LoWPAN adaptation layer context. =C2=A0to the IESG. = draft-ietf-roll-routing-dispatch

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ini= tial Submission of the No-Path DAO Problem Statement to the IESG



2016-07-13 9:56 GMT+03:00 Ines Robles <mariainesrobles@googlemail.com>:
Dear all,

Please find a new version= of the charter. Thanks to Samita for the suggestions.

=
Last changes:

A-

Old: "
New: "=C2=A0ROLL=C2=A0will coordinate= closely with the working groups in other=C2=A0areas that focus on constrained node networks, such as 6lo (Intern= et) and=C2=A0CoRE (APP).The Working group will align with the 6man WG= when needed."=C2=A0

= B-

Old: "=C2=A0Co= mpression of =C2=A0RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptati= on layer context"

<= span style=3D"font-size:12.8px">New: "=C2= =A0Compression of =C2=A0RFC6553, RFC6554, and I= P headers in the 6LoWPAN adaptation layer context"=C2=A0(co-ordinated with 6lo WG).
=


C= omments are welcome.

Thank you,

Peter and Ines

////////////////////////////= ///////////////////////////////////////////////////////////////////////////= ////////////////////////////////////////////////////////

CHARTER PROPOSAL:


Charter for Working Group


Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up o= f many embedded devices with limited power, memory, and processing resource= s. They are interconnected by a variety of links, such as IEEE 802.15.4, Bl= uetooth, Low Power WiFi, wired or other low power PLC (Powerline Communicat= ion) links. LLNs are transitioning to an end-to-end IP-based solution to av= oid the problem of non-interoperable networks interconnected by protocol tr= anslation gateways and proxies.


Generally speaking, LLNs are characterized as follows, but no= t limited to:


LLNs= operate with a hard, very small bound on state.


In most cases, LLN optimize for saving energy by using small p= acket headers and reduce amount of control packets.


Typical traffic patterns are not simply u= nicast flows (e.g. in some cases most if not all traffic can be point to mu= ltipoint).


In most= cases, LLNs will be employed over link layers with restricted frame-sizes = and low bit rates, thus a routing protocol for LLNs should be specifically = adapted for such link layers.


LLN routing protocols have to be very careful when trading off= efficiency for generality; since LLN nodes do not have resources to waste.=


These specific pr= operties cause LLNs to have specific routing requirements.


Existing routing protocols suc= h as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group (= draft-levis-roll-overview-protocols-00) and have in their current form been= found to not satisfy all of these specific routing requirements =E2=80=9CR= outing Requirements for Urban Low-Power and Lossy Networks=E2=80=9D RFC 554= 8, =E2=80=9CIndustrial Routing Requirements in Low-Power and Lossy Networks= =E2=80=9D RFC 5673, =E2=80=9CHome Automation Routing Requirements in Low-Po= wer and Lossy Networks=E2=80=9D RFC 5826, Building Automation Routing Requi= rements in Low-Power and Lossy Networks RFC 5867.


The Working Group is focused on routing iss= ues for LLN and maintaining the protocols developed by the working group.



There is a wide= scope of application areas for LLNs, including industrial monitoring, buil= ding automation (HVAC, lighting, access control, fire), connected homes, he= alth care, environmental monitoring, urban sensor networks (e.g. Smart Grid= ), asset tracking. The Working Group focuses on routing solutions for a sub= set of these: connected home, building and urban sensor networks for which = routing requirements have been specified. These application-specific routin= g requirement documents were used for protocol design.

The Working Group focuses on IPv6 routing = architectural framework for these application scenarios. The Framework will= take into consideration various aspects including high reliability in the = presence of time varying loss characteristics and connectivity while permit= ting low-power operation with very modest memory and CPU pressure in networ= ks potentially comprising a very large number (several thousands) of nodes.=



The Working Group will document = how data packets are routed and encapsulated when they cross the LLN, and w= hen they enter and exit the LLN: the appropriate use of RPI (RFC6553), RH3 = (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are de= tected. In consultation with the 6lo WG, the Working Group will design a me= thod to compress these routing headers into a single block. The WGLC on thi= s work will be shared with 6lo.


ROLL=C2=A0w= ill coordinate closely with the working groups in otherareas that focus on constrained node networks, = such as 6lo (Internet) and=C2=A0CoR= E (APP).The = Working group will align with the 6man WG when needed.


ROLL= is responsible for maintenance of the protocols that is has developed, inc= luding RPL and MPL.



Work Items are:

- Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.


- Compression of =C2= =A0RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context= . (co-ordinated with 6lo WG).


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12.6667px;font-family:Arial;vertical-align:baseline= ;white-space:pre-wrap">- Ad= ditional protocol elements to reduce packet size and the amount of required= routing states


- Automatic selection = of MPL forwarders to reduce message replication


- Data models for RPL and MPL management


- Alternative Multic= ast algorithm based on Bier forwarding.


- Methods to improve or correct =C2=A0the current RPL behaviour and the= other protocols defined by the working group.



Milestones


DATE =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Milestone

September 2017 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or cl= ose

March 2017 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about YANG = RPL model to IESG

January 2017 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MP= L selection to IESG

November 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about Bier = Multicast to IESG

October 2016 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model to= IESG

August 2016 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial Submission of the draft about when= to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-us= eofrplinfo to the IESG.

May 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial s= ubmission of the draft about how to compress RFC6553, RFC6554, and IP heade= rs in the 6LoWPAN adaptation layer context. =C2=A0to the IESG. draft-ietf-r= oll-routing-dispatch

November 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial Submission of the No-Path DAO P= roblem Statement to the IESG

--001a113f2ba0517ff50537d560ce-- From nobody Sun Jul 17 08:30:14 2016 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 248BF12B03A; Sun, 17 Jul 2016 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 38jz0zARf_fU; Sun, 17 Jul 2016 08:29:44 -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 993F712B010; Sun, 17 Jul 2016 08:22:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,379,1464645600"; d="scan'208,217";a="226929634" Received: from mail-lf0-f48.google.com ([209.85.215.48]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 17 Jul 2016 17:22:42 +0200 Received: by mail-lf0-f48.google.com with SMTP id g62so6642641lfe.3; Sun, 17 Jul 2016 08:22:42 -0700 (PDT) X-Gm-Message-State: ALyK8tJCAybCiUqhxkJBDTQPZ60FqKtV+g2hqRKQvEmE6Q5YIK3wxX/2n7776ezdqgMalLvn6PUo3qE73to5EA== X-Received: by 10.25.37.208 with SMTP id l199mr552324lfl.41.1468768961444; Sun, 17 Jul 2016 08:22:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Sun, 17 Jul 2016 08:22:21 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Sun, 17 Jul 2016 17:22:21 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lwig@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a11410ed43443780537d66cea Archived-At: Subject: Re: [Roll] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 15:29:46 -0000 --001a11410ed43443780537d66cea Content-Type: text/plain; charset=UTF-8 All, Please note that the info session is in the EVENING, i.e. 20.30. Some people got confused. Also, the Meetecho team is arranging for remote participation [1] to be possible, thanks to them! Thomas [1] http://ietf96.conf.meetecho.com/index.php/Remote_Participation On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne wrote: > All, > > We are organizing an information meeting about F-Interop, an online > platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in > Charlottenburg I. > > F-Interop (www.f-interop.eu) is a platform for online and remote > conformance and interoperability testing, targeted at IoT-related standards > (6TiSCH, 6LoWPAN, CoAP, RPL, ...) > > The purpose of this info session is to give you a technical overview of > the platform, describe how the IETF community can use and contribute to it, > and get feedback. > > The platform is built as part of the 2016-2018 F-Interop H2020 European > project. As part of that project, we will have an open call for entities to > contribute additional tools and test descriptions to the platform. Selected > projects will be funded; we will explain the process during the info > session as well. > > Looking forward to seeing you there, > > Thomas > -- _______________________________________ 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 _______________________________________ --001a11410ed43443780537d66cea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Please note that the info session = is in the EVENING, i.e. 20.30. Some people got confused.

Also, the Meetecho team is arranging for remote participation [1] to= be possible, thanks to them!

Thomas

On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne &= lt;thomas.wat= teyne@inria.fr> wrote:
All,

We are organizing an inform= ation meeting about F-Interop, an online platform for remote interoperabili= ty testing, IETF96 Monday 8.30-9.30pm, in Charlottenburg I.

<= /div>
F-Interop (= www.f-interop.eu) is a platform for online and remote conformance and i= nteroperability testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN= , CoAP, RPL, ...)

The purpose of this info session= is to give you a technical overview of the platform, describe how the IETF= community can use and contribute to it, and get feedback.

The platform is built as part of the 2016-2018 F-Interop H2020 Eur= opean project. As part of that project, we will have an open call for entit= ies to contribute additional tools and test descriptions to the platform. S= elected projects will be funded; we will explain the process during the inf= o session as well.

Looking forward to seeing you t= here,

Thomas



--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a11410ed43443780537d66cea-- From nobody Mon Jul 18 06:46:13 2016 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 48C9812DE76; Mon, 18 Jul 2016 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YCHF_ERJ4E7p; Mon, 18 Jul 2016 06:45:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9F12DABD; Mon, 18 Jul 2016 06:24:12 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d5-578ccda91d4e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.F2.03614.AADCC875; Mon, 18 Jul 2016 14:38:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 08:39:11 -0400 From: Suresh Krishnan To: Internet Area , "iot-dir@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, "core@ietf.org" , "its@ietf.org" , "lpwan@ietf.org" , "roll@ietf.org" Thread-Topic: AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AdHg8WGWoPnMMjhNT2ePkXbsiQk/9Q== Date: Mon, 18 Jul 2016 12:39:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPoO6qsz3hBmveClk0TxGwWHa3j9li 39v1zBY3Zt1ksZj/fB2zxcX571gsZpw7wmrRdFnAgcNjyZKfTAGMUVw2Kak5mWWpRfp2CVwZ ez+9ZS5oY604tHAZYwNjB0sXIyeHhICJxJ99J5ggbDGJC/fWs3UxcnEICRxllNjU0MwO4Sxn lDj57BVYFRtQx4adn5lAEiICLUwS+5qOMYIkhAUMJT6ducoGYosImEmsaH8OZetJzPnZCNbM IqAqMen0LlYQm1fAV6L/2AKwMxiBVn8/tQashllAXOLWk/lQJwlILNlznhnCFpV4+fgfK4St JPHx93x2iHodiQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYuQo LS7IyU03MtzECIyHYxJsjjsY9/Z6HmIU4GBU4uFdcLw7XIg1say4MvcQowQHs5II7+fTPeFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGMOOaK/vfJLd f8RErPVOMd/+ee+mJ/wr4dVpT1sc6flq3ebHzeEL76cwNVrmTBFhjDaKu5x7rehuZcni19ZH uvfPWPrq3DUfgYM93MWlrjpyK97UaUw3Nl5b3PHCYvbHvuSfi385iB3mFvV3/r3SL6/LNfd/ bKOxcMMssdSKvh6z1NW/JC/vUWIpzkg01GIuKk4EALDwpz2DAgAA Archived-At: Subject: [Roll] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:45:52 -0000 Hi all,=0A= I am considering AD sponsoring the following draft=0A= =0A= https://tools.ietf.org/html/draft-kivinen-802-15-ie-02=0A= =0A= to request the allocation of an 802.15.4 information element from the IEEE = =0A= for use in the IETF protocols that may need it. If you have any concerns = =0A= either with the content of the draft or about requesting the IE at all plea= se =0A= let me know before 2016/07/29.=0A= =0A= Thanks=0A= Suresh=0A= =0A= NOTE: I have CCed: all the groups that I thought could be potentially =0A= interested in this work. If you think I have missed out some WG(s) please l= et =0A= me know.=0A= From nobody Mon Jul 18 07:29:17 2016 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 D67BC12DFC8 for ; Mon, 18 Jul 2016 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 tKpa58KAgSLG for ; Mon, 18 Jul 2016 07:29:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E7712DF49 for ; Mon, 18 Jul 2016 06:54:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90286200A7 for ; Mon, 18 Jul 2016 10:04:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1DE41638D1 for ; Mon, 18 Jul 2016 09:54:52 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 18 Jul 2016 09:54:52 -0400 Message-ID: <20718.1468850092@obiwan.sandelman.ca> Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 14:29:13 -0000 In trying to update useofrplinfo and to answer Cenk, I find myself trying to explain inserting per-hop IPIP headers. I am dissatisfied with this text, and I see a clearer explanation:
The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header that originates from a node to an adjacent node, using the addresses (usually the GUA or ULA, but could use the link-local addresses) of each node. If the packet must traverse multiple hops, then it must be decapsulated at each hop, and then re-encapsulated again in a similar fashion. Can anyone write this clearer? -- ] 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 [ From nobody Mon Jul 18 07:57:03 2016 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 E68A612DD3D for ; Mon, 18 Jul 2016 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 HO3i38s9XKlZ for ; Mon, 18 Jul 2016 07:57:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861F912DF98 for ; Mon, 18 Jul 2016 07:28:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E686E200A7 for ; Mon, 18 Jul 2016 10:38:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5E046638D1 for ; Mon, 18 Jul 2016 10:28:36 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 14:57:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cenk G=C3=BCndogan wrote: > Hey *, > --- > 5.3) The question in this scenario is how the root knows how to addre= ss > the IPv6-in-IPv6 header. It can not know that the destination isn't > RPL aware, so it must insert an IPv6 header that can be removed on the > last RPL aware node. Since the root can not know in a storing network > where the last RPL aware node is, the IPv6-in-IPv6 header must be add= ed > hop-by-hop along the path from root to leaf. > --- > in section 5.3 it is said that the sender does not know whether the > destinationaddress is rpl-aware or not. This might be true for P2P > traffic, but for root->leaf traffic, I would expect that the root kno= ws > that. I don't want to be confused by the term P2P: let's use the term leaf to leaf traffic unless you are speaking about a path that is arrived at via P2PRPL. (RFC 6997). > There is the Transit Option for DAOs with the 'E' flag to indicate th= at > the target address was not learned from rpl. I would expect that this > 'E' flag is set for all Transit Options in DAOs until it reaches the > root node (recursively). So the root node should actually be aware > which address was learned from RPL and which not. Assuming that the 'E' bit was set, and that it propogated up to the root (I can't find any text in RFC6550 that mandates that, maybe I missed it), the root still would not know the address of the adjacent 6LR, if there is more than two layers of mesh. And, as you point out, it won't work for leaf to leaf traffic, so we still have to support the situation of hop-by-hop IPv6-in-IPv6. (unless rfc2461bi= s) It does permit us to distinguish between situation 5.2 (root to rpl-aware leaf) and 5.3 (root to not-rpl-aware-leaf), which is certainly an improvement! The root then learn about the "E" status for all leaf nodes, a= nd if there are no not-RPL-aware leafs, could announce that in it's DIO. That would permit leafs to know that case 5.10 (leaf to not-RPL-aware leaf) never occurs, and therefore could avoid IPv6-in-IPv6 headers in that case. (can you contribute any text for the document from this?) This a definite improvement as well: and the result is that we may need a document to describe an option to put into the DIO to announce this situation. (If there *are* not-RPL-aware leafs, then another option instead of IPv6-in-IPv6 hop-by-hop for all traffic, would be for leafs to IPv6-in-IPv6 traffic to the root rather than go across the DODAG. Serious performance and congestion issues if we do that, but maybe less code and le= ss Ines and Michael. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4znkICLcPvd0N1lAQIYxQf/W7/K8Sa3wLyuVn51AUNka/jdkT4Dcsbh V9tCUcErZMA3RCVsrGe3fLpnXYyLbvGAEj1O5zOHorFH5EPCBns4t2TBH7sZTQrr MzbarO63veFOADxNyP3H3hEKfqLMdf4rpX7HRO9MyYHLd5xrcL38QTKKls0L0BYT SCgWhYH7B774Qofa6IKDmgqguJTBEa9Bdi+ZQghYPhwK7PpuLXA6dtg11LvoicyW X8Aw/CJ8GJ65yo7oKHfgHIsTrO2GifAVT81JURTfz3rwrUrSboq/K08v/LO9TggT V5ZIVwESfbbfX/Cxczr9eKtN0G8/1LxUkDF2ZpHerEUl+s3xuOYTOg== =ty9k -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 07:58:40 2016 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 B047B12DA98 for ; Mon, 18 Jul 2016 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 awV_sq4Fzq7N for ; Mon, 18 Jul 2016 07:58:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1C112DFE2 for ; Mon, 18 Jul 2016 07:30:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F9C5200A7; Mon, 18 Jul 2016 10:39:51 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 86C1B638D1; Mon, 18 Jul 2016 10:30:26 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <4fad9a644c561d0a2f632edad1d4beb3@xs4all.nl> References: <4fad9a644c561d0a2f632edad1d4beb3@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 14:58:39 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> There is the Transit Option for DAOs with the 'E' flag to indicate >> that the target address was not learned from rpl. I would expect that >> this 'E' flag is set for all Transit Options in DAOs until it reaches >> the root node (recursively). So the root node should actually be >> aware which address was learned from RPL and which not. > It is probably worthwhile to describe (remind) in the draft this > procedure for the root to learn RPL associated addresses. Are you are referring to section 6.7.8 of RFC6550, or section 9.4? The root does not learn adjacency in storing mode, only in non-storing mode. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4zn/4CLcPvd0N1lAQItjAf/ZVEXvKX72BWRVHPtXxF+PKe0iBfGXmmJ ZyejFcRKrs3rDpV5Z3sGBF+BwQR/IwKibTtV8Lv1fEb555HnAXgZ2eYL1fGzKn/E cLG5NoRbANtnNQ6WsdyivX5iKM4bg7Fv9dIWnruslidXyjAWW+6P9pzt3AiWqhiT kyPKdOfdlOQWhmWv9GSah6tvwVhlk/ZuQc90jKP2onOSjhTpfNNuD7ysQDZfc0I/ 1496MndPJMVx3oj9dfvJNyZhySK0/OMyjZaleYew9i9EwGGBn5TC2CrrUrv+S9E3 U2Va2QR1PAONZ4nwRrqkHafqyiahriJUxMnm+Cm/H2BumPbS822PGQ== =/hFe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 08:00:05 2016 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 292B512DA99 for ; Mon, 18 Jul 2016 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 nSJ0a5UNRPBK for ; Mon, 18 Jul 2016 08:00:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D597A12DB07 for ; Mon, 18 Jul 2016 07:32:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A06DA200A7 for ; Mon, 18 Jul 2016 10:41:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0F02D638D1 for ; Mon, 18 Jul 2016 10:32:20 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <8bd985a5-ded0-b5f3-8750-e0fb24c852ef@gmail.com> References: <8bd985a5-ded0-b5f3-8750-e0fb24c852ef@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 15:00:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cenk G=C3=BCndogan wrote: >> Other question: how does the last 6LR know that the next node is a >> not_Raf? > I would try to answer this question in the following way: > I expect routes that were found _not_ with RPL, but e.g. configured > manually or through any other mechanism to be marked somehow > differently than routes that were accumulated with DAOs. How to mark > routes "differently" seems to be implementation specific. (but this > information would be used to fill in the `E` flag of Transit Options = in > DAOs later). yes, one would expect the neighbour cache to have a direct (connected) route to a non-RPL aware node that was discovered through neighbour discovery. (NS/NA). > So, if a rpl router forwards a packet downwards (storing-mode), it > somehow needs to know whether the (dst;next-hop) pair in a forwarding > table is rpl-born or not. If it is not rpl-born, then the IPIP header > containing the RPI must be removed before continuing the forwarding > process, otherwise the IPIP+RPI is re-added and targeted to the > next-hop. > You probably noticed that I used many "somehows" and generalized a lot > in the text above, but this process looks very blurry to me. Any RPL > veterans available to make things clearer? Actually, that's the point of this document: it's blurry for many! =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4zocYCLcPvd0N1lAQJMaQgAll0OHJoJe3EeYzyc79TgztmPZfTyjJpE waxwzZq3DaBox/GEvF4KJSZEzv4GQGRsquHo1LA9HOXZUJUSPVARbgI0oFVOjc72 FCodyw2fH1UltDVTHI2zTF2Ig+A6/v1KKSE8INt0MT2uUeK2ZQr9mEydfFcBjAOH udd1DR7LMGF8ZbIxJ5B6l+LDuO0XChRc7u4+POS/xeTWyST03OXFvZxqObmDPf4i lD9YfaoNKrY4QNiLue4lQXnyKbRXmOHchz25gtlUke7KXun9B4pKjGHUQcrIrwfj vomQTU609JX8MAqLeoiBu0qVtuANnoPjWgqPGIuLqQ3ZGFce71axpQ== =Sqg/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 08:02:26 2016 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 CF08412B046 for ; Mon, 18 Jul 2016 08:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 nsndLUnOEkc1 for ; Mon, 18 Jul 2016 08:02:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F8A12D8AD for ; Mon, 18 Jul 2016 07:34:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EFBE200A7; Mon, 18 Jul 2016 10:44:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 910CB638D1; Mon, 18 Jul 2016 10:34:49 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Kovatsch Matthias Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 15:02:25 -0000 --=-=-= Content-Type: text/plain Ines Robles wrote: > P: Section 5.3 and section 5.2: If the 6LBR does not know whether > destination is Raf or not_Raf in section 5.3, then this is also the > case in section 5.2. Question why is the IPv6-in-IPv6 header not also > used in section 5.2. The problem for the 6LBR is the same. Because the root doesn't know (unless we mandate that the E flag is propogated all the way upwards), then the root has to always use hop-by-hop IPIP for both 5.2 and 5.3, because the root can't tell which situation is in play. We (as omniscient god looking down) can distinguish the cases, but the root can not. Michael and Ines. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4zpBoCLcPvd0N1lAQINfwf/aR4AIVxg+OHfYOHaYm6PLle1i20MGlte vLCeOwPy/SMBWMb16+B42kYY73HWaaTz83l6JMtbBcTggKzdVn4Neng0F2ZE2qE7 oxXaL/fsMwBnjWeKSNPJYcZgTfYb9Z3B+lkqrWOTfmEeYU76Sx/8ntj4bNI21Yp1 w0eMP8zPmQjusOtBuaSYot0Tolq2c3Sh8ixBASteGQ4Ip9iBtV6I2IqvMNUVOqtS PbgRlc5nqQBvtGHqAUuYT0Rrdvb6DHdKy5QAtA1uvMCk8fdScvsZO/GxZAImQvz6 1uNo8p4W17FcMokhTuyKqUdiDF6pu8D5/l12QuUSL8USmGRl2ZhETA== =oHwc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 09:09:22 2016 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 A10B312DA5A for ; Mon, 18 Jul 2016 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 RbcEYPYDtr7S for ; Mon, 18 Jul 2016 09:09:17 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7963012B03F for ; Mon, 18 Jul 2016 09:09:17 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.209]) by smtp-cloud6.xs4all.net with ESMTP id LG9E1t00G4WfiVN01G9EEF; Mon, 18 Jul 2016 18:09:14 +0200 Received: from 2001:67c:370:160:581a:2bfc:4a20:2be9 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 18 Jul 2016 18:09:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2016 18:09:14 +0200 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <30186.1468852489@obiwan.sandelman.ca> References: <30186.1468852489@obiwan.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl (pNDv+xmYgITHhD6y7+9TCcYJwIeI7WGD) User-Agent: XS4ALL Webmail Archived-At: Cc: Kovatsch Matthias , Routing Over Low power and Lossy networks Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:09:19 -0000 (unless we mandate that the E flag is > propogated all the way upwards), then the root has to always use > hop-by-hop > IPIP for both 5.2 and 5.3, because the root can't tell which situation > is in > play. I thought that this was a good occasion to point that out in the rplinfo document. Peter From nobody Mon Jul 18 10:47:14 2016 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 00B5712B043 for ; Mon, 18 Jul 2016 10:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 ADKtQSEJwsbN for ; Mon, 18 Jul 2016 10:47:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 4C84D12D0DD for ; Mon, 18 Jul 2016 10:47:09 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id s189so40355163vkh.1 for ; Mon, 18 Jul 2016 10:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=mkB/Sh4PRBwbyQsamc6XInqpHg9qglLcsZPPXpzvvc0=; b=bN7B84GkoVZguBFxYRJgAjR+n2p0LtL322UW1SUAqluugYfP00+DBIVgNbSL2IhrW6 6sMhJjTl7PuwocMe/CyikGmOUj/gTgeSZYbLqYVD25VZT3WJ84stuZb8Lx5EVxgvDbE6 mxesazIT/nw1PBH3OwjSGb+RsKNOu9ErLovGmme/1RObT0LzgxcJjT401SigTWiaiHdb OgDcvhOl3yaDa/QrLDn2kJARQpXlACUoCHzsDm6OfuYw/1BL0h6OySPmmbgbotPhspvE ohudKMUfg+wrALKaRk0Gl6CnuKrlttmzFNeTTI6KyvLQJumN8ePrqROKLSjCs/lIlrOQ xV/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mkB/Sh4PRBwbyQsamc6XInqpHg9qglLcsZPPXpzvvc0=; b=RBkf7nfS21hhvLrpTc52lGWFa2ejqkSFxeo1XN4l4/nhLFDqgqqGU2rlUn75kmiOnq epIQJM+d5gQE0r+q9dhqFwebVCWzgwLCHk4DGPZ9Y+6NPVWHsf41OMjjWnmbVE5mV4JY m2mlDbvo+SqYmvzl2VvU77+fI+wjU6l9cuwci9MMLvuaUY9pGrdVFfwgSEn8YGmzrD4g bZ5AVBAmRGn6sUMABH2tcBFSisCUV52SRIZE/K3Q6htrVeVAtduDJusZDGNKn4bGVSdf ACz6VH+bcWEFIYN1eehkyNBPxxgvkjFsIMPPbiHQuXc0yI3WqqLekxGGCnRJB73Q1jdw mCYg== X-Gm-Message-State: ALyK8tJfaMPkUUwJUO14uyfR8CHLb2IW+lCxVP3iy1aO90zHDUhsUv2rLVSGylGndgvNmBmPTdYAaJ6bC2jxpA== X-Received: by 10.176.4.162 with SMTP id 31mr18816846uaw.81.1468864028301; Mon, 18 Jul 2016 10:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Mon, 18 Jul 2016 10:47:07 -0700 (PDT) From: Ines Robles Date: Mon, 18 Jul 2016 20:47:07 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=94eb2c125290a160e10537ec8e48 Archived-At: Subject: [Roll] Request for Comments ROLL Charter - version 06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:47:12 -0000 --94eb2c125290a160e10537ec8e48 Content-Type: text/plain; charset=UTF-8 Dear all, Please find the new charter. We have reduced the history part, removed redundant text and updated work items. Please comments Thank you very much, Peter and Ines //////////////////////////////////////////////////////////////////////////////////////////////////////// CHARTER PROPOSAL: Charter for ROLL Working Group Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs are characterized as follows, but not limited to: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste. - These specific properties cause LLNs to have specific routing requirements. RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from several application perspectives. The Working Group has focused on routing solutions for the areas: connected home, building and urban sensor networks. It has developed a protocol set that takes into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group continues to focus on routing issues for LLN and to maintain, improve and streamline the protocols developed by the working group, including RPL and MPL. ROLL will coordinate closely with the working groups in other areas that focus on constrained node networks, such as 6lo (Internet) and CoRE (APP). behavior and the other protocols defined by the working groupThe Working group will align with the 6man and BIER WGs when needed. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. The WGLC on this work will be shared with 6lo. - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. (coordinated with 6lo WG). - Automatic selection of MPL forwarders to reduce message replication - Data models for RPL and MPL management (coordinated with netmod wg) - Alternative Multicast algorithm such as BIER forwarding. two - Methods to improve or correct the current RPL control messages behaviour, e.g. DIS and No-Path DAO. Milestones DATE Milestone September 2017 Recharter WG or close March 2017 Initial submission of draft about YANG RPL model to IESG January 2017 Initial submission of draft about MPL selection to IESG November 2016 Initial submission of draft about Bier Multicast to IESG October 2016 Submit draft about YANG MPL model to IESG August 2016 Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG. May 2016 Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. to the IESG. draft-ietf-roll-routing-dispatch November 2016 Initial Submission of the No-Path DAO Problem Statement to the IESG --94eb2c125290a160e10537ec8e48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the new charter. = We have reduced the history part, removed redundant text and updated work i= tems.

Please comments

Tha= nk you very much,

Peter and Ines

///////////////////////////////////////////////////////////////////= /////////////////////////////////////

CHARTER = PROPOSAL:


Charter for ROLL Working Group


Low power and Lo= ssy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devic= es with limited power, memory, and processing resources. They are interconn= ected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power Wi= Fi, wired or other low power PLC (Powerline Communication) links. LLNs are = transitioning to an end-to-end IP-based solution to avoid the problem of no= n-interoperable networks interconnected by protocol translation gateways an= d proxies.


Generally speaking, LLNs are characterized as follows,= but not limited to:


  • LLNs operate wi= th a hard, very small bound on state.

  • In most cases, LLN optimize for saving energy by using small = packet headers and reduce amount of control packets.

  • Typical traffic patterns are= not simply unicast flows (e.g. in some cases most if not all traffic can b= e point to multipoint).

  • In most cases, LLNs will be employed over link layers with= restricted frame-sizes and low bit rates, thus a routing protocol for LLNs= should be specifically adapted for such link layers.

  • LLN routing protocols have = to be very careful when trading off efficiency for generality; since LLN no= des do not have resources to waste.

  • These specific properties cause LLNs to have s= pecific routing requirements.


RFC 5548, 5673, 5826, an= d 5876 describe the requirements for LLNs from several application perspect= ives.

The Working Group has focused on routing solutions for the area= s: connected home, building and urban sensor networks. It has developed a = =C2=A0protocol set that takes into consideration various aspects including = high reliability in the presence of time varying loss characteristics and c= onnectivity while permitting low-power operation with very modest memory an= d CPU pressure in networks potentially comprising a very large number (seve= ral thousands) of nodes.


The Working Group continues to focus on = routing issues for LLN and to maintain, improve and streamline the protocol= s developed by the working group, including RPL and MPL.


ROLL= =C2=A0will coordinate closely with the working groups in other=C2=A0areas t= hat focus on constrained node networks, such as 6lo (Internet) and=C2=A0CoR= E (APP). behavior and the other protocols defined by the working groupThe= Working group will align with the 6man and BIER WGs when needed.

Work Items are:

- Guidance in using RFC6553, RFC6554, and IPv6-in-IP= v6 encapsulation. The WGLC on this work will be shared with 6lo. <= /p>

- Compression of =C2=A0RFC6553, RFC6554, and IP headers in the 6LoWPAN a= daptation layer context. (coordinated with 6lo WG).


- Automatic se= lection of MPL forwarders to reduce message replication


- Data mo= dels for RPL and MPL management (coordinated with netmod wg)


=

<= span style=3D"font-size:12.6667px;font-family:Arial;color:rgb(80,0,80);vert= ical-align:baseline;white-space:pre-wrap;background-color:transparent">- Al= ternative Multicast algorithm such as BIER forwarding.

two

- Methods= to improve or correct=C2=A0the current RPL control messages behaviour, e.g= . DIS and No-Path DAO.


Milestones


DATE =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Milest= one

September 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about YA= NG RPL model to IESG

January 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Initial submission of draft about MPL selection to IESG<= /p>

Nov= ember 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of = draft about Bier Multicast to IESG

October 2016 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model to IESG=

Au= gust 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial Sub= mission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 e= ncapsulation Draft-ietf-roll-useofrplinfo to the IESG.

May 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial s= ubmission of the draft about how to compress RFC6553, RFC6554, and IP heade= rs in the 6LoWPAN adaptation layer context. =C2=A0to the IESG. draft-ietf-r= oll-routing-dispatch

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Initial Submission of the No-Path DAO Problem Statement to the IES= G
--94eb2c125290a160e10537ec8e48-- From nobody Mon Jul 18 10:52:57 2016 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 8202B12D8B5 for ; Mon, 18 Jul 2016 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.176 X-Spam-Level: X-Spam-Status: No, score=-8.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7t6vS-mzuGF for ; Mon, 18 Jul 2016 10:52:53 -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 6E79512DB2D for ; Mon, 18 Jul 2016 10:52:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,385,1464645600"; d="scan'208,217";a="185147615" Received: from mail-lf0-f52.google.com ([209.85.215.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 18 Jul 2016 19:52:50 +0200 Received: by mail-lf0-f52.google.com with SMTP id l69so80341083lfg.1 for ; Mon, 18 Jul 2016 10:52:50 -0700 (PDT) X-Gm-Message-State: ALyK8tIsGkZUmJuZZXeYnV8a5Ci/eGoSA/5AuUEzg4cPrHAhw93Eg3TPdIYDrcK5w73+VCo5XMlzQqGUg7rBXQ== X-Received: by 10.25.155.149 with SMTP id d143mr9682938lfe.121.1468864370093; Mon, 18 Jul 2016 10:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Mon, 18 Jul 2016 10:52:30 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Mon, 18 Jul 2016 19:52:30 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11401fba00b5fc0537eca330 Archived-At: Subject: Re: [Roll] Request for Comments ROLL Charter - version 06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:52:56 -0000 --001a11401fba00b5fc0537eca330 Content-Type: text/plain; charset=UTF-8 Ines, Peter, Looks good to me. Two typos: "groupThe " and an etra "two" in the items. T On Mon, Jul 18, 2016 at 7:47 PM, Ines Robles wrote: > Dear all, > > Please find the new charter. We have reduced the history part, removed > redundant text and updated work items. > > Please comments > > Thank you very much, > > Peter and Ines > > > //////////////////////////////////////////////////////////////////////////////////////////////////////// > > CHARTER PROPOSAL: > > Charter for ROLL Working Group > > Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of > many embedded devices with limited power, memory, and processing resources. > They are interconnected by a variety of links, such as IEEE 802.15.4, > Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline > Communication) links. LLNs are transitioning to an end-to-end IP-based > solution to avoid the problem of non-interoperable networks interconnected > by protocol translation gateways and proxies. > > Generally speaking, LLNs are characterized as follows, but not limited to: > > > - > > LLNs operate with a hard, very small bound on state. > - > > In most cases, LLN optimize for saving energy by using small packet > headers and reduce amount of control packets. > - > > Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if not all traffic can be point to multipoint). > - > > In most cases, LLNs will be employed over link layers with restricted > frame-sizes and low bit rates, thus a routing protocol for LLNs should be > specifically adapted for such link layers. > - > > LLN routing protocols have to be very careful when trading off > efficiency for generality; since LLN nodes do not have resources to waste. > - > > These specific properties cause LLNs to have specific routing > requirements. > > > RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from > several application perspectives. > > The Working Group has focused on routing solutions for the areas: > connected home, building and urban sensor networks. It has developed a > protocol set that takes into consideration various aspects including high > reliability in the presence of time varying loss characteristics and > connectivity while permitting low-power operation with very modest memory > and CPU pressure in networks potentially comprising a very large number > (several thousands) of nodes. > > The Working Group continues to focus on routing issues for LLN and to > maintain, improve and streamline the protocols developed by the working > group, including RPL and MPL. > > ROLL will coordinate closely with the working groups in other areas that > focus on constrained node networks, such as 6lo (Internet) and CoRE (APP). > behavior and the other protocols defined by the working groupThe Working > group will align with the 6man and BIER WGs when needed. > > Work Items are: > > - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. The > WGLC on this work will be shared with 6lo. > > - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN > adaptation layer context. (coordinated with 6lo WG). > > - Automatic selection of MPL forwarders to reduce message replication > > - Data models for RPL and MPL management (coordinated with netmod wg) > > - Alternative Multicast algorithm such as BIER forwarding. > two > > - Methods to improve or correct the current RPL control messages > behaviour, e.g. DIS and No-Path DAO. > > Milestones > > DATE Milestone > > September 2017 Recharter WG or close > > March 2017 Initial submission of draft about YANG RPL model to > IESG > > January 2017 Initial submission of draft about MPL selection to > IESG > > November 2016 Initial submission of draft about Bier Multicast to > IESG > > October 2016 Submit draft about YANG MPL model to IESG > > August 2016 Initial Submission of the draft about when to use > RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation > Draft-ietf-roll-useofrplinfo to the IESG. > > May 2016 Initial submission of the draft about how to compress > RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. > to the IESG. draft-ietf-roll-routing-dispatch > November 2016 Initial Submission of the No-Path DAO Problem > Statement to the IESG > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > -- _______________________________________ 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 _______________________________________ --001a11401fba00b5fc0537eca330 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ines, Peter,

Looks good to me. Two typo= s: "groupThe " and an etra "two" in the items.=
T

On Mon, Jul 18, 2016 at 7:47 PM, Ines Robles <= mariain= esrobles@googlemail.com> wrote:
Dear all,

Please find the new char= ter. We have reduced the history part, removed redundant text and updated w= ork items.

Please comments

Thank you very much,

Peter and Ines
//////////////////////////////////////////////////////////////= //////////////////////////////////////////

<= p dir=3D"ltr" style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">CHARTER PROPOSAL:


Charter for ROLL Working Group<= /p>

Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of ma= ny embedded devices with limited power, memory, and processing resources. T= hey are interconnected by a variety of links, such as IEEE 802.15.4, Blueto= oth, Low Power WiFi, wired or other low power PLC (Powerline Communication)= links. LLNs are transitioning to an end-to-end IP-based solution to avoid = the problem of non-interoperable networks interconnected by protocol transl= ation gateways and proxies.


Generally speaking, LLNs are characte= rized as follows, but not limited to:


  • In most cases, LLN optimize for saving energy= by using small packet headers and reduce amount of control packets.=

  • Typical traff= ic patterns are not simply unicast flows (e.g. in some cases most if not al= l traffic can be point to multipoint).

  • In most cases, LLNs will be employed over = link layers with restricted frame-sizes and low bit rates, thus a routing p= rotocol for LLNs should be specifically adapted for such link layers.

  • LLN routing= protocols have to be very careful when trading off efficiency for generali= ty; since LLN nodes do not have resources to waste.

  • These specific properties ca= use LLNs to have specific routing requirements.


RFC 554= 8, 5673, 5826, and 5876 describe the requirements for LLNs from several app= lication perspectives.

The Working Group has focused on routing solut= ions for the areas: connected home, building and urban sensor networks. It = has developed a =C2=A0protocol set that takes into consideration various as= pects including high reliability in the presence of time varying loss chara= cteristics and connectivity while permitting low-power operation with very = modest memory and CPU pressure in networks potentially comprising a very la= rge number (several thousands) of nodes.


The Working Group contin= ues to focus on routing issues for LLN and to maintain, improve and streaml= ine the protocols developed by the working group, including RPL and MPL.


ROLL=C2=A0will coordinate closely with the working groups in oth= er=C2=A0areas that focus on constrained node networks, such as 6lo (Interne= t) and=C2=A0CoRE (APP). behavior and the other protocols defined by the wor= king groupThe Working group will align with the 6man and BIER WGs when ne= eded.


Work Items are:

- Guidance in using RFC6553, RFC6554,= and IPv6-in-IPv6 encapsulation. The WGLC on this work will be shared wit= h 6lo.


- Compression of =C2=A0RFC6553, RFC6554, and IP headers i= n the 6LoWPAN adaptation layer context. (coordinated with 6lo WG).

- Automatic selection of MPL forwarders to reduce message replication


- Data models for RPL and MPL management (coordinated with netmod wg)=


- Alternative Multicast algorithm such as BIER forwarding.

two

- Methods to improve or correct=C2=A0the current RPL control messages= behaviour, e.g. DIS and No-Path DAO.


Milestones


DATE =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Milestone

September 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of= draft about YANG RPL model to IESG

January 2017 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MPL selection = to IESG

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial= submission of draft about Bier Multicast to IESG

October 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model= to IESG

August 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Initial Submission of the draft about when to use RFC6553, RFC6554, a= nd IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG.

May 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Initial submission of the draft about how to compress RFC6553, RFC= 6554, and IP headers in the 6LoWPAN adaptation layer context. =C2=A0to the = IESG. draft-ietf-roll-routing-dispatch

November 2016 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Initial Submission of the No-Path DAO Problem St= atement to the IESG

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




--
=
_______________________________________

=
Thomas W= atteyne, PhD
Research Scientist & Innovator, Inria
Sr Networkin= g Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN

______________________= _________________
--001a11401fba00b5fc0537eca330-- From nobody Mon Jul 18 11:24:03 2016 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 85F5212B036 for ; Mon, 18 Jul 2016 11:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 aGlzBQirPCFR for ; Mon, 18 Jul 2016 11:23:58 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 529EC12B016 for ; Mon, 18 Jul 2016 11:23:58 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id w127so192057358vkh.2 for ; Mon, 18 Jul 2016 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zAdcZFRPxwJMn1qLmfZCkbKYVzaJZZ+VsM60miLtw60=; b=toA9dFH6AJyktADLVP7LZre+gy5w7j9uZ1qigIxlM5pv6V6IiK4Auo3vR0RZAdw1Jh nNjCvcJEO+QKEvzIbJdfOYc2wN1YSGbq1M6pm8WH0aALhV2KsOsYuF5XXXJ1CIE/rFBR Ce92x4+fc4XN431klP/m1uC6NaksrU5zaQgySmeqk6yRtyHFRn0XNEkUowraQ1kGUb4p 4TKndygZU9jAvdU21LDUQpoxaloOKLJkJRKUVoq5tXzJuhOE3Kp4VfOCisERHx1eNByN oXR1/mk8TswgHmT4jsxKlNgVQGh2synkb4+zZwZ17BPlvEh0H69xHjnKdb9JHBvchZSQ DrKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zAdcZFRPxwJMn1qLmfZCkbKYVzaJZZ+VsM60miLtw60=; b=kR+5Si/yUX8WRdo5aC8yC4T+A/4KKeAYGrzwJ1WGFxkuFrLtOeLVYENVAnsjWuVMdH TIOYvbZHJ/HItmS/OuOIxs0/Po7U+IY6+tvIx2whKapZyeBGF1hi06n900SwVbNhACqg YLUZD0Eoj3hKj1FRxawQ/8mZmYQXaT2wrAojrSgH7pWN+n/NKq5GqiqmIGCkNLK0EXZ9 AQI8/I9Gpq39K6zSitiOJTeSDId1J8BnApK0gHSPDntmrY5yIx7TI5zq/VwerrcPq0Gi elzKcd5Bs0EmUF1zuLokY4klomrm1mn8CZSGh7qa9kojgEcfLK0iv4Vip544REJwrVrO B72g== X-Gm-Message-State: ALyK8tI0MSa+UKG4S6OLrBxk6V+PmpzUHmS6wV8LsxgrOrJLLtEV8UT4TuBJ77i17ujSr1bYbczUkwyopeMMwQ== X-Received: by 10.176.2.238 with SMTP id 101mr18699794uah.5.1468866237203; Mon, 18 Jul 2016 11:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Mon, 18 Jul 2016 11:23:56 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Mon, 18 Jul 2016 21:23:56 +0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a113cf1904a8aa10537ed12ee Archived-At: Subject: Re: [Roll] Request for Comments ROLL Charter - version 06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:24:01 -0000 --001a113cf1904a8aa10537ed12ee Content-Type: text/plain; charset=UTF-8 Ok, Thank you Thomas! :-) 2016-07-18 20:52 GMT+03:00 Thomas Watteyne : > Ines, Peter, > > Looks good to me. Two typos: "groupThe " and an etra "two" in the items. > T > > On Mon, Jul 18, 2016 at 7:47 PM, Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find the new charter. We have reduced the history part, removed >> redundant text and updated work items. >> >> Please comments >> >> Thank you very much, >> >> Peter and Ines >> >> >> //////////////////////////////////////////////////////////////////////////////////////////////////////// >> >> CHARTER PROPOSAL: >> >> Charter for ROLL Working Group >> >> Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of >> many embedded devices with limited power, memory, and processing resources. >> They are interconnected by a variety of links, such as IEEE 802.15.4, >> Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline >> Communication) links. LLNs are transitioning to an end-to-end IP-based >> solution to avoid the problem of non-interoperable networks interconnected >> by protocol translation gateways and proxies. >> >> Generally speaking, LLNs are characterized as follows, but not limited to: >> >> >> - >> >> LLNs operate with a hard, very small bound on state. >> - >> >> In most cases, LLN optimize for saving energy by using small packet >> headers and reduce amount of control packets. >> - >> >> Typical traffic patterns are not simply unicast flows (e.g. in some >> cases most if not all traffic can be point to multipoint). >> - >> >> In most cases, LLNs will be employed over link layers with restricted >> frame-sizes and low bit rates, thus a routing protocol for LLNs should be >> specifically adapted for such link layers. >> - >> >> LLN routing protocols have to be very careful when trading off >> efficiency for generality; since LLN nodes do not have resources to waste. >> - >> >> These specific properties cause LLNs to have specific routing >> requirements. >> >> >> RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from >> several application perspectives. >> >> The Working Group has focused on routing solutions for the areas: >> connected home, building and urban sensor networks. It has developed a >> protocol set that takes into consideration various aspects including high >> reliability in the presence of time varying loss characteristics and >> connectivity while permitting low-power operation with very modest memory >> and CPU pressure in networks potentially comprising a very large number >> (several thousands) of nodes. >> >> The Working Group continues to focus on routing issues for LLN and to >> maintain, improve and streamline the protocols developed by the working >> group, including RPL and MPL. >> >> ROLL will coordinate closely with the working groups in other areas that >> focus on constrained node networks, such as 6lo (Internet) and CoRE (APP). >> behavior and the other protocols defined by the working groupThe Working >> group will align with the 6man and BIER WGs when needed. >> >> Work Items are: >> >> - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. >> The WGLC on this work will be shared with 6lo. >> >> - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN >> adaptation layer context. (coordinated with 6lo WG). >> >> - Automatic selection of MPL forwarders to reduce message replication >> >> - Data models for RPL and MPL management (coordinated with netmod wg) >> >> - Alternative Multicast algorithm such as BIER forwarding. >> two >> >> - Methods to improve or correct the current RPL control messages >> behaviour, e.g. DIS and No-Path DAO. >> >> Milestones >> >> DATE Milestone >> >> September 2017 Recharter WG or close >> >> March 2017 Initial submission of draft about YANG RPL model to >> IESG >> >> January 2017 Initial submission of draft about MPL selection to >> IESG >> >> November 2016 Initial submission of draft about Bier Multicast to >> IESG >> >> October 2016 Submit draft about YANG MPL model to IESG >> >> August 2016 Initial Submission of the draft about when to use >> RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation >> Draft-ietf-roll-useofrplinfo to the IESG. >> >> May 2016 Initial submission of the draft about how to >> compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer >> context. to the IESG. draft-ietf-roll-routing-dispatch >> November 2016 Initial Submission of the No-Path DAO Problem >> Statement to the IESG >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > > -- > _______________________________________ > > 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 > _______________________________________ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a113cf1904a8aa10537ed12ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, Thank you Thomas! :-)
=
2016-07-18 20:52 GMT+03:00 Thomas Watteyne <= span dir=3D"ltr"><thomas.watteyne@inria.fr>:
Ines, Peter,

Looks good to me. = Two typos: "groupThe " and an etra "two" in th= e items.
T

On Mon, Jul 18, 2016 at 7:47 PM, In= es Robles <mariainesrobles@googlemail.com> wro= te:
Dear all,

Please find the new charter. We= have reduced the history part, removed redundant text and updated work ite= ms.

Please comments

Thank= you very much,

Peter and Ines

/////////////////////////////////////////////////////////////////////= ///////////////////////////////////

CHARTER PROPOSAL:


Charter for ROLL Working Group

Low = power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many em= bedded devices with limited power, memory, and processing resources. They a= re interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, = Low Power WiFi, wired or other low power PLC (Powerline Communication) link= s. LLNs are transitioning to an end-to-end IP-based solution to avoid the p= roblem of non-interoperable networks interconnected by protocol translation= gateways and proxies.


Generally speaking, LLNs are characterized= as follows, but not limited to:


  • LLN= s operate with a hard, very small bound on state.

  • In most cases, LLN optimize for saving energy b= y using small packet headers and reduce amount of control packets.

  • Typical traffic= patterns are not simply unicast flows (e.g. in some cases most if not all = traffic can be point to multipoint).

  • In most cases, LLNs will be employed over = link layers with restricted frame-sizes and low bit rates, thus a routing p= rotocol for LLNs should be specifically adapted for such link layers.

  • LLN routing= protocols have to be very careful when trading off efficiency for generali= ty; since LLN nodes do not have resources to waste.

  • These specific properties ca= use LLNs to have specific routing requirements.


RFC 554= 8, 5673, 5826, and 5876 describe the requirements for LLNs from several app= lication perspectives.

The Working Group has focused on routing solut= ions for the areas: connected home, building and urban sensor networks. It = has developed a =C2=A0protocol set that takes into consideration various as= pects including high reliability in the presence of time varying loss chara= cteristics and connectivity while permitting low-power operation with very = modest memory and CPU pressure in networks potentially comprising a very la= rge number (several thousands) of nodes.


The Working Group contin= ues to focus on routing issues for LLN and to maintain, improve and streaml= ine the protocols developed by the working group, including RPL and MPL.


ROLL=C2=A0will coordinate closely with the working groups in oth= er=C2=A0areas that focus on constrained node networks, such as 6lo (Interne= t) and=C2=A0CoRE (APP). behavior and the other protocols defined by the wor= king groupThe Working group will align with the 6man and BIER WGs when ne= eded.


Work Items are:

- Guidance in using RFC6553, RFC6554,= and IPv6-in-IPv6 encapsulation. The WGLC on this work will be shared wit= h 6lo.


- Compression of =C2=A0RFC6553, RFC6554, and IP headers i= n the 6LoWPAN adaptation layer context. (coordinated with 6lo WG).

- Automatic selection of MPL forwarders to reduce message replication


- Data models for RPL and MPL management (coordinated with netmod wg)=


- Alternative Multicast algorithm such as BIER forwarding.

two

- Methods to improve or correct=C2=A0the current RPL control messages= behaviour, e.g. DIS and No-Path DAO.


Milestones


DATE =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Milestone

September 2017 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Recharter WG or close

March 2017 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of= draft about YANG RPL model to IESG

January 2017 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Initial submission of draft about MPL selection = to IESG

November 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Initial= submission of draft about Bier Multicast to IESG

October 2016 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Submit draft about YANG MPL model= to IESG

August 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Initial Submission of the draft about when to use RFC6553, RFC6554, a= nd IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG.

May 2016 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Initial submission of the draft about how to compress RFC6553, RFC= 6554, and IP headers in the 6LoWPAN adaptation layer context. =C2=A0to the = IESG. draft-ietf-roll-routing-dispatch

November 2016 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Initial Submission of the No-Path DAO Problem St= atement to the IESG

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


<= br clear=3D"all">

--
<= font face=3D"monospace, monospace">_______________________________________<= /font>

Thomas Watteyne, PhD
Research Scientist & Innovator, I= nria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, U= C Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_= ______________________________________

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


--001a113cf1904a8aa10537ed12ee-- From nobody Mon Jul 18 11:40:06 2016 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 97BCB12B016; Mon, 18 Jul 2016 11:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718184003.18108.94009.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 11:40:03 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:40:03 -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-06.txt Pages : 32 Date : 2016-07-18 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-06 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 Mon Jul 18 12:03:18 2016 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 445A412B077; Mon, 18 Jul 2016 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 Yr3IcjwRsKkU; Mon, 18 Jul 2016 12:03:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3356512B01E; Mon, 18 Jul 2016 12:03:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 69223200A7; Mon, 18 Jul 2016 15:12:38 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 391C5638D1; Mon, 18 Jul 2016 15:03:13 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6man@ietf.org Subject: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:03:16 -0000 --=-=-= Content-Type: text/plain The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). There is work on 6lo to allocate additional 6lowpan IPHC codes such that the work in ROLL: https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can know what kinds of things we need to compress. A number of things are constrained by the need to always remove the RFC6553 Hop-by-Hop option RPI option which had been marked critical: i.e. drop packet if you don't understand it. As a result of the change in RFC2460bis, which says that intermediate hosts will in general not examine hop-by-hop options, but should just ignore them, we can make certain simplications to the useofrplinfo document. (rfc2460bis, section 4, page 8, "NOTE: While...) (It is unclear what end-hosts can/should do. I will assume they can also ignore hop-by-hop options if they haven't been told to pay attention to them). https://goo.gl/cxWkP5 this is a reference to an RFC diff between: draft-ietf-roll-useofrplinfo-06.txt and draft-richardson-roll-useofrplinfo-2460bis-00.txt (Note we have only re-analyzed storing mode , so please ignore changes in section 6) The summary is that in storing mode we never need to use per-hop IPv6-in-IPv6 encapsulation with the 2460bis text. Packets originating from not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be encapsulated so that the RPI option can be added, but no complex considerations need apply for where to remove the RPI, as it can be left in place until the end-host. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV40n7YCLcPvd0N1lAQIRCQgAlC7K8hRhC6Ttbtz8ZMaj4AZo+P2Tcx32 gHWoJvIkA4aJ9Tfyw9aO/DjH39exoGBZfCKrQp6VuKH2wnp+4B3CJWSbY0sAYsVI z+EEt7wmtDG+NF1kX6AhR/Pi9VE3hlYrCRdqgoFpksbk10P1/hVuXCodl4j1bKv0 v58QvnOLmHStHwM7YAo81LoZk06yrsY4s82tzGLfVaV3OthqhW7/MmISGM37xPSU mG8tVsmhu93S8IyFaTN9K7pkbNqvoOqStX39QjDtZZlgPQWKON52KYSENLedgf6O /hqIE1XXqL4C1f2MxMEeWYEBoSl5GlGqMezGelf74IKZost/gJN6RQ== =Xqq4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 12:16:09 2016 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 344B712B01E for ; Mon, 18 Jul 2016 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 h00uoRYajZxB for ; Mon, 18 Jul 2016 12:16:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F69512B00D for ; Mon, 18 Jul 2016 12:16:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C75AE200A7; Mon, 18 Jul 2016 15:25:30 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D809638D1; Mon, 18 Jul 2016 15:16:05 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: References: <30186.1468852489@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Kovatsch Matthias , Routing Over Low power and Lossy networks Subject: Re: [Roll] useofrplinfo version 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:16:08 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> (unless we mandate that the E flag is >> propogated all the way upwards), then the root has to always use >> hop-by-hop IPIP for both 5.2 and 5.3, because the root can't tell >> which situation is in play. > I thought that this was a good occasion to point that out in the > rplinfo document. Noting that this issue goes away with rfc2460bis... but assuming that wasn't the case... if we need to clarify that the E flag is sent upwards, then we *can* say that in useofrplinfo, because it was designed to be standards track *UPDATE* to RFC6550. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV40q8oCLcPvd0N1lAQKoJwf/dLU1BKFgfjaB1O84kK+OMZfJoJEYmpmV JhmMa9J/G8iXe4riw+ya2bTXAxWV6j1xrRlVoZzJ0TXjM0NZYeiDTUHGv9pMw5UB sKboccoSfeKnzouhQP4DStk61KShtuSBPDr6BFL4VnjTMOilSlF/f2R6lg2XFYzG 8IEff/XbUo1RUKHdGGdnIr9lV+NIHH0jYMfXzert3cZhg7lB7PrVDwFFg08eOBqz o3QMIC/d9wrwZuFs75I/9SzXr3xUCsLo7eliRvfJZP+WNTpc9YOLKa6473Np/Dc2 ubzZgR9OtvuZe1tslSrpaZpZanUG2wTkLLi5jwhWHmcRZ9W5oV7tGQ== =25sh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 22:29:05 2016 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 7862012D0E2; Mon, 18 Jul 2016 22:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 ACwsQlC4tf_H; Mon, 18 Jul 2016 22:29:00 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A657B12D08F; Mon, 18 Jul 2016 22:28:59 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id o80so11727731wme.1; Mon, 18 Jul 2016 22:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BlDnyk/gP83XS7vzrB9KBqbrGZEKxsD7+w8yL1B/hrU=; b=KYnEg8vFSRD3K+VUA9mEIklyPAxyiJ6CxVbMiliOBnct6sUy/NeU37JYl+2FrWxU/9 uLC6a3kqYb6kyBmHyVxrmo9qsf3oqv/6rOjs4YxOSlYBmj9pi1EgKVtFuQShDRwtEDA5 3BqytCblgRCJz/27NHB0ZH5ojpu+ET3zanRFwCncldgMqHyMHWLdpmCmdCVr0q1/MN6V a6Azd8dXt8QL4wRqzUFtpXrVUcejElo339jyPzxBUQhTFM066cgvWwY17Oavt6fm/qWk KQGV3CMqXL4X7v6qK7/GU+9LFImw3BvN65GkXeM++6pb8wbvrGdl/yIWHppWdq+wTI8t t++g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BlDnyk/gP83XS7vzrB9KBqbrGZEKxsD7+w8yL1B/hrU=; b=LwXObDjk5GT5vR8vNvXmz4SZRc0tKTvNTPq1wGnO2nSH47Wak6PbF+uNz0h05m8y9c +YuZra43GOz5paIA7JUSYS0OiPobxWoRHhhibQ3q3go3mJ0XDN9GPiNfAmZE+jzfzTmz nfBo0lUi5qCxpyCcgxalW5D9+9VPk70e5iRzQAZUwGNxbB/65+wQxarZFyCtaZtniDY/ M76mRsNpEh7l4bqPLGFfHad7gaY5alsmCkLyff3BbxBXp8VInWG5SsDoQVK1XnUzLwfe dsJfccCETi2K44p5M9pp0zFcwcnBsLcSPKRuUDAzzRfN5K8aMLgV5EeM2uarpeuWyH19 B86A== X-Gm-Message-State: ALyK8tIIZUQh3DZuSoG+NfTbom9If2BCR4OT6GrhJhZYpFx0OSFMOOxTjP7AOeGnnv8izg== X-Received: by 10.194.176.34 with SMTP id cf2mr4617336wjc.172.1468906138114; Mon, 18 Jul 2016 22:28:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i195sm21946093wmg.1.2016.07.18.22.28.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 22:28:57 -0700 (PDT) To: Michael Richardson , roll@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> Date: Tue, 19 Jul 2016 17:28:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <24554.1468868593@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man@ietf.org Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 05:29:01 -0000 On 19/07/2016 07:03, Michael Richardson wrote: > > The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a > Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). > There is work on 6lo to allocate additional 6lowpan IPHC codes such that > the work in ROLL: > https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can > know what kinds of things we need to compress. > > A number of things are constrained by the need to always remove the > RFC6553 Hop-by-Hop option RPI option which had been marked critical: > i.e. drop packet if you don't understand it. > > As a result of the change in RFC2460bis, which says that intermediate hosts > will in general not examine hop-by-hop options, but should just ignore > them, we can make certain simplications to the useofrplinfo document. > (rfc2460bis, section 4, page 8, "NOTE: While...) You can already do that, because RFC7045 section 2.2 updates RFC2460: " The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]." which of course means that forwarding nodes MAY ignore HbH. > (It is unclear what end-hosts can/should do. I will assume they can > also ignore hop-by-hop options if they haven't been told to pay attention to > them). If they are 00 options, yes, RFC2460 is clear that for all options: The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. Brian > > https://goo.gl/cxWkP5 this is a reference to an RFC diff between: > draft-ietf-roll-useofrplinfo-06.txt > and draft-richardson-roll-useofrplinfo-2460bis-00.txt > > (Note we have only re-analyzed storing mode , so please ignore changes in > section 6) > > The summary is that in storing mode we never need to use per-hop > IPv6-in-IPv6 encapsulation with the 2460bis text. Packets originating from > not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be > encapsulated so that the RPI option can be added, but no complex > considerations need apply for where to remove the RPI, as it can be left in > place until the end-host. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 19 03:31:11 2016 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 8F55812B05A; Tue, 19 Jul 2016 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 G8GLhULbwMwc; Tue, 19 Jul 2016 03:31:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D112A12B049; Tue, 19 Jul 2016 03:31:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7197C20183; Tue, 19 Jul 2016 06:40:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0FE5D638D1; Tue, 19 Jul 2016 06:31:07 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, 6man@ietf.org In-Reply-To: <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Brian E Carpenter Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:31:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> >> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). >> There is work on 6lo to allocate additional 6lowpan IPHC codes such that >> the work in ROLL: >> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can >> know what kinds of things we need to compress. >> >> A number of things are constrained by the need to always remove the >> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >> i.e. drop packet if you don't understand it. >> >> As a result of the change in RFC2460bis, which says that intermediate hosts >> will in general not examine hop-by-hop options, but should just ignore >> them, we can make certain simplications to the useofrplinfo document. >> (rfc2460bis, section 4, page 8, "NOTE: While...) > You can already do that, because RFC7045 section 2.2 updates RFC2460: > " The IPv6 Hop-by-Hop Options header SHOULD be processed by > intermediate forwarding nodes as described in [RFC2460]." > which of course means that forwarding nodes MAY ignore HbH. It's not what *I* want to do, it's what *I* can expect *others* to do. So 7045 doesn't help me. > 00 - skip over this option and continue processing the header. A type=10 option was allocated by RFC6553 I think it was a mistake. We have discussed changing it as we add compression for 6553, 6554 and IPIP (which would be a flag day anyway). This was considered undesireable, because there was a desire not to leak our headers; that the internet would drop our packets if we screwed up. But, it turns out that the internet won't drop out packets, so we might as well optimize the situation so that if we don't need to remove our Hob-by-Hop header, then we don't need extra IPIP headers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV44BZoCLcPvd0N1lAQLDrAgAvFKzmGFSAvAyAL7yRB1IkhiQpv0W/JA1 3OAxOlIpTBMZ/hRLSbfIzSePYFwAhI9IJc9eo5ecWidxjmpIQT/tjZwUIp6EiYP1 MfQpzSR0lsPiCfvYNAe5JViokwR24z2RMqCsGOCxmRmL7eHzloamzwehqwQr4oFo CZAd3VoZoIxXWAwvO/80tNaN8Z0qDhZiQsi263fvbS+sK0GCx4OOWZP8ryLHMDA9 JfAn1gfT5MuXJwK0ss2OWvbLH+bGn/h5vVqfTjL/kpKVYKzf49+mKyjAjFUdY6MP LYbeqWeWQQ4+XSxJOcyRH2txWdI/6XNIoSI0mFPr1bfIT12uMS+H+A== =Wkhf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 19 04:14:47 2016 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 B09C412B02B; Tue, 19 Jul 2016 04:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 jE38ZbDEwS3s; Tue, 19 Jul 2016 04:14:44 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 9CD6C12B057; Tue, 19 Jul 2016 04:05:44 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id b199so10925064lfe.0; Tue, 19 Jul 2016 04:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+HsL9aVKwCvPHY3O//I1f42Yzh722DBZoRa6Dj6vE5E=; b=ToI5gaTPuBvAo5ctQj7Sb4uMl7tBkaSCHIu4pM0s2gFQbTkdJUjiQN/xUosloGGL2p Yg6l87LLRVGGLiefinGHVbshO5LvXvUkOIxbJc4GYeIX2LjtQtwpFTefFGq/0clSqAva h68Bi8F/X36YQ+dujCC2ugommQBfSwKRMSnva6hhKq801xw9JbjqwAq70BAV/6WottGA 1sh85O5YCVGRMG9PDrjSDO1CWcm/02iLqSAexMnnYjgNwZEqp/kg73yMeyoJpYqDZjII KiaHUSVWxHi+0exBPhnG3FW/s5GTZrdwJem2hxsV5G5SY9Q4FKbKJd37feQhXJ0mAro7 weFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+HsL9aVKwCvPHY3O//I1f42Yzh722DBZoRa6Dj6vE5E=; b=C+XzwBBbtG047CZboPuRktbEvw2Sojg/7GtT//xEJpUkSrhAFH91zq0dVC3xZPlVE5 c1eeATHSKhSvmkRL4OrdtdlkK1VMyhsTtPx5PNTFYiC66ydECQMtcjpwHVlIC+k2R9J8 j0CsMZCrptUIN+Ezsr7aTAEMQOsqBMw0PRqspIrU8qwEhf4hqcNLK/Ii1Quf4UI3cbHr x/TvwmKNxMQvei5rQRMh8iPSNyK7B7clDazHWdHH80+tXVOc+BuimnRhA5Eb4Dogzlyg vJmNyCA3XeWjedMLQSZJDc0+1EDmHD1OfaIHFuRH1wZXYPkATRZYFEXHvUU0K40PQZB1 ajpA== X-Gm-Message-State: ALyK8tK8eqaOdNNMtRFXphDqpc3u1sWtalDdFuYKsBdHN/ToCopi+28ZxM1r9DZhBsMdCA== X-Received: by 10.25.212.5 with SMTP id l5mr5958901lfg.73.1468926342730; Tue, 19 Jul 2016 04:05:42 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 17sm5542994ljj.49.2016.07.19.04.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 04:05:41 -0700 (PDT) To: Michael Richardson , roll@ietf.org, 6man@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 19 Jul 2016 23:05:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <30725.1468924267@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:14:46 -0000 On 19/07/2016 22:31, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> > >> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a > >> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). > >> There is work on 6lo to allocate additional 6lowpan IPHC codes such that > >> the work in ROLL: > >> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can > >> know what kinds of things we need to compress. > >> > >> A number of things are constrained by the need to always remove the > >> RFC6553 Hop-by-Hop option RPI option which had been marked critical: > >> i.e. drop packet if you don't understand it. > >> > >> As a result of the change in RFC2460bis, which says that intermediate hosts > >> will in general not examine hop-by-hop options, but should just ignore > >> them, we can make certain simplications to the useofrplinfo document. > >> (rfc2460bis, section 4, page 8, "NOTE: While...) > > > You can already do that, because RFC7045 section 2.2 updates RFC2460: > > " The IPv6 Hop-by-Hop Options header SHOULD be processed by > > intermediate forwarding nodes as described in [RFC2460]." > > which of course means that forwarding nodes MAY ignore HbH. > > It's not what *I* want to do, it's what *I* can expect *others* to do. > So 7045 doesn't help me. Well, it legitimizes a router simply ignoring a HbH header. Isn't that useful? > > > 00 - skip over this option and continue processing the header. > > A type=10 option was allocated by RFC6553 > > I think it was a mistake. Agreed. Brian > We have discussed changing it as we add > compression for 6553, 6554 and IPIP (which would be a flag day anyway). > This was considered undesireable, because there was a desire not to leak > our headers; that the internet would drop our packets if we screwed up. > > But, it turns out that the internet won't drop out packets, so we might > as well optimize the situation so that if we don't need to remove our > Hob-by-Hop header, then we don't need extra IPIP headers. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Tue Jul 19 04:37:59 2016 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 1E6BF12D0F5; Tue, 19 Jul 2016 04:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 Zqof3eRfrefz; Tue, 19 Jul 2016 04:37:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2037712D0BF; Tue, 19 Jul 2016 04:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2996; q=dns/txt; s=iport; t=1468928274; x=1470137874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B5WntOcXl5Z1i9LNkhxrQa/xldw0K9lb/NnEf5b/zAk=; b=UIiMwLH9W2L5lmPKot+ZknfmIGNL1eEtdZvFz29EFt0Y7VuGeF3uQtRB 8AVy/DoD0mcTzVHUvx4/80b7zoadP77CfsXJkFEAlVGKeD/cyhqojiq7J HApxMzAvloGFvcL8b75XeRn/xMBfyDbHhYUEFOOklX4B341UlCHkfWmmu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AABgAhEI5X/5FdJa1cgz9WfKxMjBqBe?= =?us-ascii?q?iKCQYM3AoEvOhIBAQEBAQEBZSeEXAEBBAEBAWwLBQsCAQgYLiEGCyUCBA4FiBY?= =?us-ascii?q?DDwgOuFQNhB4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXiCVYJDgX2DLIIvB?= =?us-ascii?q?Y5Eiiw0AYYShjGCHo83iCWHeAElCiWDc24BiA8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="127460276" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 11:37:53 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6JBbr2h027809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 11:37:53 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 06:37:52 -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, 19 Jul 2016 06:37:52 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4X59TqNb256fWESru62KIaaKWqAf4iWAgAAJrAD//7UpVw== Date: Tue, 19 Jul 2016 11:37:52 +0000 Message-ID: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:37:56 -0000 Actually Brian: What is really needed here is not for routers but for the end hosts to igno= re a HbH they are not programmed to recognize.=20 The new text says all nodes on the path do. This seems to include the recei= ver in which case we're good. This will not change that most open implementations of RPL (all but a proto= type implementing this draft) actually do header insertion. Regards, Pascal > Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >=20 >> On 19/07/2016 22:31, Michael Richardson wrote: >>=20 >> Brian E Carpenter wrote: >>>>=20 >>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header,= RH3). >>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such th= at >>>> the work in ROLL: >>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can >>>> know what kinds of things we need to compress. >>>>=20 >>>> A number of things are constrained by the need to always remove the >>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>> i.e. drop packet if you don't understand it. >>>>=20 >>>> As a result of the change in RFC2460bis, which says that intermediate = hosts >>>> will in general not examine hop-by-hop options, but should just ignore >>>> them, we can make certain simplications to the useofrplinfo document. >>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>=20 >>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>> intermediate forwarding nodes as described in [RFC2460]." >>> which of course means that forwarding nodes MAY ignore HbH. >>=20 >> It's not what *I* want to do, it's what *I* can expect *others* to do. >> So 7045 doesn't help me. >=20 > Well, it legitimizes a router simply ignoring a HbH header. Isn't that us= eful? >=20 >>=20 >>> 00 - skip over this option and continue processing the header. >>=20 >> A type=3D10 option was allocated by RFC6553 >>=20 >> I think it was a mistake. >=20 > Agreed. > Brian >=20 >> We have discussed changing it as we add >> compression for 6553, 6554 and IPIP (which would be a flag day anyway). >> This was considered undesireable, because there was a desire not to leak >> our headers; that the internet would drop our packets if we screwed up. >>=20 >> But, it turns out that the internet won't drop out packets, so we might >> as well optimize the situation so that if we don't need to remove our >> Hob-by-Hop header, then we don't need extra IPIP headers. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jul 19 05:18:44 2016 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 EE48212D60A for ; Tue, 19 Jul 2016 05:18:41 -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 bdc5wzB9gsru for ; Tue, 19 Jul 2016 05:18:39 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 4810312D60D for ; Tue, 19 Jul 2016 05:18:39 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id w127so21619378vkh.2 for ; Tue, 19 Jul 2016 05:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=unZLkx0ae3xRt/7flNHSmxXPmKJPM9Cc78/N4FvAuqU=; b=qdtqJN10RyZuPEpSdJkeUnWgIPVt+oV2soH2x8PoYGJvaWhdSez4gzhlpJiW8ewwhb 963ym1EBMxem7bTY+JPH4SBWwDgtJgzXkB1R/oEBUKsVDOEYHDUUNNlkAQueuXgvYHTG IkVp/uTqc1l6ez0D0PEveLqqOoNMU90ulwuFl2K58WFRBaWihvcfy/oIXGvjfnZYe9CX JvRKidkHMsr65sZOKrx9A+i0ObDM15fAoEwew7hQ7+nLx8snkcwbqAkMLIOmsTXW/l2O NIANI3/rghYzYKRI1+u14qMesnI9X/qXMkyiuz21EQyJhkIXC5l5RQdzuL1GRWQaFjDi jVeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=unZLkx0ae3xRt/7flNHSmxXPmKJPM9Cc78/N4FvAuqU=; b=h5yZnDbaxrFqxKt66ilQ5wVwADQnCOSqMvorpLe1PbSIl5i77ywSoKKFLV1awjmMmU cIpbJxvM2cfwOWoCR2i+nuzslOu3SMEgvaUB/STYTraQXtYgfPac/gZWFtRHBb8xqQEu DisUmpmbpJ0hmOJa7BTs6xk7dTcjLaPDge3YT3oFixq4Sf1+TMb1JUJX+6b8Z3UKR0zq k71SpIK4pFiZfkKkxTKrW8/QzEvej3GNFDxeuNDU8dEyyJbXKGkEXQG2cjRM6k5G3lcr /F7zAAncSESBeLClQVN1gFj7LkKvp1aFioyE6xC3AVA0Z1J5V5uiukgDhzgN++3mDUas KgOA== X-Gm-Message-State: ALyK8tIjDDVxxNn3nBwQWjcAPUnE9YyLCT7PLTE7YBB9rZdpbxCaOfNTNVlInfIMS+W6cLLwP+rQGE7sT85/Dw== X-Received: by 10.176.2.238 with SMTP id 101mr20551026uah.5.1468930718223; Tue, 19 Jul 2016 05:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Tue, 19 Jul 2016 05:18:37 -0700 (PDT) From: Ines Robles Date: Tue, 19 Jul 2016 15:18:37 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a113cf190a8d2f60537fc1588 Archived-At: Subject: [Roll] Request for Comments ROLL Charter - version 07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:18:42 -0000 --001a113cf190a8d2f60537fc1588 Content-Type: text/plain; charset=UTF-8 Dear all, Please find a new version of the proposed charter. We have corrected the typos and updated the milestones. Please comment. Thank you very much, Peter and Ines //////////////////////////////////////////////////////////////////////////////////////////////////////// CHARTER PROPOSAL: Charter for ROLL Working Group Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs are characterized as follows, but not limited to: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy by using small packet headers and reduce amount of control packets. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes and low bit rates, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; since LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. RFC 5548, 5673, 5826, and 5876 describe the requirements for LLNs from several application perspectives. The Working Group has focused on routing solutions for the areas: connected home, building and urban sensor networks. It has developed a protocol set that takes into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group continues to focus on routing issues for LLN and to maintain, improve and streamline the protocols developed by the working group, including RPL and MPL. ROLL will coordinate closely with the working groups in other areas that focus on constrained node networks, such as 6lo (Internet) and CoRE (APP). behavior and the other protocols defined by the working group. The Working group will align with the 6man, NETMOD and BIER WGs when needed. Work Items are: - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. The WGLC on this work will be shared with 6lo. - Compression of RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. (coordinated with 6lo WG). - Automatic selection of MPL forwarders to reduce message replication - Data models for RPL and MPL management (coordinated with netmod wg) - Alternative Multicast algorithm such as BIER forwarding. - Methods to improve or correct the current RPL control messages behaviour, e.g. DIS and No-Path DAO. Milestone Date Milestones May 2016 --------------------- Initial submission of the draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context. to the IESG. draft-ietf-roll-routing-dispatch August 2016 ------------------- Initial Submission of the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo to the IESG. October 2016 ------------------ Submit draft about YANG MPL model to IESG January 2017 ------------------ Initial submission of draft about MPL Forwarder selection to IESG March 2017 -------------------- Initial submission of draft about YANG RPL model to IESG April 2017 ------------------- Initial submission of draft about BIER Multicast to IESG April 2017 ------------------- Initial Submission of the No-Path DAO Problem Statement to the IESG April 2017 ------------------- Initial Submission of the DIS Modifications Document to the IESG September 2017 ---------------- Recharter WG or close --001a113cf190a8d2f60537fc1588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear= all,

= Please find a new version of the proposed charter. We have corrected the ty= pos and updated the milestones.

<= div class=3D"gmail_extra">Please comment.
<= br>
Thank you very much,

Peter and Ines

///////////////= ///////////////////////////////////////////////////////////////////////////= //////////////

CHARTER PROPOSAL:

Charter for ROLL Working Group

Low power and Lossy Networks = (LLNs ) [RFC7102] [RFC7228] are made up of many embedded devices with limit= ed power, memory, and processing resources. They are interconnected by a va= riety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or = other low power PLC (Powerline Communication) links. LLNs are transitioning= to an end-to-end IP-based solution to avoid the problem of non-interoperab= le networks interconnected by protocol translation gateways and proxies.

Generall= y speaking, LLNs are characterized as follows, but not limited to:

LLNs operate w= ith a hard, very small bound on state.=C2=A0
In most cases, LLN optimize for saving energy by using small packet heade= rs and reduce amount of control packets.
Ty= pical traffic patterns are not simply unicast flows (e.g. in some cases mos= t if not all traffic can be point to multipoint).
In most cases, LLNs will be employed over link layers with restricte= d frame-sizes and low bit rates, thus a routing protocol for LLNs should be= specifically adapted for such link layers.=C2=A0
LLN routing protocols have to be very careful when trading off effic= iency for generality; since LLN nodes do not have resources to waste.
=
These specific properties cause LLNs to have spe= cific routing requirements.

RFC 5548, 5673, 5826, and 5876 describe the requireme= nts for LLNs from several application perspectives.
The Working Group has focused on routing solutions for the areas: = connected home, building and urban sensor networks. It has developed a =C2= =A0protocol set that takes into consideration various aspects including hig= h reliability in the presence of time varying loss characteristics and conn= ectivity while permitting low-power operation with very modest memory and C= PU pressure in networks potentially comprising a very large number (several= thousands) of nodes.

The Working Group continues to focus on routing issues for= LLN and to maintain, improve and streamline the protocols developed by the= working group, including RPL and MPL.

=
ROLL will coordinate closely with the work= ing groups in other areas that focus on constrained node networks, such as = 6lo (Internet) and CoRE (APP). behavior and the other protocols defined by = the working group. The Working group will align with the 6man, NETMOD and B= IER WGs when needed.

Work Items are:

=
- Guidance in using RFC6553, RFC6554, and IPv6-i= n-IPv6 encapsulation. The WGLC on this work will be shared with 6lo.=C2=A0<= /div>

- Comp= ression of =C2=A0RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation= layer context. (coordinated with 6lo WG).
=
- Automatic selection of MPL forwarder= s to reduce message replication

<= div class=3D"gmail_extra">- Data models for RPL and MPL management (coordin= ated with netmod wg)

- Alternative Multicast algorithm such as BIER forwarding.=

- Met= hods to improve or correct the current RPL control messages behaviour, e.g.= DIS and No-Path DAO.


Milestone


Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Milestones

May 2016 =C2=A0--------------------- Initial submission of= the draft about how to compress RFC6553, RFC6554, and IP headers in the 6L= oWPAN adaptation layer context. =C2=A0to the IESG. draft-ietf-roll-routing-= dispatch

August 2016 ------------------- Initial Submission of the draft about wh= en to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-= useofrplinfo to the IESG.

October 2016 ------------------ Submit draft about YANG= MPL model to IESG

January 2017 ------------------ Initial submission of draft ab= out MPL Forwarder selection to IESG

March 2017 -------------------- Initial submi= ssion of draft about YANG RPL model to IESG

April 2017 =C2=A0------------------- = Initial submission of draft about BIER Multicast to IESG

April 2017 =C2=A0-------= ------------ Initial Submission of the No-Path DAO Problem Statement to the= IESG

= April 2017 =C2=A0------------------- Initial Submission of the DIS Modifica= tions Document to the IESG

September 2017 ---------------- Recharter WG or close<= /div>
--001a113cf190a8d2f60537fc1588-- From nobody Tue Jul 19 07:03:37 2016 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 B2C6312E06E; Tue, 19 Jul 2016 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 KzsQPcEvx_N7; Tue, 19 Jul 2016 07:03:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A463912E196; Tue, 19 Jul 2016 06:29:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F897203BC; Tue, 19 Jul 2016 09:38:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7B9BC638D1; Tue, 19 Jul 2016 09:29:31 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6lo@ietf.org Subject: [Roll] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:03:36 -0000 --=-=-= Content-Type: text/plain Pascal spoke today in 6man concerning the process of providing privacy enhanced addresses in 6man, and how LLNs typically use their 2-byte short addresses for layer-2, and also for forming L3 addresses. Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefore unrelated to the EUI-64. (Of course, many just use the bottom two bytes of the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to spec) I was thinking about the dhcpv6 process. In order to do it in a route-over mesh, the route-over mesh needs to be up in order to get traffic to the DHCPv6 server. That means that the DAG has been formed using EUI-64 derived link local addresses. Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 server, and will then set their L2 address based upon that. I think that this is not specified anywhere...? But, the thing that got to write this email (while doing my IETF96 laundry), is the parent selection process. Do we need to have a way for an RPL parent to say in it's DIO, "I know you see me as fe80::1234, but you knew me before as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and efficient transition to the new 2-byte addresses? Perhaps it's good enough that the node, having been allocated a 2-byte L2 address, does a gratitous NA where it announces it's EUI64 LL address with it's 2-byte L2 address? How does that sit security-wise? Have we just encouraged the network to accept gratuitous L2 address spoofing? How does this interact with Back-Bone Router EARO processing? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV44rOICLcPvd0N1lAQKn1Af7BXebgsfOlPQkATV6A1E6g6XaxuefYJiM NVjrOQqpYMTLbIry9O/O28CLeydb5c9n2t5GW4hs2gyhLUtouzY0myoSY/sU1xm5 fafQX/a5SMHU1PFkSE0H7y++z0KJ58uDLr9xRroldiPX1PHfEARr2Rc1ykd4ejHc cVdmTuvvh+gtEio7X/neVTdseRhsYc/6M6YWGJU8k37yfNYAe8xm4mKjaFut5BZM vCphl+kz0OGHgEbmRATAen6sZWzXTXJshyYbqWsYjEmJBE0icAIs26gVEQYZxyIV vd00aOIWo+diF3aHmvkGoFeZwbe0HTvpM6xgjAWHwpbKUuLa1YNwGg== =05go -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 19 07:55:35 2016 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 9681212DD29; Tue, 19 Jul 2016 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 jlUNfMZTV9T3; Tue, 19 Jul 2016 07:55:27 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 421CC12E155; Tue, 19 Jul 2016 07:32:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6478F615EB; Tue, 19 Jul 2016 10:32:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id db83iiBz93MR; Tue, 19 Jul 2016 10:32:17 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-a2d7.meeting.ietf.org [31.133.162.215]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1A5B8615E6; Tue, 19 Jul 2016 10:32:15 -0400 (EDT) To: roll@ietf.org References: <4193.1468934971@obiwan.sandelman.ca> From: Robert Moskowitz Message-ID: Date: Tue, 19 Jul 2016 16:32:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4193.1468934971@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------BA3F4AF2CF32F4484CF8EF22" Archived-At: Cc: 6lo@ietf.org Subject: Re: [Roll] [6lo] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:55:30 -0000 This is a multi-part message in MIME format. --------------BA3F4AF2CF32F4484CF8EF22 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit If the transition can be augmented by an ephemeral public key, and some parameters, perhaps, in dhcpv6, this could work as you indicated in a safe manner. On 07/19/2016 03:29 PM, Michael Richardson wrote: > Pascal spoke today in 6man concerning the process of providing privacy > enhanced addresses in 6man, and how LLNs typically use their 2-byte short > addresses for layer-2, and also for forming L3 addresses. > Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefore > unrelated to the EUI-64. (Of course, many just use the bottom two bytes of > the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to spec) > > I was thinking about the dhcpv6 process. In order to do it in a route-over > mesh, the route-over mesh needs to be up in order to get traffic to the > DHCPv6 server. That means that the DAG has been formed using EUI-64 derived > link local addresses. > > Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 server, > and will then set their L2 address based upon that. I think that this is > not specified anywhere...? > > But, the thing that got to write this email (while doing my IETF96 laundry), > is the parent selection process. Do we need to have a way for an RPL parent > to say in it's DIO, "I know you see me as fe80::1234, but you knew me before > as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and > efficient transition to the new 2-byte addresses? > > Perhaps it's good enough that the node, having been allocated a 2-byte L2 > address, does a gratitous NA where it announces it's EUI64 LL address with > it's 2-byte L2 address? How does that sit security-wise? Have we just > encouraged the network to accept gratuitous L2 address spoofing? > > How does this interact with Back-Bone Router EARO processing? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo --------------BA3F4AF2CF32F4484CF8EF22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

If the transition can be augmented by an ephemeral public key, and some parameters, perhaps, in dhcpv6, this could work as you indicated in a safe manner.


On 07/19/2016 03:29 PM, Michael Richardson wrote:
Pascal spoke today in 6man concerning the process of providing privacy
enhanced addresses in 6man, and how LLNs typically use their 2-byte short
addresses for layer-2, and also for forming L3 addresses.
Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefore
unrelated to the EUI-64.  (Of course, many just use the bottom two bytes of
the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to spec)

I was thinking about the dhcpv6 process.  In order to do it in a route-over
mesh, the route-over mesh needs to be up in order to get traffic to the
DHCPv6 server.  That means that the DAG has been formed using EUI-64 derived
link local addresses.

Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 server,
and will then set their L2 address based upon that.    I think that this is
not specified anywhere...?

But, the thing that got to write this email (while doing my IETF96 laundry),
is the parent selection process.  Do we need to have a way for an RPL parent
to say in it's DIO, "I know you see me as fe80::1234, but you knew me before
as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and
efficient transition to the new 2-byte addresses?

Perhaps it's good enough that the node, having been allocated a 2-byte L2
address, does a gratitous NA where it announces it's EUI64 LL address with
it's 2-byte L2 address?  How does that sit security-wise?  Have we just
encouraged the network to accept gratuitous L2 address spoofing?

How does this interact with Back-Bone Router EARO processing?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-






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

--------------BA3F4AF2CF32F4484CF8EF22-- From nobody Tue Jul 19 07:58:06 2016 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 7849012DD01 for ; Tue, 19 Jul 2016 07:58:03 -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 w0DloSi7yQ93 for ; Tue, 19 Jul 2016 07:58:02 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661A312E2A6 for ; Tue, 19 Jul 2016 07:35:03 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id w127so27120843vkh.2 for ; Tue, 19 Jul 2016 07:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=a2gfGoB/J650myb4fhoBMGhkwVGnRZcbXG2Jeh/Ka+o=; b=Xp05EPv9bwdFrdYDsrKd8nPJQT7juZxF89QL/PXRxv6tIcQIRNeC8w4AML0PxhNAAu MsKfR/lNTnOHG2rGDVUu5uFKNYk64uvrKeOt4hd19GcnzVy3QMQVyUMUMpBc3L3p2LMT rHe34kkU1//s2Xgols2oz6uFxDWc4+aElqjn4zhpyi7JGj59zYCveHM6L1TEYOkJ99rm lJOteNHtg3ly6MkY1lti3uwtT7FUsWzsilJMfGkl6AVIeuTH+J6KZPKUpgKgp3xpJquZ gPaESo7RWhlWRbqqzbwBd3Ffx3bvvYIdgEoGp+z8AG2YodnSf/VJpuk5zQw+cDH9YwYw 6jkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=a2gfGoB/J650myb4fhoBMGhkwVGnRZcbXG2Jeh/Ka+o=; b=Lx72Js4I1PFzZKTbH0vVALOQYrfU9b1+mZSsnBv6op/fXCOYtigdG7wDl8f7acK2iW fTIeZi376kvHMajmXAr45kVb827TMceXWFAQF1tgs2YgOxbbSF6bDguaLYBIRPWv3zUO Qa8vTRcOWfQcARozd++mdyhPeQ3zAFuK8RDD1LcjKZQuc8mnfyWMlFVosMJRM4bNvnir dFFdoKQft52SCat7W8q5Le8aCSspjV0Cso5vx36olhJQoV2zOqLpFx18pwb8l6//kDpZ a83NEQMXc3F4qEhh4DwI2yowLgoQCCLhEbQkKqxJ+sT+FigfjqiN07UpG72pGOVLI1EA EyyQ== X-Gm-Message-State: ALyK8tLtAJNg9mQbYaz9djVt4sIz/zHp8fyRYl7Qpx1fLBJBVSusBJwcNmbiRj+BMjyWCd8SQKGy4o27WaSHzA== X-Received: by 10.159.35.40 with SMTP id 37mr20709424uae.118.1468938902329; Tue, 19 Jul 2016 07:35:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Tue, 19 Jul 2016 07:35:02 -0700 (PDT) From: Ines Robles Date: Tue, 19 Jul 2016 17:35:02 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a113bcc7e785fb10537fdfd33 Archived-At: Subject: [Roll] Agenda IETF 96 - updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:58:03 -0000 --001a113bcc7e785fb10537fdfd33 Content-Type: text/plain; charset=UTF-8 Dear all, Please find the updated agenda for the meeting tomorrow. https://www.ietf.org/proceedings/96/agenda/agenda-96-roll Any comments are very welcome, Thanks, Peter and Ines --001a113bcc7e785fb10537fdfd33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the updated agend= a for the meeting tomorrow.=C2=A0


Any c= omments are very welcome,

Thanks,

Peter and Ines



<= div>
--001a113bcc7e785fb10537fdfd33-- From nobody Tue Jul 19 08:19:04 2016 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 AA97312D868; Tue, 19 Jul 2016 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 iXdP9Mp2Dzj7; Tue, 19 Jul 2016 08:18:56 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAD012D937; Tue, 19 Jul 2016 07:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2356; q=dns/txt; s=iport; t=1468940256; x=1470149856; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8eaJ5JpZHJqgzRHXAjR8c9CVzNxwave8c4uSoNQEZMU=; b=GHF2Lhd8s9ro1eoWeo7Opwi7aiohbk6vGb9wOAIJo162IiVsnokhexLo OjDyZ5IN0lPa8KfJdUAyMreKmB1zyx66suJuWrcFl/VyPSNG6vANcgURZ CZplMVTFSH2TnBtto9++wqO/swppjS8wVqMRzzwDcC8jIQlqFOwCMFLaN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgATP45X/5BdJa1cgz9WfLhngXoig?= =?us-ascii?q?kGDNwKBLzgUAQEBAQEBAWUcC4RdAQQBAQFsCwULAgEIRicLJQIEDgWIKAgOvE4?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXgIgk2EEhEBBhaFWwWORIpgAYkNh?= =?us-ascii?q?VSPN5AdAR42gggDHIFMboZhDxcEgRoBAQE?= X-IronPort-AV: E=Sophos;i="5.28,390,1464652800"; d="scan'208";a="297779776" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 14:57:35 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6JEvZ4a010843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 14:57:35 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 09:57:34 -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, 19 Jul 2016 09:57:34 -0500 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: [6lo] privacy enhanced l2 addresses and parent selection in ROLL Thread-Index: AQHR4caMSXOr0gwlvEWbOHI2l3eejqAf2De8 Date: Tue, 19 Jul 2016 14:57:34 +0000 Message-ID: <255FC706-DF79-4333-83D7-178608251273@cisco.com> References: <4193.1468934971@obiwan.sandelman.ca> In-Reply-To: <4193.1468934971@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:18:59 -0000 For the sake of things I said assigned and said that this assignment plays = the role that was expected from DHCP but not really delivered of getting te= mporary addresses.=20 The rest is my French: Using DHCP to assign them is interesting but beyond = my intent. Regards, Pascal > Le 19 juil. 2016 =E0 16:05, Michael Richardson a = =E9crit : >=20 >=20 > Pascal spoke today in 6man concerning the process of providing privacy > enhanced addresses in 6man, and how LLNs typically use their 2-byte short > addresses for layer-2, and also for forming L3 addresses. > Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefo= re > unrelated to the EUI-64. (Of course, many just use the bottom two bytes = of > the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to s= pec) >=20 > I was thinking about the dhcpv6 process. In order to do it in a route-ov= er > mesh, the route-over mesh needs to be up in order to get traffic to the > DHCPv6 server. That means that the DAG has been formed using EUI-64 deri= ved > link local addresses. >=20 > Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 ser= ver, > and will then set their L2 address based upon that. I think that this = is > not specified anywhere...? >=20 > But, the thing that got to write this email (while doing my IETF96 laundr= y), > is the parent selection process. Do we need to have a way for an RPL par= ent > to say in it's DIO, "I know you see me as fe80::1234, but you knew me bef= ore > as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and > efficient transition to the new 2-byte addresses? >=20 > Perhaps it's good enough that the node, having been allocated a 2-byte L2 > address, does a gratitous NA where it announces it's EUI64 LL address wit= h > it's 2-byte L2 address? How does that sit security-wise? Have we just > encouraged the network to accept gratuitous L2 address spoofing? >=20 > How does this interact with Back-Bone Router EARO processing? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Wed Jul 20 04:00:43 2016 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 B0C3F12DB3B for ; Wed, 20 Jul 2016 04:00:41 -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 WIfkOEHJvzot for ; Wed, 20 Jul 2016 04:00:40 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 9FD5612DB02 for ; Wed, 20 Jul 2016 04:00:27 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id x130so63903956vkc.0 for ; Wed, 20 Jul 2016 04:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=pU3/ilUjt0ly/N8xfYvsS95ZWlKrMR1lZwm1e8Yy9sI=; b=tIxFCkMagfN8dCrj5yIB9to4oouWGmFzSPlzFrm4BAd3fVU2W68Rz/XC0KkTs8yQe2 86OLOiyD3npL26e9ajNP7ZHSdRHdVnUGLhuMEeiT6WXLj/vew5tVEPLs+38fyD1R0GDg tbZf1my0DJg4FgEPtGaz5hJmzHjq17qX5A9s4/WYQI0iPcxqrXokGIB2Lc1CxegtroIg JQQqmlgYtExh+Th6CLesE2xgPSSOPv5QweSv0V/G/dNrdSGVISyTVRfPw727fk9IwD3C +6Jps0oxcZ2qzPg8BExk0eekwN/inA6sySiS3YpZ5qvJoQWqPe3RXJCmBV1hztt1Ress LyBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pU3/ilUjt0ly/N8xfYvsS95ZWlKrMR1lZwm1e8Yy9sI=; b=SLJ4RshL5PstKbilb3oXlqK1loE1ZQFI9r5KuktWdZPgETq7yEaDz98Z2RxqiGoxNy K1MYI/sXlQKEi7VF8BmP0FsikWFISlKLJwcZbmGd/RYS7FTU5Hoaza47kRSXd9LlD7ix RfogfeZ0HTOt2rW9Y+txwwcK5eXQBJk0vI3V4jrpGpvgfGsSUZX/VkdztSLUWTNRm9Vs RBds5lsOYZ/Z757kZkxLy4K4xZ7dCRhJdgvEs24+3MkuGqXlin86/DJNQJztUDNIgm3Z CyemyOLAKrQXyF8BqcCbnLLE+pB3nMWQ3o0c5VKFEP1HAgxiWDg3IwPHcYRb4LuwHXmC l9bA== X-Gm-Message-State: ALyK8tKa24sygHLbzYb2rcWOeTvjTZgLIlSB9ClO/7hDleNxONITa6V2vWG8dTecwreZiFOQCc8ZxEQqMovlPQ== X-Received: by 10.176.0.108 with SMTP id 99mr23063905uai.71.1469012426523; Wed, 20 Jul 2016 04:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Wed, 20 Jul 2016 04:00:26 -0700 (PDT) From: Ines Robles Date: Wed, 20 Jul 2016 14:00:26 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=001a113f2ba0da8a0d05380f1b3d Archived-At: Subject: [Roll] IETF 96 - Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:00:42 -0000 --001a113f2ba0da8a0d05380f1b3d Content-Type: text/plain; charset=UTF-8 Dear all, Please find the slides for the meeting today https://www.ietf.org/proceedings/96/slides/slides-96-roll-1.pdf Comments are welcome Thanks Peter and Ines --001a113f2ba0da8a0d05380f1b3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the slides for th= e meeting today


Comments ar= e welcome

Thanks

Peter an= d Ines=C2=A0
--001a113f2ba0da8a0d05380f1b3d-- From nobody Wed Jul 20 04:27:15 2016 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 C555612DBB0; Wed, 20 Jul 2016 04:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 btj0d1DMGs5U; Wed, 20 Jul 2016 04:27:11 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7C612B05F; Wed, 20 Jul 2016 04:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=430; q=dns/txt; s=iport; t=1469014031; x=1470223631; h=reply-to:subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GLAbiws59h0i3gH5W74P6FbmYZqDQXudfT4T6WcefkE=; b=UJqE9jR0UDLBvXBM9/ZgyPug1hZeCq0z/XRXf6Qq6ZCa0IaEyG76UEyo 5dAd2dfQaDHXNe+HnA+c5mIJC+xrqKuSZvAKxYiRfTHMfteYe7noLTUaw DOW+Dk6XWz3NPyi8qZUgLzTpeEu0N7nmrdu6x3sIFDUxu8ur0JVNZkHMi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3BgB6Xo9X/xbLJq1dhD+3GoQJhhoCg?= =?us-ascii?q?XsBAQEBAQFmJ4RdAQU4QRALGC5XEwgBAYgstgiHSgEBAQEBAQQBAQEBI4YqgXi?= =?us-ascii?q?CVYQqYoUPAQSZJokOhVSBVgGHe4VnkCBUg3U6iCIBAQE?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="636871450" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 11:27:09 +0000 Received: from [10.61.225.225] ([10.61.225.225]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6KBR8pe010837; Wed, 20 Jul 2016 11:27:09 GMT References: <4193.1468934971@obiwan.sandelman.ca> To: roll@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: Date: Wed, 20 Jul 2016 13:27:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4193.1468934971@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 6lo@ietf.org Subject: Re: [Roll] [6lo] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: paduffy@cisco.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:27:14 -0000 On 7/19/2016 3:29 PM, Michael Richardson wrote: > I was thinking about the dhcpv6 process. In order to do it in a route-over > mesh, the route-over mesh needs to be up in order to get traffic to the > DHCPv6 server. That means that the DAG has been formed using EUI-64 derived > link local addresses. Confirming. Assuming non storing RPL ... are you thinking the LBR is maintaining the DAG with link local addresses? From nobody Wed Jul 20 04:49:33 2016 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 EE7A112D1E6; Wed, 20 Jul 2016 04:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 1Uk7l2UumMTr; Wed, 20 Jul 2016 04:49:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA2412B01B; Wed, 20 Jul 2016 04:49:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E414E200A3; Wed, 20 Jul 2016 07:58:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F1D18638D1; Wed, 20 Jul 2016 07:49:24 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz In-Reply-To: References: <4193.1468934971@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: roll@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [6lo] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:49:28 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: > If the transition can be augmented by an ephemeral public key, and > some parameters, perhaps, in dhcpv6, this could work as you indicated > in a safe manner. If we are doing per-link keying, and we transition our address, and we can propogate the L2-security upwards, then I agree that this transition could be secured. I'm still thinking that we might need a L3-RPL level signal which would be secured. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV49lP4CLcPvd0N1lAQKSHAf+Ll74D0o3gYctbem0VssA3kVxpbnHPPaP AkFJhF1Qb53799UykGKz728bbFyNFezdDjbuICHXh+76Pl8XtXUQtI6Wz7nsf7Ml Ku4jxAf+eIr+4v/plIQilV+eQvSiOm0942qnvf5I6IRZqp9C1QUMo8gfhb8rbg7x zl7/OvapN0GijWCmBlhLR/vX5B+BW0dY4T9G4ByuPqP5DSr+ldcxHP4Bnzu+lt97 vqOqgIx7yWCFX1pq8I/IzF3nwoEa1CZ7gZOJXyPTJfqHU2fxlpuALz9yD5jovAj3 f+MVIdyAJDgiV19JreGHdckM0njthXtyKykwxGiMxGmwE4Og4MIkrw== =uXKr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 05:21:28 2016 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 4C29E12DBDA for ; Wed, 20 Jul 2016 05:21:27 -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 7STh6Nt0lqf9 for ; Wed, 20 Jul 2016 05:21:25 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 4900F12D57B for ; Wed, 20 Jul 2016 05:21:25 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id n129so20919444vke.3 for ; Wed, 20 Jul 2016 05:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8Kwq3Ln1I8P0pRxVUxvoUVBZ2VfQ1eccZSWJQtOe8a0=; b=SkMNTRFv4tnt8yvEHYwnip3z2TGFIBeTLA1djZxQKBV8mQBx1/jYh7Dv9Bh3QjMEe1 Klch5w6+PmJf1xoDm309rVowZdXDQs7YDte+yzMPbXXVtQWSD//AgHl9aqOLk0nY+9xO 6b+TqGnSnHqN9c/4qrMpsYH5fAioMefylM7jPNi/WqQcNrhZ1JIR6SZkVMnxmiBaUhk7 2kILmAP7LNCxvKNSjZXk9+gUv5oJfZyb+7t0YC+vIIDunnJrwSbg2MliNFDGmEO06TM5 1nBslSLdWpOalaNgw1k2BXV4K6bNdvQ9gU7PpvcjuHBLKkmQfzBZ2hT1+nMiKpIM5afe rh8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8Kwq3Ln1I8P0pRxVUxvoUVBZ2VfQ1eccZSWJQtOe8a0=; b=m02mRw38YpqRHOvSAr/JlBjET023Ra+92rsLpHkBYTRYN3bYLklu8uYmBZWjCy2Az1 3glUlqm7EMx6Bd7vc6+YYI16i2rKXDp5XGqyoXs9Pil8nwgRQ1HNL1rlR+N/mD0Qpzq6 JNrM2kiWmsTdabzgjl4mCWpRRb7+cifUbVJstasTkRLD9J8vUiEayP4XHsySebZKyoyl Rqx6wMFROcElL737LqHzv9cgwFERtf806DP+UDdX8AMQ0KONFel+Gzs31Nqb7eVEbiwT SQbyJE6l1axXwZGtVmgdoNMtQD236cuI7H68Z4EULxacqM4ABPU/e5muMztx2HGDWZGR 5gcw== X-Gm-Message-State: ALyK8tL8O0tOUMmpc/pttPiwYwBp4g+u8UnVp/DR9Wb46DJMfBGGrroBJTgz+uUOFJYpnZ7iwK435PCLtVkpGQ== X-Received: by 10.159.32.163 with SMTP id 32mr23159061uaa.28.1469017284222; Wed, 20 Jul 2016 05:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Wed, 20 Jul 2016 05:21:23 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Wed, 20 Jul 2016 15:21:23 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary=94eb2c0b6d8a6526370538103d85 Archived-At: Subject: Re: [Roll] IETF 96 - Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:21:27 -0000 --94eb2c0b6d8a6526370538103d85 Content-Type: text/plain; charset=UTF-8 Hi, The slides were slightly updated (charter format), please find a new version: https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf Cheers 2016-07-20 14:00 GMT+03:00 Ines Robles : > Dear all, > > Please find the slides for the meeting today > > https://www.ietf.org/proceedings/96/slides/slides-96-roll-1.pdf > > Comments are welcome > > Thanks > > Peter and Ines > --94eb2c0b6d8a6526370538103d85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The slides were slightly updated (c= harter format), please find a new version:


Cheers

2016-07-20 14:00 GMT+03:00 Ines Robles = <mar= iainesrobles@googlemail.com>:
Dear all,

Please find the slides for= the meeting today


<= /div>
Comments are welcome

Thanks
Peter and Ines=C2=A0

--94eb2c0b6d8a6526370538103d85-- From nobody Wed Jul 20 05:27:12 2016 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 DEBBB12DBE5 for ; Wed, 20 Jul 2016 05:27:09 -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 1pyN6SNLTD3q for ; Wed, 20 Jul 2016 05:27:06 -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 732DD12DBE9 for ; Wed, 20 Jul 2016 05:27:04 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud3.xs4all.net with ESMTP id M0T21t00E4fjQrE010T2M3; Wed, 20 Jul 2016 14:27:02 +0200 Received: from 2001:67c:370:160:e10d:486f:762f:d6ec by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 20 Jul 2016 14:27:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Jul 2016 14:27:02 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (/YR2ojbzvjuxjd1mDTt5ZM5tsS1x7+iG) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] IETF 96 - Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:27:10 -0000 yeah, all same size. fantastic. peter Ines Robles schreef op 2016-07-20 14:21: > Hi, > > The slides were slightly updated (charter format), please find a new > version: > > https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf > > Cheers > > 2016-07-20 14:00 GMT+03:00 Ines Robles > : > >> Dear all, >> >> Please find the slides for the meeting today >> >> https://www.ietf.org/proceedings/96/slides/slides-96-roll-1.pdf >> >> Comments are welcome >> >> Thanks >> >> Peter and Ines > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Jul 20 08:02:15 2016 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 2437712D92F; Wed, 20 Jul 2016 08:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 6VF2h56sI2U2; Wed, 20 Jul 2016 08:01:33 -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 834B612D90D; Wed, 20 Jul 2016 08:01:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,394,1464645600"; d="scan'208,217";a="185362659" Received: from mail-lf0-f44.google.com ([209.85.215.44]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Jul 2016 17:01:29 +0200 Received: by mail-lf0-f44.google.com with SMTP id f93so40344697lfi.2; Wed, 20 Jul 2016 08:01:29 -0700 (PDT) X-Gm-Message-State: ALyK8tKLWyojbkuuysV0NbVg/YCIS21VEy40WjMGeK6CzBqSzxLxbTA1gFcFSYptbxXHKZeCZ7u6mYsfFOXH6w== X-Received: by 10.25.37.208 with SMTP id l199mr7827548lfl.41.1469026888797; Wed, 20 Jul 2016 08:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.9 with HTTP; Wed, 20 Jul 2016 08:01:09 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 20 Jul 2016 17:01:09 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, core , IETF ROLL , cose@ietf.org, lp-wan@ietf.org, "iot-dir@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "t2trg@irtf.org" Content-Type: multipart/alternative; boundary=001a11410ed4df55e40538127963 Archived-At: Subject: Re: [Roll] F-Interop info session @IETF96 - Monday 8.30-9-30pm - Charlottenburg I X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:01:38 -0000 --001a11410ed4df55e40538127963 Content-Type: text/plain; charset=UTF-8 All, Thanks for attending the F-Interop info session on Monday evening. As promised, you will find the slides at http://www.finterop.eu/images/presentations/F-Interop_IETF96.pdf. Thomas On Sun, Jul 17, 2016 at 5:22 PM, Thomas Watteyne wrote: > All, > > Please note that the info session is in the EVENING, i.e. 20.30. Some > people got confused. > > Also, the Meetecho team is arranging for remote participation [1] to be > possible, thanks to them! > > Thomas > > [1] http://ietf96.conf.meetecho.com/index.php/Remote_Participation > > On Thu, Jul 14, 2016 at 3:43 PM, Thomas Watteyne > wrote: > >> All, >> >> We are organizing an information meeting about F-Interop, an online >> platform for remote interoperability testing, IETF96 Monday 8.30-9.30pm, in >> Charlottenburg I. >> >> F-Interop (www.f-interop.eu) is a platform for online and remote >> conformance and interoperability testing, targeted at IoT-related standards >> (6TiSCH, 6LoWPAN, CoAP, RPL, ...) >> >> The purpose of this info session is to give you a technical overview of >> the platform, describe how the IETF community can use and contribute to it, >> and get feedback. >> >> The platform is built as part of the 2016-2018 F-Interop H2020 European >> project. As part of that project, we will have an open call for entities to >> contribute additional tools and test descriptions to the platform. Selected >> projects will be funded; we will explain the process during the info >> session as well. >> >> Looking forward to seeing you there, >> >> Thomas >> > > > > -- > _______________________________________ > > 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 > _______________________________________ > -- _______________________________________ 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 _______________________________________ --001a11410ed4df55e40538127963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Thanks for attending the F-Interop= info session on Monday evening. As promised, you will find the slides at= =C2=A0http://www.finterop.eu/images/presentations/F-Interop_IETF96.pdf.

On Sun, Jul 17, 2016 at 5:22 PM, Thomas Wattey= ne <thomas.watteyne@inria.fr> wrote:
All,

Please note that= the info session is in the EVENING, i.e. 20.30. Some people got confused.<= /div>

Also, the Meetecho team is arranging for remote pa= rticipation [1] to be possible, thanks to them!

Th= omas


On Thu, J= ul 14, 2016 at 3:43 PM, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
All,

We are organizing an information meeting ab= out F-Interop, an online platform for remote interoperability testing, IETF= 96 Monday 8.30-9.30pm, in Charlottenburg I.

F-Inte= rop (www.f-interop.eu= ) is a platform for online and remote conformance and interoperability = testing, targeted at IoT-related standards (6TiSCH, 6LoWPAN, CoAP, RPL, ...= )

The purpose of this info session is to give you = a technical overview of the platform, describe how the IETF community can u= se and contribute to it, and get feedback.

The pla= tform is built as part of the 2016-2018 F-Interop H2020 European project. A= s part of that project, we will have an open call for entities to contribut= e additional tools and test descriptions to the platform. Selected projects= will be funded; we will explain the process during the info session as wel= l.

Looking forward to seeing you there,
=
Thomas



--
<= div>
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________


--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a11410ed4df55e40538127963-- From nobody Wed Jul 20 08:11:53 2016 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 924A612D8C1 for ; Wed, 20 Jul 2016 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.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 vray-Fk6weKH for ; Wed, 20 Jul 2016 08:11:30 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC51912D98F for ; Wed, 20 Jul 2016 08:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TZap93wjfWCqpve/L+WzjIZ+HQQ4YCpk+SM20q/moXE=; b=SWL5BTi4opf4kMwA8jghdv2wJbbVhbRqv0XFg8EzAvup094ZDU16epoN8gaNWNBtPH0sbHzGDP8iIv00SNeobyX6i6V/v97OEq+RdFLC55cIcmQV+CqsYpUa7vHGOL4B25sZZ3UCdvrmgU/3t0rTSnTFhNTysILpKRw9Z767Dmg= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0086.outbound.protection.outlook.com [94.245.120.86]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-58-DaNgdMAhP8mriqxwnaJqfA-1; Wed, 20 Jul 2016 16:11:20 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 20 Jul 2016 15:11:06 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.021; Wed, 20 Jul 2016 15:11:06 +0000 From: Tim Chown To: "Pascal Thubert (pthubert)" Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4Scc3IsoEvP+qkam64X61wE+OqAfOpcAgABUa4CAAAmsAIAACPsAgAHOPYA= Date: Wed, 20 Jul 2016 15:11:06 +0000 Message-ID: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:160:7d03:333f:9868:5854] x-ms-office365-filtering-correlation-id: 945269d2-8eec-4492-a1cb-08d3b0b0129c x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:L5bbxqeWUpDrJwLQ8jK+pTm2oq4QdmBwYWq6TMXblWRH7zJsrIVQ44HnTKtzZ8CzE8DuD0kfEogQ/9g/vbyuQyKcSGfvWuvQfugJgYvJ+Fj57Sgp05SSof9nkFw3dcXMabF7CZK3Fjht8hxQUQK+h1ZafhO5dkVQ463rQIKnoRo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(189002)(8936002)(74482002)(3280700002)(586003)(8676002)(81156014)(7846002)(2950100001)(2900100001)(3660700001)(81166006)(76176999)(15975445007)(2906002)(93886004)(102836003)(110136002)(82746002)(6116002)(19580395003)(19580405001)(122556002)(7736002)(305945005)(11100500001)(97736004)(4326007)(77096005)(50226002)(92566002)(106356001)(101416001)(83716003)(105586002)(57306001)(5002640100001)(106116001)(50986999)(230783001)(36756003)(86362001)(87936001)(10400500002)(189998001)(33656002)(68736007)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <8290B68AB5D40B4AAA680371A4D3E482@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 15:11:06.0137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: DaNgdMAhP8mriqxwnaJqfA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:11:38 -0000 Hi Pascal, What RFC6554 (defining the RPL Type 3 RH) appears to say is: 1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself. 2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram. Which seems to suggest otherwise. Is it case 2 where insertion is happening rather than tunnelling? Case 1 is= at the source, which is compliant with RFC2460. Curious to know... Tim > On 19 Jul 2016, at 12:37, Pascal Thubert (pthubert) = wrote: >=20 > Actually Brian: >=20 > What is really needed here is not for routers but for the end hosts to ig= nore a HbH they are not programmed to recognize.=20 >=20 > The new text says all nodes on the path do. This seems to include the rec= eiver in which case we're good. >=20 > This will not change that most open implementations of RPL (all but a pro= totype implementing this draft) actually do header insertion. >=20 > Regards, >=20 > Pascal >=20 >> Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >>=20 >>> On 19/07/2016 22:31, Michael Richardson wrote: >>>=20 >>> Brian E Carpenter wrote: >>>>>=20 >>>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header= , RH3). >>>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such t= hat >>>>> the work in ROLL: >>>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ ca= n >>>>> know what kinds of things we need to compress. >>>>>=20 >>>>> A number of things are constrained by the need to always remove the >>>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>>> i.e. drop packet if you don't understand it. >>>>>=20 >>>>> As a result of the change in RFC2460bis, which says that intermediate= hosts >>>>> will in general not examine hop-by-hop options, but should just ignor= e >>>>> them, we can make certain simplications to the useofrplinfo document. >>>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>>=20 >>>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>>> intermediate forwarding nodes as described in [RFC2460]." >>>> which of course means that forwarding nodes MAY ignore HbH. >>>=20 >>> It's not what *I* want to do, it's what *I* can expect *others* to do. >>> So 7045 doesn't help me. >>=20 >> Well, it legitimizes a router simply ignoring a HbH header. Isn't that u= seful? >>=20 >>>=20 >>>> 00 - skip over this option and continue processing the header. >>>=20 >>> A type=3D10 option was allocated by RFC6553 >>>=20 >>> I think it was a mistake. >>=20 >> Agreed. >> Brian >>=20 >>> We have discussed changing it as we add >>> compression for 6553, 6554 and IPIP (which would be a flag day anyway). >>> This was considered undesireable, because there was a desire not to lea= k >>> our headers; that the internet would drop our packets if we screwed up. >>>=20 >>> But, it turns out that the internet won't drop out packets, so we might >>> as well optimize the situation so that if we don't need to remove our >>> Hob-by-Hop header, then we don't need extra IPIP headers. >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 20 09:24:18 2016 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 91F1D12D7FB; Wed, 20 Jul 2016 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 cASG7MgUgK5O; Wed, 20 Jul 2016 09:24:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE47312D821; Wed, 20 Jul 2016 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5067; q=dns/txt; s=iport; t=1469031851; x=1470241451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1MphemYKGSEpW5t37LK8UuxpOkzf3WbsLXBPFocoZQg=; b=JxKAh07bCusW+CgrxNVAE7ILYM8ApTHFKhQFW0/RFeWc2+LfmsKg5XyA KU1eD5KHeK0Vy93QIJL9DzV/zuGuc/+uWUo47/Bl8eKRopZENjRi89Gmw 6XO+gx6PtDloYRZUi53zQU+IVz1bGYLYzM5+kCUdP2eMj5d/DWokUjadF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgDDpI9X/4cNJK1dDoMxVnysQYwbg?= =?us-ascii?q?XoigkGDNwKBMzgUAQEBAQEBAWUnhFwBAQQBAQFsCwULAgEIGC4hBgslAgQOBYg?= =?us-ascii?q?WAw8IDrkbDYQIAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4CIJNgkOBWSSDL?= =?us-ascii?q?IIvBYgfhiWKLjQBhhKGMYIejzmIJYd6AR42gzg7bgGFYoFEAQEB?= X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="130870143" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 16:24:10 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6KGOAgL019193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 16:24:10 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 11:24:10 -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; Wed, 20 Jul 2016 11:24:10 -0500 From: "Pascal Thubert (pthubert)" To: Tim Chown Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4X59TqNb256fWESru62KIaaKWqAf4iWAgAAJrAD//7UpV4ACIboA///AmR8= Date: Wed, 20 Jul 2016 16:24:10 +0000 Message-ID: <87F2A4F0-7EFA-4898-BEEF-6CCC89670464@cisco.com> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:24:13 -0000 Hello Tim: The spec of the case that requires IP in IP (in effect the root relaying a = packet as opposed to sourcing it) was not followed by implementors.=20 People figured that the overhead for encapsulation limited the size of the = network to 2 or 3 hops.=20 This is now somewhat alleviated by the new 6LoRH compression schema. Thus a= first tentative implementation of Michael's draft in openWSN. But the architectural value vs. energy/ bandwidth cost is still hardly conv= incing for the world outside IETF.=20 Regards, Pascal > Le 20 juil. 2016 =E0 17:11, Tim Chown a =E9crit : >=20 > Hi Pascal, >=20 > What RFC6554 (defining the RPL Type 3 RH) appears to say is: >=20 > 1. If the SRH specifies the complete path from source to > destination, the router places the SRH directly in the datagram > itself. >=20 > 2. If the SRH only specifies a subset of the path from source to > destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and > places the SRH in the outer IPv6 header. Use of tunneling > ensures that the datagram is delivered unmodified and that ICMP > errors return to the source of the SRH rather than the source of > the original datagram. >=20 > Which seems to suggest otherwise. >=20 > Is it case 2 where insertion is happening rather than tunnelling? Case 1 = is at the source, which is compliant with RFC2460. Curious to know... >=20 > Tim >=20 >> On 19 Jul 2016, at 12:37, Pascal Thubert (pthubert) = wrote: >>=20 >> Actually Brian: >>=20 >> What is really needed here is not for routers but for the end hosts to i= gnore a HbH they are not programmed to recognize.=20 >>=20 >> The new text says all nodes on the path do. This seems to include the re= ceiver in which case we're good. >>=20 >> This will not change that most open implementations of RPL (all but a pr= ototype implementing this draft) actually do header insertion. >>=20 >> Regards, >>=20 >> Pascal >>=20 >>>> Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >>>>=20 >>>> On 19/07/2016 22:31, Michael Richardson wrote: >>>>=20 >>>> Brian E Carpenter wrote: >>>>>>=20 >>>>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Heade= r, RH3). >>>>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such = that >>>>>> the work in ROLL: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ c= an >>>>>> know what kinds of things we need to compress. >>>>>>=20 >>>>>> A number of things are constrained by the need to always remove the >>>>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>>>> i.e. drop packet if you don't understand it. >>>>>>=20 >>>>>> As a result of the change in RFC2460bis, which says that intermediat= e hosts >>>>>> will in general not examine hop-by-hop options, but should just igno= re >>>>>> them, we can make certain simplications to the useofrplinfo document= . >>>>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>>>=20 >>>>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>>>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>>>> intermediate forwarding nodes as described in [RFC2460]." >>>>> which of course means that forwarding nodes MAY ignore HbH. >>>>=20 >>>> It's not what *I* want to do, it's what *I* can expect *others* to do. >>>> So 7045 doesn't help me. >>>=20 >>> Well, it legitimizes a router simply ignoring a HbH header. Isn't that = useful? >>>=20 >>>>=20 >>>>> 00 - skip over this option and continue processing the header. >>>>=20 >>>> A type=3D10 option was allocated by RFC6553 >>>>=20 >>>> I think it was a mistake. >>>=20 >>> Agreed. >>> Brian >>>=20 >>>> We have discussed changing it as we add >>>> compression for 6553, 6554 and IPIP (which would be a flag day anyway)= . >>>> This was considered undesireable, because there was a desire not to le= ak >>>> our headers; that the internet would drop our packets if we screwed up= . >>>>=20 >>>> But, it turns out that the internet won't drop out packets, so we migh= t >>>> as well optimize the situation so that if we don't need to remove our >>>> Hob-by-Hop header, then we don't need extra IPIP headers. >>>>=20 >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> -=3D IPv6 IoT consulting =3D- >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Wed Jul 20 10:17:20 2016 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 12C5E12D83B; Wed, 20 Jul 2016 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 iXhCB47HDxD6; Wed, 20 Jul 2016 10:17:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC7712D7F9; Wed, 20 Jul 2016 10:17:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 66893200A5; Wed, 20 Jul 2016 13:26:43 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB823638D1; Wed, 20 Jul 2016 13:17:11 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6man@ietf.org, Brian E Carpenter Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 17:17:15 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> > intermediate forwarding nodes as described in [RFC2460]." >> > which of course means that forwarding nodes MAY ignore HbH. >> >> It's not what *I* want to do, it's what *I* can expect *others* to do. >> So 7045 doesn't help me. > Well, it legitimizes a router simply ignoring a HbH header. Isn't that > useful? It doesn't tell me what behaviour I can expect, just what I'm allowed to do myself. In RPL networks, we don't want to ignore that HbH header, we simply want to avoid having to go through conniptions to remove it. today, at ROLL, we went through some slides to explain the improvements that 2460bis "Note" does for us. Here are the link to the slides: The ROLL WG meeting we seemed to have consensus in the room to wait for rfc2460bis to progress, and to have a normative reference to it in useofrplinfo. I have merged the changes that were shown in the links I posted before: https://goo.gl/cxWkP5 this is a reference to an RFC diff between: draft-ietf-roll-useofrplinfo-06.txt and draft-richardson-roll-useofrplinfo-2460bis-00.txt I have merged the changes into draft-ietf-roll-useofrplinfo-07, so you can now see the changes directly in the datatracker. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4+yE4CLcPvd0N1lAQKaWggAg43wNScct9yBk9ree9dobIezBOIFVMQn BfklpkaPF2vdC46SvdN5YGeFyGAm9eDpEv/KCr72mN4a+6M/oBPv541+xJ2wqMYg tZ3sUE/u1zzv1MZa86XUUeT70LiqJMviHtarbZIq7ouA3mZuhxiDohC0fcfuzWMn s4oPsl7IJCYqfE08NBvubBcYc5T/NzFBC8IjLgXU6NHgsvo9yOoY22f7zIJln/J4 K91OKDPk3sIFVwAxZ5YIbAsry1K7SBXfo9fPg9yX7qNgnqmiFWATW9yqCVZYxeZe JnfxuXOgxOy09+1qRZMPrqVMnwXlJIrFr8fgh0t04kbX3xKTJh+cJA== =wSQ+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 10:25:08 2016 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 6D14C12D77F; Wed, 20 Jul 2016 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 a4FlMJbmgerX; Wed, 20 Jul 2016 10:24:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DF812D88E; Wed, 20 Jul 2016 10:24:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BC47200A5; Wed, 20 Jul 2016 13:34:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D65EB638D1; Wed, 20 Jul 2016 13:24:55 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, otroan@employees.org In-Reply-To: References: <26148.1468914385@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6man@ietf.org Subject: Re: [Roll] 2460bis - section 4.2 -- hop-by-hop option writeup. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 17:24:58 -0000 --=-=-= Content-Type: text/plain otroan@employees.org wrote: > I don't think we can do this in 2460bis. The option flags are also used > for the Destination options header. > There is anyway legacy implementations, meaning that new options cannot > reuse the space. Ah, I hadn't realized this. > For your particular problem, it sounds like you don't really want a > mandatory option, why not reclassify the RPL option instead of trying > to make 2460 fit the corner you've been painted into :-)). Okay, so I want to re-open this possibility as part of the flag day caused by deploying of 6LoRH. Specifically, about updating RFC6553 such that the Option code changes from 0x63 to 0x23. I think that this should be tied to deployment of 6LoRH. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4+z4oCLcPvd0N1lAQJZLgf+KbX5A4sOiIZ/b83AoEN/ElwfIE48teSf Qr9YUmJWnBaDTpSAm9eq/WX4jIyfF92NCDTzdFV11to+D8Yi/EjQlTwdVLFgzOH8 oqoRe5LjHpp9qNP6tsAMVylEpBoo95w9y3n6C/0kTk0cSokUQJP8PSGgqT0ejgYu jh/4tXo/q4iYRBGALGAnoHyANwzof1CXN1TeTZmmYQCJ7/XbwoNtTSGf5VChTb/A eTAqfq85F5Hru4LBz6jdWPlQvjL3huHbjcHBBC4ZQoqN0EZcTUNHlIaWi2GKVqfi zoq4ojKewbzCnibWrwOwbhk8ISdZbHgObvqctppCuk7/oG3jQbkMZw== =6bMa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 11:16:59 2016 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 EC10712D9F2; Wed, 20 Jul 2016 11:16:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160720181655.26509.61853.idtracker@ietfa.amsl.com> Date: Wed, 20 Jul 2016 11:16:55 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 18:16:56 -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-07.txt Pages : 29 Date : 2016-07-20 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-07 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 Wed Jul 20 14:08:37 2016 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 29F0D12D0AF for ; Wed, 20 Jul 2016 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 b8AsBTrL1-NS for ; Wed, 20 Jul 2016 14:08:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE9612B024 for ; Wed, 20 Jul 2016 14:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3001; q=dns/txt; s=iport; t=1469048914; x=1470258514; h=date:from:to:subject:message-id:mime-version; bh=gqOaccXEW6fKLDXmDhCKQrLo1CuyJ9m2STzDwuqXmkg=; b=j3Z/2h1E6qbCqfy9+QdEiwngRjKtNsVI6FS5N4pi622JMFXXDoHQGXEo QcNJkSINd53cRJivJ04FynXMt/+fOkP/yoHf/6ywngqzneXcnwuC91OG4 dqq7QCnctC6Gp8tPXv92SV+FyLsK9JL/58vlHtvG+a3aOcD5bFe7OqS0U 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgDM549X/5ldJa1dgz+6MYF7h1E4F?= =?us-ascii?q?AEBAQEBAQFlJ4UdezQFd4gVn2udSgsBAQEjjwOBAIUPBY8AhGSFQo5YCo85kCA?= =?us-ascii?q?eNoQTHIdZAQEB?= X-IronPort-AV: E=Sophos;i="5.28,396,1464652800"; d="scan'208";a="128275036" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 21:08:33 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6KL8XL1010186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 21:08:33 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6KL8WSX011924 for ; Wed, 20 Jul 2016 14:08:32 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6KL8WUb011923 for roll@ietf.org; Wed, 20 Jul 2016 14:08:32 -0700 Date: Wed, 20 Jul 2016 14:08:32 -0700 From: Toerless Eckert To: roll@ietf.org Message-ID: <20160720210832.GP7377@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Roll] Roll: multicast use-case X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 21:08:36 -0000 Interesting drafts about multicast in Roll. After the WG meeting, Carsten explained a bit more the use-case: Eg: existing building, can only effectively install networking via inexpensive 802.15.4 radio network. Need multicast because eg: lighting controller near RPL root wants to tell eg: 50 lights to change state. 50 unicast across 256 kbps link stats == visible delay issue. So, then comes in the discussion of bitstring based multicast, explicit (BIER) or "heuristic" (bloom filter). Nice. But IMHO no cigar: What i didn't realise is that the idea was to still to use normal "IP multicast (SSM possibly)" and the bitstring methods just underneath it, adopting how BIER is currently scoped in the BIER-WG. Now maybe i am overlooking some easier app design options, but here is how i see it: - I have 256 lights - I want to switch on/off eg: some 30 of them - To do this efficiently i need to first do a lot of signaling to tell those 30 lights: Pls. join this multicast group .. so that later on i can efficiently send you a command to turn on/off. - So ultimately i'd need to upfront assign a multicast group to every desired subset of lights, signal to every light the subset groups it is a member off, have to maintain on every last-hop forwarder the MLD member state for all these groups, and yeah, now i can start sending efficient multicast packets to the desired subsets. - And i can forget more interesting lighting effects because i'll never be able to have even a reasonable percentage of subset groups of all lights i could address. - So then i want these effects, and i start broadcasting packets to just every light, and the app-level of those packets will have a bitstring of which lights should act upon the packet. And we just created a whole useless level of complexity that had to be ignored because of IP multicast scale limits and repeated inside in the app layer. This is just silly. What IMHO we really need is to throw out IP multicast and just use end-to-end BIER: Sender sends BIER packet, every bit is a possible receiver. Apps don't like BITs ? NP, we come up with a simple control plane to replace eg: MLD that auto-assigns bits to every receiver and the sender just needs to send each packet to a list of receiver IP-addresses. Senders BIER library converts that list into bitstring. Oh, you still have some IP multicast apps ? Especially if those are meant for controllers (SSM), you can easily build a shim library on top of the BIER APIs to map them back to the BIER APIs. IMHO: In this app environment, putting BIER underneath IP multicast is like putting an electric battery&motor into a Ford model T. And then putting a dynamo at the wheels to generate electricity to charge the drivers iPhone. Maye this is more a discussion for 6tsch ? Not sure how these solution cakes get split up across the various WGs. Cheers Toerless From nobody Wed Jul 20 17:21:23 2016 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 B3A2612D8AE; Wed, 20 Jul 2016 17:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 7K31YqjT83jS; Wed, 20 Jul 2016 17:21:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9006C12D106; Wed, 20 Jul 2016 17:21:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35E5C200A3; Wed, 20 Jul 2016 20:30:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 79CF8638D1; Wed, 20 Jul 2016 20:21:14 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <6180.1469035031@obiwan.sandelman.ca> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> <6180.1469035031@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6man@ietf.org Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 00:21:18 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > today, at ROLL, we went through some slides to explain the improvements that > 2460bis "Note" does for us. Here are the link to the slides: https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf starting at slide 9. I will probably fix some minor typos and fill some missing labels to make it stand-alone -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5AVd4CLcPvd0N1lAQK/Jgf/dB4AIGy57vB6Y67wWVPFxXhWhCItRN6T RO4fURTiiXWv3k3Giir5vx8cPyixOG2S20e4JVKv9KEnAfgJT9BURo7eROIRfX91 LbjZHHEk2ojhSVyJFH9hJlqZGmhkJ6thAcQsRkRLAVP5ONeIkuoAfk6QbrgTvchn JWHlN3gAv4R3ga1S+zxtlGRFc/lnGdKsjhrfmhvy/axVDrgYpcpy0pm7pgJfkOEe ekmjAdzOsQIKxzhcqTreXnxT+vw6DhZPyYr2uxBlcXxeHLh3CqqdHoYTegv2T4wo pdeoaL0wP2rNE337oNVSQNh6xPu//vXsWkP6v/Jns4eLx8Q3jcuZEQ== =3JOZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 21:37:57 2016 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 E5E4612B02C for ; Wed, 20 Jul 2016 21:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 Ye6hlga8WDFb for ; Wed, 20 Jul 2016 21:37:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CEA12B03A for ; Wed, 20 Jul 2016 21:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4103; q=dns/txt; s=iport; t=1469075874; x=1470285474; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wpj6Ph38053y+z9P0H9GRLLBOpRqwkt5+uZ96DJ2Gs8=; b=LjXFov2qvCqU2pB1RbGLQf7r6fg31AWubLeDtAauhgGoSL+we4+Ql/GG BTtnioytDHozBKocnWqkTvGKVUGzJtQ5PvVSH94cJzchK92SlMUg60E7p l5ZXAnm75zI89ICJvbq492vQsPYjB4psk+Za330jXk5c6S3+O8S0d/4Lm s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQDRUJBX/4cNJK1dgz9WfLhhgXsih?= =?us-ascii?q?XgCgTU6EgEBAQEBAQFlJ4RdAQQBAQFsEAsCAQg1EScLJQIEExuIDQgOvSwBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXhmgW+EDDSDLIIvBY5EimEBjmWPOpAfA?= =?us-ascii?q?SUMI4NzbodYAQEB?= X-IronPort-AV: E=Sophos;i="5.28,397,1464652800"; d="scan'208";a="300357846" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 04:37:54 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6L4brhZ007609 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Jul 2016 04:37:53 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 23:37:53 -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; Wed, 20 Jul 2016 23:37:53 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Roll: multicast use-case Thread-Index: AQHR4srkVhivOrkpwUSt5CdcHFy7TqAiTbO5 Date: Thu, 21 Jul 2016 04:37:53 +0000 Message-ID: <9E5DF9FD-EBCF-4F71-826C-0B57D5B0979D@cisco.com> References: <20160720210832.GP7377@cisco.com> In-Reply-To: <20160720210832.GP7377@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Roll: multicast use-case X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 04:37:57 -0000 Thanks Toerless=20 In fact we have all the IPR for RPL BIER just missing time to write the dra= ft. Basically assign (the group and) bit offset at the same time as the sho= rt address and expose the bit string in DAO as opposed to IPv6 addresses. P= arents OR the bit strings from children in their own DAOs recursively. Bloom adds elasticity but does not change the concept. I have to go to the = patents but that's probably in there too since we were very aware of that m= odem. As of ROLL: We already have a draft for the dataplane missing the one for C= ontrol plane. Matter of finding time. At least we have a charter item : ) Regards, Pascal > Le 20 juil. 2016 =E0 23:08, Toerless Eckert (eckert) a= =E9crit : >=20 > Interesting drafts about multicast in Roll. After the WG meeting, Carste= n > explained a bit more the use-case: >=20 > Eg: existing building, can only effectively install networking via inexpe= nsive > 802.15.4 radio network. Need multicast because eg: lighting controller ne= ar RPL root > wants to tell eg: 50 lights to change state. 50 unicast across 256 kbps l= ink stats =3D=3D > visible delay issue. >=20 > So, then comes in the discussion of bitstring based multicast, explicit (= BIER) > or "heuristic" (bloom filter). Nice. But IMHO no cigar: >=20 > What i didn't realise is that the idea was to still to use normal > "IP multicast (SSM possibly)" and the bitstring methods just underneath i= t, > adopting how BIER is currently scoped in the BIER-WG. >=20 > Now maybe i am overlooking some easier app design options, but here is > how i see it: >=20 > - I have 256 lights > - I want to switch on/off eg: some 30 of them > - To do this efficiently i need to first do a lot of signaling to > tell those 30 lights: Pls. join this multicast group .. so that > later on i can efficiently send you a command to turn on/off. > - So ultimately i'd need to upfront assign a multicast group to every > desired subset of lights, signal to every light the subset groups it i= s > a member off, have to maintain on every last-hop forwarder the MLD > member state for all these groups, and yeah, now i can start sending > efficient multicast packets to the desired subsets. > - And i can forget more interesting lighting effects because i'll never = be able to have=20 > even a reasonable percentage of subset groups of all lights i could ad= dress. > - So then i want these effects, and i start broadcasting packets to > just every light, and the app-level of those packets will have a bitst= ring > of which lights should act upon the packet. And we just created a whol= e > useless level of complexity that had to be ignored because of IP > multicast scale limits and repeated inside in the app layer. >=20 > This is just silly. >=20 > What IMHO we really need is to throw out IP multicast and just use end-to= -end > BIER: Sender sends BIER packet, every bit is a possible receiver.=20 >=20 > Apps don't like BITs ? NP, we come up with a simple control plane to repl= ace eg: MLD > that auto-assigns bits to every receiver and the sender just needs to sen= d > each packet to a list of receiver IP-addresses. Senders BIER library conv= erts > that list into bitstring. >=20 > Oh, you still have some IP multicast apps ? Especially if those > are meant for controllers (SSM), you can easily build a shim library on t= op > of the BIER APIs to map them back to the BIER APIs. >=20 > IMHO: In this app environment, putting BIER underneath IP multicast is > like putting an electric battery&motor into a Ford model T. And then put= ting a > dynamo at the wheels to generate electricity to charge the drivers iPhone= .=20 >=20 > Maye this is more a discussion for 6tsch ? Not sure how these solution ca= kes get > split up across the various WGs. >=20 > Cheers > Toerless >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Jul 20 21:40:31 2016 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 3E5B212B02C for ; Wed, 20 Jul 2016 21:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 xuBF0O2pTzSN for ; Wed, 20 Jul 2016 21:40:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DADA12D7FD for ; Wed, 20 Jul 2016 21:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4601; q=dns/txt; s=iport; t=1469076028; x=1470285628; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iZEmSAYaA1pQNF0FQ8jcwtkvHmzpd97O1tyye8PMZis=; b=LQbqDhG+LQU0ZNhCucQTYMIj2KLoCKKtRjvcgdKnoNh7YxglTp8fSGIB zDeVnHQ7x9jBEmzl1r3g8XVWAOqtLIizo16k8CteXrAnMggQ9XzX3Mpsh aB6sHhCL/zVQkG4XfSTKebviF++QwJPlqbi2c23N/98mCkc2EmvM8PJJl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQBVUZBX/5NdJa1dgz9WfLhhgXsih?= =?us-ascii?q?XgCgTU6EgEBAQEBAQFlJ4RdAQQBAQFsEAsCAQg1EScLJQIEExuIDQgOvSwBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXhmgW+EDBcBARuDLIIvBY5EimEBjmWPO?= =?us-ascii?q?pAfASUEK4NzboYjgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.28,397,1464652800"; d="scan'208";a="298556539" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 04:40:27 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6L4eR29018660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Jul 2016 04:40:27 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; Wed, 20 Jul 2016 23:40:26 -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; Wed, 20 Jul 2016 23:40:26 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Roll: multicast use-case Thread-Index: AQHR4srkVhivOrkpwUSt5CdcHFy7TqAiTbO5gAAAt9w= Date: Thu, 21 Jul 2016 04:40:26 +0000 Message-ID: <641AEDC6-EBBD-4EA5-9EAA-185E76133B1A@cisco.com> References: <20160720210832.GP7377@cisco.com>, <9E5DF9FD-EBCF-4F71-826C-0B57D5B0979D@cisco.com> In-Reply-To: <9E5DF9FD-EBCF-4F71-826C-0B57D5B0979D@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Roll: multicast use-case X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 04:40:30 -0000 For clarity in the mail below the group is the index to the bitstring when = there are too many device for a single one... Not a mcast group! Regards, Pascal > Le 21 juil. 2016 =E0 06:38, Pascal Thubert (pthubert) a =E9crit : >=20 > Thanks Toerless=20 >=20 > In fact we have all the IPR for RPL BIER just missing time to write the d= raft. Basically assign (the group and) bit offset at the same time as the s= hort address and expose the bit string in DAO as opposed to IPv6 addresses.= Parents OR the bit strings from children in their own DAOs recursively. >=20 > Bloom adds elasticity but does not change the concept. I have to go to th= e patents but that's probably in there too since we were very aware of that= modem. >=20 > As of ROLL: We already have a draft for the dataplane missing the one for= Control plane. Matter of finding time. At least we have a charter item : ) >=20 >=20 > Regards, >=20 > Pascal >=20 >> Le 20 juil. 2016 =E0 23:08, Toerless Eckert (eckert) = a =E9crit : >>=20 >> Interesting drafts about multicast in Roll. After the WG meeting, Carst= en >> explained a bit more the use-case: >>=20 >> Eg: existing building, can only effectively install networking via inexp= ensive >> 802.15.4 radio network. Need multicast because eg: lighting controller n= ear RPL root >> wants to tell eg: 50 lights to change state. 50 unicast across 256 kbps = link stats =3D=3D >> visible delay issue. >>=20 >> So, then comes in the discussion of bitstring based multicast, explicit = (BIER) >> or "heuristic" (bloom filter). Nice. But IMHO no cigar: >>=20 >> What i didn't realise is that the idea was to still to use normal >> "IP multicast (SSM possibly)" and the bitstring methods just underneath = it, >> adopting how BIER is currently scoped in the BIER-WG. >>=20 >> Now maybe i am overlooking some easier app design options, but here is >> how i see it: >>=20 >> - I have 256 lights >> - I want to switch on/off eg: some 30 of them >> - To do this efficiently i need to first do a lot of signaling to >> tell those 30 lights: Pls. join this multicast group .. so that >> later on i can efficiently send you a command to turn on/off. >> - So ultimately i'd need to upfront assign a multicast group to every >> desired subset of lights, signal to every light the subset groups it i= s >> a member off, have to maintain on every last-hop forwarder the MLD >> member state for all these groups, and yeah, now i can start sending >> efficient multicast packets to the desired subsets. >> - And i can forget more interesting lighting effects because i'll never = be able to have=20 >> even a reasonable percentage of subset groups of all lights i could ad= dress. >> - So then i want these effects, and i start broadcasting packets to >> just every light, and the app-level of those packets will have a bitst= ring >> of which lights should act upon the packet. And we just created a whol= e >> useless level of complexity that had to be ignored because of IP >> multicast scale limits and repeated inside in the app layer. >>=20 >> This is just silly. >>=20 >> What IMHO we really need is to throw out IP multicast and just use end-t= o-end >> BIER: Sender sends BIER packet, every bit is a possible receiver.=20 >>=20 >> Apps don't like BITs ? NP, we come up with a simple control plane to rep= lace eg: MLD >> that auto-assigns bits to every receiver and the sender just needs to se= nd >> each packet to a list of receiver IP-addresses. Senders BIER library con= verts >> that list into bitstring. >>=20 >> Oh, you still have some IP multicast apps ? Especially if those >> are meant for controllers (SSM), you can easily build a shim library on = top >> of the BIER APIs to map them back to the BIER APIs. >>=20 >> IMHO: In this app environment, putting BIER underneath IP multicast is >> like putting an electric battery&motor into a Ford model T. And then pu= tting a >> dynamo at the wheels to generate electricity to charge the drivers iPhon= e.=20 >>=20 >> Maye this is more a discussion for 6tsch ? Not sure how these solution c= akes get >> split up across the various WGs. >>=20 >> Cheers >> Toerless >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Jul 20 22:09:23 2016 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 B2FD512D9FA; Wed, 20 Jul 2016 22:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 oOr2Jt-5m0C9; Wed, 20 Jul 2016 22:09:17 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8B712D9ED; Wed, 20 Jul 2016 22:09:16 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id E7E20FB8B8; Thu, 21 Jul 2016 07:09:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Gc-gMZjc0oI2; Thu, 21 Jul 2016 07:09:13 +0200 (CEST) X-Originating-IP: 109.45.2.165 Received: from nar-3.local (ip-109-45-2-165.web.vodafone.de [109.45.2.165]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id A7F21FB8AC; Thu, 21 Jul 2016 07:09:11 +0200 (CEST) Message-ID: <579058F8.1040701@tzi.org> Date: Thu, 21 Jul 2016 07:09:12 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tony Przygienda References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Routing Over Low power and Lossy networks , "bier@ietf.org" , draft-bergmann-bier-ccast@ietf.org Subject: Re: [Roll] [Bier] comments on draft-bergmann-bier-ccast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 05:09:20 -0000 Hi Tony, thanks for taking note of this draft. > Generally, not sure how it touches BIER specifically. It seems to > specify RPL extensions. Indeed. We used the "WG name" BIER in the draft at the time we submitted the first version because the BIER BOF was just happening and we weren't sure where this would end up. By now it is pretty clear this will end up in ROLL (if at all), but resubmitting the draft to create a new -00 just for a WG name change is confusing. > Yes, one could reuse the BIER bit mask to > propagate a BLOOM filter instead of a perfect mask @ the benefit of 'set > bit mask compression' vs. the cost of spurious transmissions as the > draft acknowledges where the degenerate case is a full broadcast. The > according BIER procedures/approach is nowhere to be found in the draft > though ... No, as we are indeed focusing on RPL. One very important thing we get from RPL is the rank, which allows us to avoid forwarding loops even though the individual routers are pretty much oblivious about the structure of the network (non-storing mode is based on source routes from the root of the destination-oriented directed acyclic graph, DODAG). So I wouldn't immediately know how to generalize the current approach to other underlying unicast routing protocols. But the use of bloom filters (instead of bitmaps) to identify a set of outgoing interfaces is probably extractable, if that is useful somewhere else. > As nit I didn't find in 6550 anything talking about "storing mode" so a > better reference is needed. Hmm, I find 81 places in there. (But Ccast is for non-storing mode.) Grüße, Carsten From nobody Wed Jul 20 22:45:14 2016 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 E60D512DA09; Wed, 20 Jul 2016 22:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 kcNQPPaul8Cw; Wed, 20 Jul 2016 22:45:07 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 F0B3612D10F; Wed, 20 Jul 2016 22:45:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x25so38360308qtx.2; Wed, 20 Jul 2016 22:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YV1eL83sudldoG/YW5MFapxurd2DdI1U048XUMJzGe4=; b=UrB7i5Er0gnxt69/OgqEw/MFMu/ifmKmKbZNrPP/jpzp5gjOp9kt7BktDcSq4dVRJO u80N45drZe0Mh0a0kTDcmV/7OyldlPv2ZenvyTfe2SV+73H0p6mwHBjZJP6jR1kFcwVi jEADfAxt+uYjFKV/0ywxroxtuu/eC6LqrjBd/9iCAHQ6QbxMHYL0ELp2VTtQKm0f+Qnl QzNv+ZNYIYirnMr3hfnzN+sn26/dBfUCjjby9B5Rx1xTt4mFf3Ae/kaY1FxN1035PQBh bjvBc7i2mXZLDJDlK2us7td/CiZDeoAHJmLavcYkGK/wa9uBING4x14hTNw22lkhp6C6 pPsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YV1eL83sudldoG/YW5MFapxurd2DdI1U048XUMJzGe4=; b=OC1zjUJfBIMxjNgbVe66R9stiageDmj60Riua87wRwKWQ2LQmFZF4c+zjgY0Pjbbfg RvFLNmEmu8DtorTrtp8tVDaBfHi15bmrqgYMu9mN41qi0RQbbZBg9vdV+gOpor5x9Q2J oUP51pyd9vGFFWblxn65+ijI08ySTU6rI5ZVaym8u5O4ZHZP5M9o/J/0xWMs0X7QChnK g/UDgS+os1DPX1dcgEloe3oVwafC58Q6FvbWino6hTGn23xBjQpqKkTtRJBRz3KUojtT 5/Onm4KkAelEv4RxiH3ORuTiW/8gjbmpD4tIEXkCO9MHDl2uc9pEUQw85X8lI9UTiZmP Rpbg== X-Gm-Message-State: ALyK8tICdGfespxkT+KcVNvFyun6NYCitEELQceL2VwnNpAUwkmhtiD1GfT2Gcv3yFHY+Q== X-Received: by 10.200.49.203 with SMTP id i11mr77613247qte.40.1469079906098; Wed, 20 Jul 2016 22:45:06 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o84sm3436798qke.38.2016.07.20.22.45.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 22:45:05 -0700 (PDT) To: Michael Richardson , roll@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> <6180.1469035031@obiwan.sandelman.ca> <2070.1469060474@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Jul 2016 17:45:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2070.1469060474@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man@ietf.org Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 05:45:09 -0000 On 21/07/2016 12:21, Michael Richardson wrote: > > Michael Richardson wrote: > > today, at ROLL, we went through some slides to explain the improvements that > > 2460bis "Note" does for us. Here are the link to the slides: > > https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf > starting at slide 9. > I will probably fix some minor typos and fill some missing labels > to make it stand-alone Again, I'm OK with the "Note" as a compromise to get us to Internet Standard. Without the "Note" the compromise breaks. Remember, for Internet Standard we are focussed on proven Internet-wide interoperability. Once that's done I think we should circle around again and look seriously at this and other "local use" issues. What should we say on top of Internet-wide standard about local use? We have a clear local use mechanism for DSCPs. We argued through the same issue for the latest revision of the flow label standard. For that matter, ULAs and NPTv6 also touch local use issues. I think it's a future work item after shipping 2460bis. From nobody Thu Jul 21 01:32:44 2016 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 0CDA112B02A for ; Thu, 21 Jul 2016 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 whKKH-6i_sNb for ; Thu, 21 Jul 2016 01:32:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA16712DBDE for ; Thu, 21 Jul 2016 01:32:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FD57200A3; Thu, 21 Jul 2016 04:42:13 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AED11638D1; Thu, 21 Jul 2016 04:32:39 -0400 (EDT) From: Michael Richardson To: paduffy@cisco.com, Routing Over Low power and Lossy networks In-Reply-To: References: <4193.1468934971@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] [6lo] privacy enhanced l2 addresses and parent selection in ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 08:32:43 -0000 --=-=-= Content-Type: text/plain {following up to roll only} Paul Duffy wrote: > On 7/19/2016 3:29 PM, Michael Richardson wrote: >> I was thinking about the dhcpv6 process. In order to do it in a >> route-over >> mesh, the route-over mesh needs to be up in order to get traffic to the >> DHCPv6 server. That means that the DAG has been formed using EUI-64 >> derived >> link local addresses. > Confirming. Assuming non storing RPL ... are you thinking the LBR is > maintaining the DAG with link local addresses? No, I'm not. I'm thinking that it maintains it wants to ultimately record using GUA addresses which are derived from 2-byte short link-layer addresses. Giving an example from my test setup: parent with (ethernet, not 802.15.4 EUI48 of 10:00:00:64:64:23) parent# ip -6 route show 2001:db8:1:0:1200:ff:fe66:6602 via fe80::1000:ff:fe66:6602 dev eth1 src 2001:db8:1:0:1200:ff:fe64:6423 metric 1024 child with (ethernet, not 802.15.4 EUI48 of 10:00:00:66:66:02) child# ip -6 route show 2001:db8:1::/48 via fe80::1000:ff:fe64:6423 dev eth1 src 2001:db8:1:0:1200:ff:fe66:6602 metric 1024 (this is a non-grounded DODAG, so no default route, just a route to the prefix announced) I would expect a non-storing implementation (which I don't have yet) to look something like this on the parent: dagroot# ip -6 route show 2001:db8:1:0:1200:ff:fe66:6602 via fe80::1000:ff:fe66:6602, 2001:db8:1:0:1000:ff:fe66:7702, 2001:db8:1:0:1000:ff:fe88:9902 dev eth1 src 2001:db8:1:0:1200:ff:fe64:6423 metric 1024 The point is that once "parent" gets itself a 2-byte short address, and generates some new LL and GUA addresses, I would expect this to look like: parent# ip -6 route show 2001:db8:1::6602 via fe80::6602 dev eth1 src 2001:db8:1::6423 metric 1024 child# ip -6 route show 2001:db8:1::/48 via fe80::6423 dev eth1 src 2001:db8:1::6602 metric 1024 So I'm asking if we need to do something to *encourage* this transition, or the trickle refresh is enough; to get the child to pick the short-form of the parent, we might have to consider the short form "better" from a parent selection point of view. That would be a parent change, and that might trigger unnecessary DAOs, yet this is not actually a parent change. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5CIpYCLcPvd0N1lAQJj0AgAhYmfHOf59uPjaTL7QuZJZBGy0b8Jv40V 6x+03E0tY3JaahsZFPP2xzJcMvBk7p/4bkRU6gLKfSF00dJSBljtj2tLxVNAdU69 ox9PXYy0XetnHoRTpIfZc4B2cd/FL1o9wN5IRiin2Yaq1CzDsXrFlQmVRmnYtSmf A46F5gsTCPWRr8kELORA1qR4IfXgf6TAXPwiAy8Sg0KW3zHC4/HDk0VbYhoezG8o ffJTRES4WPktuY9SKAbNLpz5F7da2a0e5iZpE/HZSaxOXg8rBgCO6h5VAXblr+aU uFsdT0hZ/QMvCcRc6Czf0ploZTMCV+s/KvvxWO8piOoslCKu29NARg== =JlJq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 21 02:13:26 2016 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 2DC2F12DC31; Thu, 21 Jul 2016 02:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 Cp8WyvhIEIf1; Thu, 21 Jul 2016 02:13:21 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D7112DC1D; Thu, 21 Jul 2016 02:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2949; q=dns/txt; s=iport; t=1469092400; x=1470302000; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=iLBfh8trm7HkS//itFtcC2f/j9V9Uu/dURaARygFHbI=; b=mkPHpdBcVEgo1OjyBC5X2y7Bue5bQUkwIqE3B+Ljk/j9FdcW10vC3Jv/ kYIRyI13uwhDEgouvUof1HxZyEAln5IQWEo40jXCQmM8/JVE0+7nRHr6g uLWy3dVUsPbGx+BHzTUTbcwJoQXnkPZ7Q0jR9FdGZxls/YrL7tK43QVcC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAwDqkZBX/5FdJa1TCoM/Vny4ZIF7I?= =?us-ascii?q?oV4AoEsOBQBAQEBAQEBZSdBDgGEDQEFAQEwATsLEAsYCSUPBRM2E4gwDr00AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBFwWJdIEDhBgEg1CCLwWODHWEPIVpjmEKjzqQI?= =?us-ascii?q?R42hBMcMoRagTqBRAEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="299657293" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 09:13:19 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6L9DJni013287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 09:13:19 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6L9DIrJ022474; Thu, 21 Jul 2016 02:13:18 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6L9DIoO022473; Thu, 21 Jul 2016 02:13:18 -0700 Date: Thu, 21 Jul 2016 02:13:18 -0700 From: Toerless Eckert To: Routing Over Low power and Lossy networks Message-ID: <20160721091318.GA21876@cisco.com> References: <579058F8.1040701@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <579058F8.1040701@tzi.org> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "bier@ietf.org" , draft-bergmann-bier-ccast@ietf.org, Tony Przygienda Subject: Re: [Roll] [Bier] comments on draft-bergmann-bier-ccast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:13:24 -0000 Thinking more of it (fun to analyse ;-): Without having done the math, i'd suspect this might be very efficient in very large networks for small-receiver-sets. Aka: 2048 NFER/receivers, 64 bits bitstring, max normal number of receivers ca. 16 for a packet. This could be very efficient in very large networks for "small-receiver-set". Aka: 2048 BFER/receivers. Maybe typically 16 receivers. This is not 100% tied to RPL. Consider a data-center with 100,000 VMs, with thousands of 'vlans', each hosting a typically a quite limited number of VMs. Instead of creating per-VLAN flood-state across the DC (which AFAIK gets complicated with all the overlay options involved), you could simply use maybe hmm... 256 ? bits bitstring. You need spanning tree forwarding (no redundancy). And you need some logic figuring out the intermediate interfaces in the bitstring. In RPL, the root does this. In a DC this could be more tricky. On Thu, Jul 21, 2016 at 07:09:12AM +0200, Carsten Bormann wrote: > Hi Tony, > > thanks for taking note of this draft. > > > Generally, not sure how it touches BIER specifically. It seems to > > specify RPL extensions. > > Indeed. We used the "WG name" BIER in the draft at the time we submitted > the first version because the BIER BOF was just happening and we weren't > sure where this would end up. By now it is pretty clear this will end > up in ROLL (if at all), but resubmitting the draft to create a new -00 > just for a WG name change is confusing. > > > Yes, one could reuse the BIER bit mask to > > propagate a BLOOM filter instead of a perfect mask @ the benefit of 'set > > bit mask compression' vs. the cost of spurious transmissions as the > > draft acknowledges where the degenerate case is a full broadcast. The > > according BIER procedures/approach is nowhere to be found in the draft > > though ... > > No, as we are indeed focusing on RPL. > > One very important thing we get from RPL is the rank, which allows us to > avoid forwarding loops even though the individual routers are pretty > much oblivious about the structure of the network (non-storing mode is > based on source routes from the root of the destination-oriented > directed acyclic graph, DODAG). So I wouldn't immediately know how to > generalize the current approach to other underlying unicast routing > protocols. But the use of bloom filters (instead of bitmaps) to > identify a set of outgoing interfaces is probably extractable, if that > is useful somewhere else. > > > As nit I didn't find in 6550 anything talking about "storing mode" so a > > better reference is needed. > > Hmm, I find 81 places in there. (But Ccast is for non-storing mode.) > > Gre, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Jul 21 02:37:27 2016 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 E09CB12D10B for ; Thu, 21 Jul 2016 02:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 EzxRTM8zc-Nm for ; Thu, 21 Jul 2016 02:37:25 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 EE07F12B004 for ; Thu, 21 Jul 2016 02:37:24 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id q128so15625687wma.1 for ; Thu, 21 Jul 2016 02:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=Nx05hhGUefhg+GAgk69CVEv/hf4CWM6jXjkW8KkbLaw=; b=QxXtgI0xJwgyn6hYYKR0F/uTowyq+eKYJ4q5vzV6ST+mfORnILoV7nTfEOwObB9yMy /iZ9RkTikyFuh4H6kpGBn/EbGXownC/DH8dWuarBVfnQgVBtFeM2IFlYtCART4GPbsTW zceSlKd0z1PLNhOdMFu6vBBT3i4qkAEDwjsM4uIWJOWMdVfenrh3Wuf1w80RCKRDoYac QgXYlauK0K5MrOtkmHS9MOS8pezRidavRgM0DHQ3s3T/nSBjrzNgwSfLGlzIVlriE/hD I3pceavjLnweSzAbnVgfUXxhRLads8+xtgPt03otVfotNFzjqy8kIpx51RwmtJlSzUhx KTKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=Nx05hhGUefhg+GAgk69CVEv/hf4CWM6jXjkW8KkbLaw=; b=BQHdk8Ed1+4R+NW3ukOKtnpTecK3F5r43zi0gKoZTq9DCzPooEkswUSuXbGXRqRpBJ 2/mcU6VBzrWDTdyMTdy9HbeYImyK5VfkU+swFjn0TZV2aUS7zk1aQkgPU/brG5Ret+ug WjiIKshfVDiriqzt+MjTu+LR+ohwc1QJYX0Nvl+GOfjnOU9XEtH8Qt/93KqttzhrtF4B ND6uR2E8vXWbCaa+2t3oea8i/sbo1Bqf23FRwGWYrqB1dOefZEwqTav7Oujyf1JBdiYu 3pd51oek2NVdQlCvKRch6iwkte6u+rFg5Yp0kxXtRKZSSR+1G7ifkiZPV1pBj1J3uo62 xrMQ== X-Gm-Message-State: ALyK8tKCEUIz2BywhGv75ib1SVtc3xHJqceuC1XmIayiZW9nyytCb0t1pgxbKPqmpEDyfg== X-Received: by 10.28.10.21 with SMTP id 21mr4879439wmk.3.1469093843288; Thu, 21 Jul 2016 02:37:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:e4da:511d:337:a3de? ([2001:67c:370:176:e4da:511d:337:a3de]) by smtp.gmail.com with ESMTPSA id w129sm2553568wmd.9.2016.07.21.02.37.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 02:37:22 -0700 (PDT) From: Rahul Jadhav Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 21 Jul 2016 11:37:21 +0200 To: roll@ietf.org, Carsten Bormann Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:37:27 -0000 In general the tone in ROLL WG seems to be in favor of non-storing mode = of operation =E2=80=A6 To this effect, Carsten even made a statement = yesterday =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D while = presenting his draft on constrained cast. I don=E2=80=99t truly understand on why non-storing mode is the de-facto = mode favoured=E2=80=A6 (quite possible that this is already discussed on = WG before but i could not find a ref!) My point is, There seems to be an obvious design limitation with regards to = Non-storing mode in context to multi hop networks=E2=80=A6. i.e. if the = number of hops goes several tens of hops (as mentioned in = ami-applicability draft), then the IP header bulges because of the = source routing header(SRH). Even with the latest proposals on = compressing the SRH, the overhead per packet is still =E2=80=9Ctoo=E2=80=9D= significant considering for e.g. a 20 hops networks. Use of non-storing = mode will result in significant increase in fragmentation which is not = desirable in LLNs. i understand that the non-storing mode significantly reduces the = memory/complexity requirements=E2=80=A6 but the trade-off is now between = cost and technical infeasibility! Also, all the major open sources (Contiki, RiOT, unstrung) seems to have = adopted storing-mode first =E2=80=A6=20 Thanks, Rahul= From nobody Thu Jul 21 02:52:26 2016 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 6014C12DA12 for ; Thu, 21 Jul 2016 02:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 581DN5Nb0kYy for ; Thu, 21 Jul 2016 02:52:22 -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 7944F12B004 for ; Thu, 21 Jul 2016 02:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1777; q=dns/txt; s=iport; t=1469094742; x=1470304342; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=93QsLpAiiqzID/AsNq8RA5l/mWHbwWO+yh1RrZL1bFM=; b=WMB/is5EOsT7DnBY5qWFHPAHr62A13NlQS3TJDrWXffmkLVzzPdBuCzd Q8f5rfVRP/AX47Aettd3XGvcclW6jk+l2AjEDziZzDR8286E0xJmbDcaA YJmgkWPUoquORAlObi1mdbec9pqjALtHy5R5P2P7MdSF2efUpL/sNCgNz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAwANmpBX/4wNJK1dgz9WfLhkgXsih?= =?us-ascii?q?XgCgSw4FAEBAQEBAQFlJ0EOAYQMAQEEAQEBODQLBQsLGAklDwUTNhOIKAgOvTw?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp3ihsFjwGKJY5hCo86kCEeNoQTHDKEW?= =?us-ascii?q?oJ+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="131888398" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 09:52:21 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6L9qLqr023465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 09:52:21 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6L9qKSV024471; Thu, 21 Jul 2016 02:52:20 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6L9qK7A024470; Thu, 21 Jul 2016 02:52:20 -0700 Date: Thu, 21 Jul 2016 02:52:20 -0700 From: Toerless Eckert To: Routing Over Low power and Lossy networks Message-ID: <20160721095220.GT7377@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:52:24 -0000 On Thu, Jul 21, 2016 at 11:37:21AM +0200, Rahul Jadhav wrote: > In general the tone in ROLL WG seems to be in favor of non-storing mode of operation ??? To this effect, Carsten even made a statement yesterday ???Storing mode doesn???t exist??? while presenting his draft on constrained cast. > > I don???t truly understand on why non-storing mode is the de-facto mode favoured??? (quite possible that this is already discussed on WG before but i could not find a ref!) An eample of the smallest RPL topology in which storing mode is seen infeasible would be nice. > My point is, > There seems to be an obvious design limitation with regards to Non-storing mode in context to multi hop networks???. i.e. if the number of hops goes several tens of hops (as mentioned in ami-applicability draft), then the IP header bulges because of the source routing header(SRH). Even with the latest proposals on compressing the SRH, the overhead per packet is still ???too??? significant considering for e.g. a 20 hops networks. Use of non-storing mode will result in significant increase in fragmentation which is not desirable in LLNs. > > i understand that the non-storing mode significantly reduces the memory/complexity requirements??? but the trade-off is now between cost and technical infeasibility! > The bloom filter comes to mind as a way to compress the SRH. Unicast is just a special case of small group multicast ;-) Cheers Toerless > Also, all the major open sources (Contiki, RiOT, unstrung) seems to have adopted storing-mode first ??? > > Thanks, > Rahul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Jul 21 02:55:13 2016 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 5886B12DC25 for ; Thu, 21 Jul 2016 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ain7TfidHaUs for ; Thu, 21 Jul 2016 02:55:10 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE97A12D9CE for ; Thu, 21 Jul 2016 02:55:03 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:7099:717a:b90a:c81f]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 43F04172098; Thu, 21 Jul 2016 11:55:01 +0200 (CEST) Message-ID: <57909BF2.6070100@tzi.org> Date: Thu, 21 Jul 2016 11:54:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Rahul Jadhav References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:55:12 -0000 Rahul Jadhav wrote: > In general the tone in ROLL WG seems to be in favor of non-storing mode of operation … To this effect, Carsten even made a statement yesterday “Storing mode doesn’t exist” while presenting his draft on constrained cast. > > I don’t truly understand on why non-storing mode is the de-facto mode favoured… (quite possible that this is already discussed on WG before but i could not find a ref!) It is not really the favored mode. It just happens the other mode is fatally broken. Storing mode presumes infinite space at each router, or perfect knowledge that your topology will never cause you to exceed that space, or that each router is expendable and can rescind at any point in time when its state space is exhausted (with the resulting massive instability because that rescinding will cause the next router to fall over). Until we advance more on the hybrid approach, storing mode unfortunately doesn't exist. (I'd like to learn more about your 20-hop networks, but as I hinted, bloom filters might help there, too.) Grüße, Carsten From nobody Thu Jul 21 03:09:52 2016 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 217F112DC92 for ; Thu, 21 Jul 2016 03:09:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 1ZZHl6inFh0r for ; Thu, 21 Jul 2016 03:09:49 -0700 (PDT) Received: from mail.stillroot.org (mail.stillroot.org [176.9.132.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89212DC89 for ; Thu, 21 Jul 2016 03:09:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.stillroot.org (Postfix) with ESMTP id DE51D4202C; Thu, 21 Jul 2016 12:09:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ba.stillroot.org Received: from mail.stillroot.org ([127.0.0.1]) by localhost (mail.stillroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_SjKQmhAhWn; Thu, 21 Jul 2016 12:09:34 +0200 (CEST) Received: from hobbykeller.org (dhcp-b132.meeting.ietf.org [31.133.177.50]) by mail.stillroot.org (Postfix) with ESMTPSA id 9E1A442028; Thu, 21 Jul 2016 12:09:33 +0200 (CEST) Date: Thu, 21 Jul 2016 12:09:03 +0200 From: Oleg Hahm To: Routing Over Low power and Lossy networks Message-ID: <20160721100903.GF13517@hobbykeller.org> References: <57909BF2.6070100@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w/VI3ydZO+RcZ3Ux" Content-Disposition: inline In-Reply-To: <57909BF2.6070100@tzi.org> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:09:51 -0000 --w/VI3ydZO+RcZ3Ux Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Carsten! On Thu, Jul 21, 2016 at 11:54:58AM +0200, Carsten Bormann wrote: > Storing mode presumes infinite space at each router, or perfect > knowledge that your topology will never cause you to exceed that space, > or that each router is expendable and can rescind at any point in time > when its state space is exhausted (with the resulting massive > instability because that rescinding will cause the next router to fall > over). Two questions: 1.) Don't we have a similar problem for ND? Without prior knowledge about the network's density and assuming that IP addresses for a particular link-layer are *not* derived from the L2 address, one needs infinite space for the neighbor cache. 2.) Doesn't need a RPL root node also require infinite space without prior knowledge of your network size? If you know the number of nodes in your network than this can also serve as an upper bound for the FIB also in storing mode. (Sure, this might not be suitable for class devices in big networks.) Cheers, Oleg --w/VI3ydZO+RcZ3Ux Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXkJ84AAoJEItjklUqsoG2EH4P/RwuCCjCpN0zfEUKpBbvS4b7 74ZtpzPOeO2oA2CFwVDgatIY2QvlT8ifgHvwihL/1iVGemnrtN8hsamp3Vg+bPaA 7HPpNGrKnk2D1PRIA+wwANePWQp2TY0iTjx2puWdpbPZuvhLFNpyS5ZBWHW/8DaS bV+jQfaWvpk5OO9zulF3+2OPdnpsViWqGXfe3VCQZdY/baJOmhlh7p6vcYUTGIOe t27yRQFUzDdqRZRBwnk/5S5lqpm+5fAYHAmtgNXyEtY3ixhSB6eOOa/xkGJYUcOr XROoxCZwPAQRNFMx24FaEo0TYgSeO7utwzk/0cUYD8DlzNWJj4ImL0iemwbST2gb +hlpiNtyIS7tUp+kpUA5qBtX5pveRuiRb4nFTRFhRsr1GatyP5WpyTJKYNF37EYc 3KJmkoWddUQjYZm0GsXbCtCKUS2BzoMaqU/Faq9znAHXj87DWZja0ju5rZr/y/66 QzIDjhZvbtWB6cmj57AO+H0jtUzDPQBC2w1TB4Hi6WO9eUmzkpHUo6e63nw/V/QC LCGxpwSMuGQ2QB9nTckJEN7dZzt55WQcAmcWRx1/Xjgu7oUDKFb6WZc5zK0dCPI3 xn2Gevlcjkr7iTagPjQ+sMcKuXNUR8hgTlFbmR/yYpeQ8yTH/RyuHFdP5QpY6mrI vRz5OGi9l6dKYMJj8q5n =Rhir -----END PGP SIGNATURE----- --w/VI3ydZO+RcZ3Ux-- From nobody Thu Jul 21 03:29:32 2016 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 BEBF012DC2D for ; Thu, 21 Jul 2016 03:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, 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 2IRqMsatrGB9 for ; Thu, 21 Jul 2016 03:29:29 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 C886612DCA2 for ; Thu, 21 Jul 2016 03:28:55 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f65so17033573wmi.0 for ; Thu, 21 Jul 2016 03:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=kSX1R8uNfdBB2VoZYR4aJ8nu+NGP3Cvz3mh0yuiqTCE=; b=vGEnSONbE/NxIUSimW5TuCXkI1/bFS5DgJw6sA8iv7FeTuKbXGEfd94m2Vv8QphJyZ uxOLF1vRtZDYrJ7hW2q4fX+G2q27Aa0buroxNjha3W5cTSxK2sitr0j4YP/8aqNxFUdR 9DeOS0bI6lpo5QkSPtMbcELytX9m66NQk8ktTK375gWhOFP4QK+PJMEvW4frNoCAsddU i7GloG5DhDP7t2KoM2tOZNisVzvx+uT3g848zghUH6hkxQZOy/s0AHFHO9Armco+hbw5 8ZqqeaqvpYyfxwnfrQx6aiUF6BjGJZMM48qOT/IgKjQla35BMPp1aA5meN0iscTw354p ABsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=kSX1R8uNfdBB2VoZYR4aJ8nu+NGP3Cvz3mh0yuiqTCE=; b=Jw252z1Zr75l0CmxwUx6McOrIKoTmYpoC5fOjYj+V4M/YJhvI1eRbBJRvDo9uawEPF rtPn/95z3/1AMGIEm4B7wF85P0hb8YqKHWhYiGx2kBFFLVc7Lb07EHoh7EkG50W8DQhB bZKAQc5kiD1fBIqOzX+KUY4++5DP48P/aywiSuII8weAcZ4I7usanwpsgdNnNLCQ0Y21 xDlzhvkm7GvQgiDi5j7ZJdGO/EiMTqoDVR74/3JsVERfhXZn1qWNxgx9Md8b99I/0c5k W7VM/Taxtg6zHJlxy0BPu3nAzqW44m1+oAWLfPpstjKVT59NYyCuWph6Q3/V+e3VW2Mg jVrw== X-Gm-Message-State: ALyK8tLw7LSZw7fqItWMU+6pRDl0ex7UgFbLbIbqf23LHV15wHhCM3uHNh+6HrN0zaXvZwOQAo2Htwu/5I4DOQ== MIME-Version: 1.0 X-Received: by 10.28.196.136 with SMTP id u130mr15388679wmf.83.1469096934073; Thu, 21 Jul 2016 03:28:54 -0700 (PDT) Received: by 10.194.173.74 with HTTP; Thu, 21 Jul 2016 03:28:53 -0700 (PDT) Received: by 10.194.173.74 with HTTP; Thu, 21 Jul 2016 03:28:53 -0700 (PDT) In-Reply-To: <57909BF2.6070100@tzi.org> References: <57909BF2.6070100@tzi.org> Date: Thu, 21 Jul 2016 12:28:53 +0200 Message-ID: From: =?UTF-8?Q?Cenk_G=C3=BCndogan?= To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=94eb2c192e74e56bb1053822c851 Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:29:31 -0000 --94eb2c192e74e56bb1053822c851 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 21.07.2016 11:55 schrieb "Carsten Bormann" : > > Rahul Jadhav wrote: > > In general the tone in ROLL WG seems to be in favor of non-storing mode of operation =E2=80=A6 To this effect, Carsten even made a statement yester= day =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D while presenting his d= raft on constrained cast. > > > > I don=E2=80=99t truly understand on why non-storing mode is the de-fact= o mode favoured=E2=80=A6 (quite possible that this is already discussed on WG befo= re but i could not find a ref!) > > It is not really the favored mode. > > It just happens the other mode is fatally broken. I wouldn't mark the storing mode as ultimately broken. It works, but it does not scale well. If you have a use case for small-sized / sparse topologies, then there should be enough space available in each nodes' rib/fib to store the (destination;next-hop) pairs of the sub-DODAG. Related to this: is there actually any work that aims to reduce the space needed for (destination;next-hop) pairs? For simple RPL only networks e.g. I can imagine that based on the DODAG Id some prefixes could be dropped / assumed when doing a longest prefix match. > Storing mode presumes infinite space at each router, or perfect > knowledge that your topology will never cause you to exceed that space, > or that each router is expendable and can rescind at any point in time > when its state space is exhausted (with the resulting massive > instability because that rescinding will cause the next router to fall > over). There is still the possibility to request DAO-ACKs and choose e.g. another parent if the ACK has a negative result (could not store DAO). Whether this approach is good or bad is of course another question. But yeah, basically, the problem remains if all routers on every upward path have no memory left= . > > Until we advance more on the hybrid approach, storing mode unfortunately > doesn't exist. +1 on the hybrid approach. I assume you refer to the DAO projection draft from Pascal? > > (I'd like to learn more about your 20-hop networks, but as I hinted, > bloom filters might help there, too.) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --94eb2c192e74e56bb1053822c851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Am 21.07.2016 11:55 schrieb "Carsten Bormann" <= cabo@tzi.org>:
>
> Rahul Jadhav wrote:
> > In general the tone in ROLL WG seems to be in favor of non-storin= g mode of operation =E2=80=A6 To this effect, Carsten even made a statement= yesterday =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D while prese= nting his draft on constrained cast.
> >
> > I don=E2=80=99t truly understand on why non-storing mode is the d= e-facto mode favoured=E2=80=A6 (quite possible that this is already discuss= ed on WG before but i could not find a ref!)
>
> It is not really the favored mode.
>
> It just happens the other mode is fatally broken.
I wouldn't mark the storing mode as ultimately broken.
It works, but it does not scale well. If you have a use case for small-size= d / sparse topologies, then there should be enough space available in each = nodes' rib/fib to store the (destination;next-hop) pairs of the sub-DOD= AG.
Related to this: is there actually any work that aims to reduce the space n= eeded for (destination;next-hop) pairs? For simple RPL only networks e.g. I= can imagine that based on the DODAG Id some prefixes could be dropped / as= sumed when doing a longest prefix match.

> Storing mode presumes infinite space at each router, or= perfect
> knowledge that your topology will never cause you to exceed that space= ,
> or that each router is expendable and can rescind at any point in time=
> when its state space is exhausted (with the resulting massive
> instability because that rescinding will cause the next router to fall=
> over).
There is still the possibility to request DAO-ACKs and choose e.g. another = parent if the ACK has a negative result (could not store DAO). Whether this= approach is good or bad is of course another question. But yeah, basically= , the problem remains if all routers on every upward path have no memory le= ft.

>
> Until we advance more on the hybrid approach, storing mode unfortunate= ly
> doesn't exist.
+1 on the hybrid approach. I assume you refer to the DAO projection draft f= rom Pascal?

>
> (I'd like to learn more about your 20-hop networks, but as I hinte= d,
> bloom filters might help there, too.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.iet= f.org/mailman/listinfo/roll

--94eb2c192e74e56bb1053822c851-- From nobody Thu Jul 21 05:17:49 2016 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 9B33C12D531 for ; Thu, 21 Jul 2016 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 LSpoJiTs5GZ3 for ; Thu, 21 Jul 2016 05:17:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF2912D890 for ; Thu, 21 Jul 2016 05:17:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82C14200A3; Thu, 21 Jul 2016 08:27:18 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 21DCC638BE; Thu, 21 Jul 2016 08:17:44 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:17:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rahul Jadhav wrote: > In general the tone in ROLL WG seems to be in favor of non-storing mo= de > of operation =E2=80=A6 To this effect, Carsten even made a statement = yesterday > =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D while presenting= his draft on constrained > cast. Carsten makes some very good points about unknown limits. There are networks where the nodes are much less constrained and are often mains powered, but the radio space is very congested. An example is electric metering. The fan-out on those networks is generally very low, with the mesh often being 10 or 20 nodes deep, but only one node wide. (A "string bean" is the word that comes to my mind). I hope that the DAO-projection document will get some more mindshare soon. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5C9ZYCLcPvd0N1lAQJSrQf+JaRUcFp+SDywoLSTVczFde2Z/7ZG0/S5 2OB/suWT5xAguO3WY3tEBmV1+k0VsLiKXbzZuHxcoQysEXu4fa/DdLP/6BUtGwgY BJv/ps038LoIZois/orYD15rjOEJBBz6TVdk4lTP8QltMSnpLVZ0BSnnFE00YVMd 05XObsC92wof+46B8gaWzzKaz3IxO0bNmL2+NBwq3FduslmVyZm2BBcmmlFYiQ5M AsR3d0MAAIw6j/iUaPVudgKwHqv8V0UxxV04zsIqh7yritE15iNFM1jL9OES+L10 tMJw4KpFsesr08ajRNDvrEvSpWw6vCAs5bXkt6sHKaz7XrhfihTJmw== =HIEB -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 21 05:36:03 2016 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 7911712DB0D for ; Thu, 21 Jul 2016 05:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 edLLDCyyH38F for ; Thu, 21 Jul 2016 05:35:53 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8377112DAB6 for ; Thu, 21 Jul 2016 05:35:40 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so20394516wma.1 for ; Thu, 21 Jul 2016 05:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=qvg3Ta9wqx5OBf3grhoLdkOgyYYCMI+8K7YtLj/X/jo=; b=Rh8+OKXZlfx8+Rg9SgCGj8RJ69IXtLSFK+9EZs7ih0odorcJYRzI4nw+lEz8y2BJic JunW9ZorifPSdkfxC4WgjhrJbIz4pMk2xXXsxQOIqCOd3my0SE2Affk0Pon6wgxN2eeU 2Qs/RBE0qjek30B++cfrJU3z57UC7qpYaYoyoaxIVLpJwNJJ9iZ8VDzgmY4N0udN7KIa hwSXgb5BLe3WjR1n5MnntsMjDfVXAGblacLcxIS/LLuP2nSVKboZxXYjVYWo+BtJG+ol BJ9t9aKZ2IFH+qOA+4dWzjw0I48mnEs1RpjTPGXJR6MlXAAV44sNKT+quWdeIvbegKJs eEsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=qvg3Ta9wqx5OBf3grhoLdkOgyYYCMI+8K7YtLj/X/jo=; b=SghEOIsyK5VQznPmWiVG5Vl4XJuEdlwfmc6i26DdqRDpBHhmHf/GHFuQbtBtqtreZE eTQepHhgkndSw3RFNC6JBqeqzu3rasm5oaQnQlx9MlCw/jkruT5L7mL8ItvnVlKFTEdC kL0LTuyIPiyeHDRsRdWOuWxciDnG1PGz6fwee+KefNQ76u1sXTBb2VKspMTwpPhlpqcJ cBIuaBY8WrZYt1E7D7AWTLvDVrYf6TSr3V0QxVJq00U+yjf3C6uRWIFBUOo3wec/JLC8 65f/DAZeJ0apM0zIrznNTF6twKG3nEtK0/N8OuHovAO2fOGgmzdJZCbWyu4eYomaNpXw 0xdw== X-Gm-Message-State: ALyK8tLQRKLp5OwhOzs+RRol7LAlRBzrKrNlH9dXeOtvn3m76D+ObvjvPxYpVCq6DUqWDg== X-Received: by 10.28.0.70 with SMTP id 67mr18336726wma.88.1469104539091; Thu, 21 Jul 2016 05:35:39 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:1551:8101:7d86:a8b3? ([2001:67c:370:176:1551:8101:7d86:a8b3]) by smtp.gmail.com with ESMTPSA id d8sm3780815wmi.0.2016.07.21.05.35.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 05:35:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Rahul Jadhav In-Reply-To: <57909BF2.6070100@tzi.org> Date: Thu, 21 Jul 2016 14:35:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <254671FB-9AAC-48AF-B28D-1BB5779C393F@gmail.com> References: <57909BF2.6070100@tzi.org> To: Carsten Bormann , roll@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:36:01 -0000 > On Jul 21, 2016, at 11:54 AM, Carsten Bormann wrote: >=20 > Rahul Jadhav wrote: >> In general the tone in ROLL WG seems to be in favor of non-storing = mode of operation =E2=80=A6 To this effect, Carsten even made a = statement yesterday =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D = while presenting his draft on constrained cast. >>=20 >> I don=E2=80=99t truly understand on why non-storing mode is the = de-facto mode favoured=E2=80=A6 (quite possible that this is already = discussed on WG before but i could not find a ref!) >=20 > It is not really the favored mode. I stand corrected. Thanks.=20 >=20 > It just happens the other mode is fatally broken. > Storing mode presumes infinite space at each router, or perfect > knowledge that your topology will never cause you to exceed that = space, > or that each router is expendable and can rescind at any point in time > when its state space is exhausted (with the resulting massive > instability because that rescinding will cause the next router to fall > over). Yes, this is a problem with storing mode and has implications on the = node/solution costing. But many times, I work with requirements in the = form of max number of nodes to be supported, in which case the network = cardinality is known=E2=80=A6. the unknowns usually are in the form of = node density and the max hops required since they hugely differ from = deployment to deployment. >=20 > Until we advance more on the hybrid approach, storing mode = unfortunately > doesn't exist. >=20 > (I'd like to learn more about your 20-hop networks, but as I hinted, > bloom filters might help there, too.) My 20-hop network was an example from ami-applicability draft (where it = actually says, several tens of hops) =E2=80=A6 Having said that it will = be nice to discuss about pragmatic conditions for such networks. Thanks. >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 21 05:47:31 2016 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 20C9212DC0D for ; Thu, 21 Jul 2016 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=sics-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db8JmGT7HQX5 for ; Thu, 21 Jul 2016 05:47:26 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 8DD7212DAE8 for ; Thu, 21 Jul 2016 05:46:55 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f93so60937980lfi.2 for ; Thu, 21 Jul 2016 05:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ItS7kHc3ScU+kweaXBv6+nPprwXlKXsPJzinnWieAQw=; b=bJb7J20FEwIW33OTG3FXCR79uajXweuuoShtzydkzVn7jOXtbEIgG8qZ//ZXKQsudV r0Va13l14rjooVWC3J5TWXjyavGoF9CHu+OWbWqmxlDxJdAc3KOM51h6YUoImfH5LiMR wJtuzQ4B4anjpYkMZdwneFG0wHR9fzMPSIfhguNVb8zWPWvd8aVK7O48YzxWLz+6nTnv hth9LOE/vCk/hham0j9a/z4nwYHLLlzMXa2QoAcKm2SGWCgnkb2c4qGeGsSWqsDNxlj5 PzcZtMBUUoB9tjscLuJT8cf71qzv9T+HcnxU6GjMLmUalXVZ4Et76y3DsBuzv+zqJgIW 2K/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ItS7kHc3ScU+kweaXBv6+nPprwXlKXsPJzinnWieAQw=; b=fIasrnnbQgya/5jj815d8cVU8JWDnvbiPZcG2Bl8G+8rIP5ZIxt4bMPH24GsyM3RSA namyBOnHq1KhcJqy1B4DiSCf8roZ0eHPBX+77K/li9topgNMu0KVHOCC9UkqtMnrsK05 GchS2V+UwAHqHRgllj+iYZssXPpiY7EhlFmZ9HoZv5X+bnKXmrywvfZ6v52AFJzFspgY m2fWks0WCZ/H96VZ+n1fIeGx6ADVt+h5qmYF8f79IiTfb3clMhGYJZ4IzJhDfSEiMGM/ KEMVlOmyl2g+znZUDgev3PZBvd/h/VAAL8N+QotxNPZv1NYWETb0rkoAkw4/gGDe/n7f z5IA== X-Gm-Message-State: ALyK8tJs0dhP29lmjBeqNQMI7VKXhjt5vnYi2sj6qOzdubaxTMBvojLP49tH6R2BWKA9Umef X-Received: by 10.25.21.32 with SMTP id l32mr25158965lfi.158.1469105213665; Thu, 21 Jul 2016 05:46:53 -0700 (PDT) Received: from joakims-mbp.mydomain.local (c-4f66b8c2-74736162.cust.telenor.se. [79.102.184.194]) by smtp.gmail.com with ESMTPSA id e22sm1723847lji.1.2016.07.21.05.46.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 05:46:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Joakim Eriksson In-Reply-To: <254671FB-9AAC-48AF-B28D-1BB5779C393F@gmail.com> Date: Thu, 21 Jul 2016 14:45:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57909BF2.6070100@tzi.org> <254671FB-9AAC-48AF-B28D-1BB5779C393F@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:47:29 -0000 Hello, We have at Yanzi / SICS managed to handle networks larger than 100 nodes = with storing mode and a configuration that is 10 IPv6 neighbors and 20 RPL routes - and achieved good = stability. But the RPL specification is very underspecified when it comes to DAO and DAO ACK handling. I am more or less sure we = also could scale to 1000 nodes if that would make sense (but data rates will be so limited per node). The major problem is very dense networks - here you will need to have a = smart policy how to handle under provisioning of routing and neighbor tables - otherwise the mentioned massive = instability occurs... Best regards, =E2=80=94 Joakim Eriksson, SICS > On 21 Jul 2016, at 14:35, Rahul Jadhav wrote: >=20 >=20 >> On Jul 21, 2016, at 11:54 AM, Carsten Bormann wrote: >>=20 >> Rahul Jadhav wrote: >>> In general the tone in ROLL WG seems to be in favor of non-storing = mode of operation =E2=80=A6 To this effect, Carsten even made a = statement yesterday =E2=80=9CStoring mode doesn=E2=80=99t exist=E2=80=9D = while presenting his draft on constrained cast. >>>=20 >>> I don=E2=80=99t truly understand on why non-storing mode is the = de-facto mode favoured=E2=80=A6 (quite possible that this is already = discussed on WG before but i could not find a ref!) >>=20 >> It is not really the favored mode. > I stand corrected. Thanks.=20 >=20 >>=20 >> It just happens the other mode is fatally broken. >> Storing mode presumes infinite space at each router, or perfect >> knowledge that your topology will never cause you to exceed that = space, >> or that each router is expendable and can rescind at any point in = time >> when its state space is exhausted (with the resulting massive >> instability because that rescinding will cause the next router to = fall >> over). >=20 > Yes, this is a problem with storing mode and has implications on the = node/solution costing. But many times, I work with requirements in the = form of max number of nodes to be supported, in which case the network = cardinality is known=E2=80=A6. the unknowns usually are in the form of = node density and the max hops required since they hugely differ from = deployment to deployment. >=20 >=20 >>=20 >> Until we advance more on the hybrid approach, storing mode = unfortunately >> doesn't exist. >>=20 >> (I'd like to learn more about your 20-hop networks, but as I hinted, >> bloom filters might help there, too.) > My 20-hop network was an example from ami-applicability draft (where = it actually says, several tens of hops) =E2=80=A6 Having said that it = will be nice to discuss about pragmatic conditions for such networks. = Thanks. >=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Jul 21 06:07:09 2016 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 04C8A12D52C for ; Thu, 21 Jul 2016 06:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 jW9fI4FYQeXl for ; Thu, 21 Jul 2016 06:07:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DA712B04D for ; Thu, 21 Jul 2016 06:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2368; q=dns/txt; s=iport; t=1469106420; x=1470316020; h=date:from:to:subject:message-id:references:mime-version: content-transfer-encoding:in-reply-to; bh=O8fV4tKYgf+ZYuUhL3zrdr2kTGJdeAnFbEsARZsBurc=; b=gjYIyBV0Fn0sG7ldmOjS5vwzAFCPsM9DtpQwD+rzTyCKVRHU/QIXHvSI ZosboWs9FcmErWLHzoZtaAxBJ+qNzukcJI+WEccKDPWDjDmhLrFu11lPO YpeOheHszKjuHbzvACwHzim4kkCRB+BYuRg9uaH6eoUi7kfS2YvInDK7L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgAYyJBX/40NJK1dgz9WfLhmgXsih?= =?us-ascii?q?XgCgS04FAEBAQEBAQFlJ4RcAQEEAQEBMAE7EAsLGAklDwUTNhOIKAgOvQUBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYp3ihsFjgx1iiWOYQqPOpAhHjaEExwyh04BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="128373635" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 13:06:59 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6LD6xab009684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jul 2016 13:06:59 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6LD6xkY001421 for ; Thu, 21 Jul 2016 06:06:59 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6LD6xUP001420 for roll@ietf.org; Thu, 21 Jul 2016 06:06:59 -0700 Date: Thu, 21 Jul 2016 06:06:59 -0700 From: Toerless Eckert To: Routing Over Low power and Lossy networks Message-ID: <20160721130659.GW7377@cisco.com> References: <57909BF2.6070100@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Roll] non-storing mode vs storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:07:08 -0000 On Thu, Jul 21, 2016 at 12:28:53PM +0200, Cenk G?ndogan wrote: > Related to this: is there actually any work that aims to reduce the space > needed for (destination;next-hop) pairs? For simple RPL only networks e.g. > I can imagine that based on the DODAG Id some prefixes could be dropped / > assumed when doing a longest prefix match. Btw: One problem overall is that the RPPL routing protocols is in a working group that comes primarily from one use case side (as its name implies). For example, in autonomic networking (ANIMA) for our original charter networks enterprise/SP, we use RPL, and storing mode is perfectly fine, even with eg: 20,000 nodes. The memory/CPU requirements for this are insignificant on the SP platforms. Topologies can be up ?50 hops. The closer to the edge you get the lower the resource consumption (fewer routes). Matches perfectly the "towards the edge, equipment gets smaller" deployment model. Hey i am fine with "fundamentally broken and proud of it" ;-)) Cheers Toerless > > Storing mode presumes infinite space at each router, or perfect > > knowledge that your topology will never cause you to exceed that space, > > or that each router is expendable and can rescind at any point in time > > when its state space is exhausted (with the resulting massive > > instability because that rescinding will cause the next router to fall > > over). > There is still the possibility to request DAO-ACKs and choose e.g. another > parent if the ACK has a negative result (could not store DAO). Whether this > approach is good or bad is of course another question. But yeah, basically, > the problem remains if all routers on every upward path have no memory left. > > > > > Until we advance more on the hybrid approach, storing mode unfortunately > > doesn't exist. > +1 on the hybrid approach. I assume you refer to the DAO projection draft > from Pascal? > > > > > (I'd like to learn more about your 20-hop networks, but as I hinted, > > bloom filters might help there, too.) > > > > Gre, Carsten > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Jul 21 08:07:27 2016 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 16AF712D5F9; Thu, 21 Jul 2016 08:07:22 -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 JGwWS14mGXsG; Thu, 21 Jul 2016 08:07:20 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BB412D5F8; Thu, 21 Jul 2016 08:07:19 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so16415338ita.0; Thu, 21 Jul 2016 08:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hK+ZhivFdSEzVhbwuHzUxZzJoXMk62Ru1oE/UI91TWg=; b=kJBLURI3AaxvzZiaS4s/Pyb1/eX5u9hAZwKartIuKRgGVfJ9+orLBxSv1KrnlHns5K O9ykRwAHIB/fEedndl5i1TPL3QLj0jgedP3++jbVn4jAmcQWb/PBMSfSTUGgtkRG3BA5 IFKVfIQvPuwulcFiNxNFDqi4339kSOFZ914OLEMHVMVRLvZm+LAKZRIdpk+dL/5nEYic /CXhGfDfcQJ6dfw28TJtGx5pKEpgc6sHbB1vjM5USQSHHOlpd4oUEhxNem1AOFnfCFOc /No/d8X0M3MsZi9sEoE86PHsIqWRx/8lTZXvYqNBCwg5Ud4huqbhztp/Nc0gnsn2i/sz s+Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hK+ZhivFdSEzVhbwuHzUxZzJoXMk62Ru1oE/UI91TWg=; b=R2OtiGrlw03fPu/FMC7Dp9IlxfsK1u4Xec3PKScpTp5QAPgJ3bs9hlWpJEjemdwCrc L6d2AEKK/ZGwkF/MB96MbFXdsgqB9nyjgFzjzgm2lKT+Hq6VQ0Io41EARX1ygxi97QaH cJFjpWQrP3jafXZI1Wx5SStsmhBxUymJ+NXjprAOPTIWBR5UxibwqY0014EZEjN08ULb d4VHSOso00FAenn/EIDqtCa3NnzQyaJ5cee9KMQLRF4+CXYmWe4A+Ss7Hv45xvI2VKwW V6lOjDNS5AZ60Rs9r10Lb5ReIxJF5nu3/Pys8GH8Hh4x7eOVbSES26dYxcm6eA3+ym5q CiEA== X-Gm-Message-State: ALyK8tIB5lSJ/YHMagC+io8n+lMe8uUc44k/AYKI3wvpHB9LpGQkcJNTLMK53tI9Tl0rvs9LPUrEgsBrYY6zYw== X-Received: by 10.36.103.214 with SMTP id u205mr6298533itc.88.1469113639312; Thu, 21 Jul 2016 08:07:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.158.82 with HTTP; Thu, 21 Jul 2016 08:06:40 -0700 (PDT) In-Reply-To: <20160721091318.GA21876@cisco.com> References: <579058F8.1040701@tzi.org> <20160721091318.GA21876@cisco.com> From: Tony Przygienda Date: Thu, 21 Jul 2016 08:06:40 -0700 Message-ID: To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a114aa8d09b25c7053826ac68 Archived-At: Cc: Routing Over Low power and Lossy networks , "bier@ietf.org" , draft-bergmann-bier-ccast@ietf.org Subject: Re: [Roll] [Bier] comments on draft-bergmann-bier-ccast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:07:22 -0000 --001a114aa8d09b25c7053826ac68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yep, all good discussion. Of all, I missed the possible looping for BIER of false positives. That needs treatment before the whole idea is feasible I think ... On Thu, Jul 21, 2016 at 2:13 AM, Toerless Eckert wrote: > Thinking more of it (fun to analyse ;-): > > Without having done the math, i'd suspect this might be very efficient in > very large networks for small-receiver-sets. Aka: 2048 NFER/receivers, 64 > bits bitstring, max normal number of receivers ca. 16 for a packet. > > This could be very efficient in very large networks for > "small-receiver-set". > Aka: 2048 BFER/receivers. Maybe typically 16 receivers. > > This is not 100% tied to RPL. Consider a data-center with 100,000 VMs, > with thousands of 'vlans', each hosting a typically a quite limited > number of VMs. Instead of creating per-VLAN flood-state across the DC > (which AFAIK gets complicated with all the overlay options involved), > you could simply use maybe hmm... 256 ? bits bitstring. > > You need spanning tree forwarding (no redundancy). And you need some > logic figuring out the intermediate interfaces in the bitstring. In > RPL, the root does this. In a DC this could be more tricky. > > On Thu, Jul 21, 2016 at 07:09:12AM +0200, Carsten Bormann wrote: > > Hi Tony, > > > > thanks for taking note of this draft. > > > > > Generally, not sure how it touches BIER specifically. It seems to > > > specify RPL extensions. > > > > Indeed. We used the "WG name" BIER in the draft at the time we submitte= d > > the first version because the BIER BOF was just happening and we weren'= t > > sure where this would end up. By now it is pretty clear this will end > > up in ROLL (if at all), but resubmitting the draft to create a new -00 > > just for a WG name change is confusing. > > > > > Yes, one could reuse the BIER bit mask to > > > propagate a BLOOM filter instead of a perfect mask @ the benefit of > 'set > > > bit mask compression' vs. the cost of spurious transmissions as the > > > draft acknowledges where the degenerate case is a full broadcast. The > > > according BIER procedures/approach is nowhere to be found in the draf= t > > > though ... > > > > No, as we are indeed focusing on RPL. > > > > One very important thing we get from RPL is the rank, which allows us t= o > > avoid forwarding loops even though the individual routers are pretty > > much oblivious about the structure of the network (non-storing mode is > > based on source routes from the root of the destination-oriented > > directed acyclic graph, DODAG). So I wouldn't immediately know how to > > generalize the current approach to other underlying unicast routing > > protocols. But the use of bloom filters (instead of bitmaps) to > > identify a set of outgoing interfaces is probably extractable, if that > > is useful somewhere else. > > > > > As nit I didn't find in 6550 anything talking about "storing mode" so= a > > > better reference is needed. > > > > Hmm, I find 81 places in there. (But Ccast is for non-storing mode.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > -- > --- > Toerless Eckert, eckert@cisco.com > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a114aa8d09b25c7053826ac68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yep, all good discussion. Of all, I missed the possible lo= oping for BIER of false positives. That needs treatment before the whole id= ea is feasible I think ...=C2=A0

On Thu, Jul 21, 2016 at 2:13 AM, Toerless Eckert <ecke= rt@cisco.com> wrote:
Thinki= ng more of it (fun to analyse ;-):

Without having done the math, i'd suspect this might be very efficient = in
very large networks for small-receiver-sets. Aka: 2048 NFER/receivers, 64 bits bitstring, max normal number of receivers ca. 16 for a packet.

This could be very efficient in very large networks for "small-receive= r-set".
Aka: 2048 BFER/receivers. Maybe typically 16 receivers.

This is not 100% tied to RPL. Consider a data-center with 100,000 VMs,
with thousands of 'vlans', each hosting a typically a quite limited=
number of VMs. Instead of creating per-VLAN flood-state across the DC
(which AFAIK gets complicated with all the overlay options involved),
you could simply use maybe hmm... 256 ? bits bitstring.

You need spanning tree forwarding (no redundancy). And you need some
logic figuring out the intermediate=C2=A0 interfaces in the bitstring. In RPL, the root does this. In a DC this could be more tricky.

On Thu, Jul 21, 2016 at 07:09:12AM +0200, Carsten Bormann wrote:
> Hi Tony,
>
> thanks for taking note of this draft.
>
> > Generally, not sure how it touches BIER specifically. It seems to=
> > specify RPL extensions.
>
> Indeed. We used the "WG name" BIER in the draft at the time = we submitted
> the first version because the BIER BOF was just happening and we weren= 't
> sure where this would end up.=C2=A0 By now it is pretty clear this wil= l end
> up in ROLL (if at all), but resubmitting the draft to create a new -00=
> just for a WG name change is confusing.
>
> > Yes, one could reuse the BIER bit mask to
> > propagate a BLOOM filter instead of a perfect mask @ the benefit = of 'set
> > bit mask compression' vs. the cost of spurious transmissions = as the
> > draft acknowledges where the degenerate case is a full broadcast.= The
> > according BIER procedures/approach is nowhere to be found in the = draft
> > though ...
>
> No, as we are indeed focusing on RPL.
>
> One very important thing we get from RPL is the rank, which allows us = to
> avoid forwarding loops even though the individual routers are pretty > much oblivious about the structure of the network (non-storing mode is=
> based on source routes from the root of the destination-oriented
> directed acyclic graph, DODAG).=C2=A0 So I wouldn't immediately kn= ow how to
> generalize the current approach to other underlying unicast routing > protocols.=C2=A0 But the use of bloom filters (instead of bitmaps) to<= br> > identify a set of outgoing interfaces is probably extractable, if that=
> is useful somewhere else.
>
> > As nit I didn't find in 6550 anything talking about "sto= ring mode" so a
> > better reference is needed.
>
> Hmm, I find 81 places in there.=C2=A0 (But Ccast is for non-storing mo= de.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

--
---
Toerless Eckert, eckert@cisco.com



--
=
We=E2=80=99ve heard that a million monkeys at a million ke= yboards could produce the complete works of Shakespeare; now, thanks to the= Internet, we know that is not true.
=E2=80=94Robert Wilensky
--001a114aa8d09b25c7053826ac68-- From nobody Thu Jul 21 16:32:45 2016 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 E1AE412DA9C; Thu, 21 Jul 2016 16:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 91dz7TskCfAt; Thu, 21 Jul 2016 16:32:21 -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 5D06212DA9E; Thu, 21 Jul 2016 16:32:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,401,1464645600"; d="xml'217?scan'217,208,217";a="185562424" Received: from mail-lf0-f46.google.com ([209.85.215.46]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 01:32:16 +0200 Received: by mail-lf0-f46.google.com with SMTP id l69so73239175lfg.1; Thu, 21 Jul 2016 16:32:16 -0700 (PDT) X-Gm-Message-State: AEkoousbHOxyxYu9BgCO2VTBTmsFhA8RnPIkw6pfGuwS9Seh+uQOSCPH/gsNNShFZ9qsetzOdwlTX9MTpMKqeQ== X-Received: by 10.25.37.208 with SMTP id l199mr576711lfl.41.1469143935971; Thu, 21 Jul 2016 16:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Thu, 21 Jul 2016 16:31:56 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 22 Jul 2016 01:31:56 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Suresh Krishnan Content-Type: multipart/mixed; boundary=001a11410ed46d946b05382dba70 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 23:32:25 -0000 --001a11410ed46d946b05382dba70 Content-Type: multipart/alternative; boundary=001a11410ed46d946505382dba6e --001a11410ed46d946505382dba6e Content-Type: text/plain; charset=UTF-8 Suresh, I strongly support the publication of this document. Since it defines a mechanism which can be used by several working groups, AD sponsoring seems perfect. I'm attaching the XML of the the -02 version of that draft in which I have corrected some typos. I'll let Tero and Pat decide what he wants to merge, if anything. These changes are for the authors' information only, they do NOT affect my support to publish this document. Thomas On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > I am considering AD sponsoring the following draft > > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 > > to request the allocation of an 802.15.4 information element from the IEEE > for use in the IETF protocols that may need it. If you have any concerns > either with the content of the draft or about requesting the IE at all > please > let me know before 2016/07/29. > > Thanks > Suresh > > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) please > let > me know. > > _______________________________________________ > IoT-DIR mailing list > IoT-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/iot-dir > --001a11410ed46d946505382dba6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,

I strongly support the publicat= ion of this document. Since it defines a mechanism which can be used by sev= eral working groups, AD sponsoring seems perfect.

= I'm attaching the XML of the the -02 version of that draft in which I h= ave corrected some typos. I'll let Tero and Pat decide what he wants to= merge, if anything. These changes are for the authors' information onl= y, they do NOT affect my support to publish this document.

Thomas

On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan <= suresh.kr= ishnan@ericsson.com> wrote:
Hi all,
=C2=A0 =C2=A0I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-kivinen-802-= 15-ie-02

to request the allocation of an 802.15.4 information element from the IEEE<= br> for use in the IETF protocols that may need it. If you have any concerns either with the content of the draft or about requesting the IE at all plea= se
let me know before 2016/07/29.

Thanks
Suresh

NOTE: I have CCed: all the groups that I thought could be potentially
interested in this work. If you think I have missed out some WG(s) please l= et
me know.

_______________________________________________
IoT-DIR mailing list
IoT-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/iot-dir

--001a11410ed46d946505382dba6e-- --001a11410ed46d946b05382dba70 Content-Type: text/xml; charset=US-ASCII; name="draft-kivinen-802-15-ie-02_tw.xml" Content-Disposition: attachment; filename="draft-kivinen-802-15-ie-02_tw.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqwy8jug0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHJmYyBTWVNU RU0gInJmYzI2MjkuZHRkIiBbCiAgICA8IUVOVElUWSByZmMyMTE5IFBVQkxJQyAnJyAKICAgICAg J2h0dHA6Ly94bWwycmZjLmlldGYub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMu MjExOS54bWwnPgpdPgoKPHJmYyBjYXRlZ29yeT0nc3RkJyBpcHI9J3RydXN0MjAwOTAyJwogICAg IGRvY05hbWU9J2RyYWZ0LWtpdmluZW4tODAyLTE1LWllLTAyLnR4dCc+Cgo8P3htbC1zdHlsZXNo ZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+Cgo8P3JmYyB0b2M9J3ll cycgPz4KPD9yZmMgc3ltcmVmcz0neWVzJyA/Pgo8P3JmYyBzb3J0cmVmcz0neWVzJz8+Cjw/cmZj IGlwcm5vdGlmaWVkPSdubycgPz4KPD9yZmMgY29tcGFjdD0neWVzJyA/Pgo8P3JmYyBzdHJpY3Q9 J3llcycgPz4KCjxmcm9udD4KICA8dGl0bGU+SUVFRSA4MDIuMTUuNCBJbmZvcm1hdGlvbiBFbGVt ZW50IGZvciBJRVRGPC90aXRsZT4KICAgICAgICAKICA8YXV0aG9yIGluaXRpYWxzPSdULicgc3Vy bmFtZT0nS2l2aW5lbicgZnVsbG5hbWU9J1Rlcm8gS2l2aW5lbic+CiAgICA8b3JnYW5pemF0aW9u PklOU0lERSBTZWN1cmU8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNzPgogICAgICA8cG9zdGFs PgogICAgICAgIDxzdHJlZXQ+RWVyaWtpbmthdHUgMjg8L3N0cmVldD4KICAgICAgICA8Y29kZT5G SS0wMDE4MDwvY29kZT4KICAgICAgICA8Y2l0eT5IRUxTSU5LSTwvY2l0eT4KICAgICAgICA8Y291 bnRyeT5GSTwvY291bnRyeT4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5raXZpbmVuQGlr aS5maTwvZW1haWw+CiAgICA8L2FkZHJlc3M+CiAgPC9hdXRob3I+CiAgPGF1dGhvciBmdWxsbmFt ZT0iUGF0IEtpbm5leSIgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJLaW5uZXkiPgogICAgPG9yZ2Fu aXphdGlvbj5LaW5uZXkgQ29uc3VsdGluZyBMTEM8L29yZ2FuaXphdGlvbj4KICAgIDxhZGRyZXNz PgogICAgICA8cG9zdGFsPgoJPHN0cmVldC8+Cgk8Y2l0eS8+Cgk8cmVnaW9uLz4KCTxjb2RlLz4K CTxjb3VudHJ5Lz4KICAgICAgPC9wb3N0YWw+CiAgICAgIDxlbWFpbD5wYXQua2lubmV5QGtpbm5l eWNvbnN1bHRpbmdsbGMuY29tPC9lbWFpbD4KICAgIDwvYWRkcmVzcz4KICA8L2F1dGhvcj4KICA8 ZGF0ZSB5ZWFyPScyMDE2JyAvPgogIDxhcmVhPkludGVybmV0PC9hcmVhPgogIDxhYnN0cmFjdD4K ICAgIDx0PklFRUUgU3RkIDgwMi4xNS40IGhhcyBJbmZvcm1hdGlvbiBFbGVtZW50cyAoSUUpIHRo YXQgY2FuIGJlCiAgICB1c2VkIHRvIGV4dGVuZCA4MDIuMTUuNCBpbiBhbiBpbnRlcm9wZXJhYmxl IG1hbm5lci4gVGhlIElFRUUgODAyLjE1CiAgICBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAo QU5BKSBtYW5hZ2VzIHRoZSByZWdpc3RyeSBvZiB0aGUKICAgIEluZm9ybWF0aW9uIEVsZW1lbnRz LCBhbmQgdGhpcyBkb2N1bWVudCByZXF1ZXN0cyBBTkEgdG8gYWxsb2NhdGUgYQogICAgbnVtYmVy IGZvciB0aGUgSUVURiwgYW5kIHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIGhvdyB0aGUgSUUgaXMK ICAgIGZvcm1hdHRlZCB0byBwcm92aWRlIHN1YiB0eXBlcy48L3Q+CiAgPC9hYnN0cmFjdD4KPC9m cm9udD4KCjxtaWRkbGU+CiAgPHNlY3Rpb24gdGl0bGU9J0ludHJvZHVjdGlvbic+CiAgICA8dD5J RUVFIFN0ZC4gODAyLjE1LjQgPHhyZWYgdGFyZ2V0PSJJRUVFLTgwMi0xNS00IiAvPiBoYXMKICAg IEluZm9ybWF0aW9uIEVsZW1lbnRzIChJRSkgdGhhdCBjYW4gYmUgdXNlZCB0byBleHRlbmQgODAy LjE1LjQgaW4gYW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuCiAgICBUaGVyZSBhcmUgdHdvIGRpZmZl cmVudCBJRQogICAgdHlwZXMsIEhlYWRlciBJRSBhbmQgUGF5bG9hZCBJRS4gVGhlIEhlYWRlciBJ RXMgYXJlIHBhcnQgb2YgdGhlCiAgICBNZWRpdW0gQWNjZXNzIENvbnRyb2wgKE1BQykgaGVhZGVy LCBhbmQgYXJlIG5ldmVyIGVuY3J5cHRlZCwKICAgIGJ1dCB0aGV5IG1heSBiZSBhdXRoZW50aWNh dGVkLiBNb3N0IG9mIHRoZSBIZWFkZXIgSUUgcHJvY2Vzc2luZyBpcwogICAgZG9uZSBieSB0aGUg TUFDLCBhbmQgSUVURiBwcm90b2NvbHMgc2hvdWxkIG5vdCBuZWVkIHRvIGV4dGVuZAogICAgdGhl bS4gVGhlIFBheWxvYWQgSUVzIGFyZSBwYXJ0IG9mIHRoZSBNQUMgcGF5bG9hZCBhbmQgdGhleQog ICAgbWF5IGJlIGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRlZC48L3Q+CgogICAgPHQ+SUVURiBw cm90b2NvbHMgd2lsbCBuZWVkIHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gaW4gdGhlIDgwMi4xNS40 CiAgICBmcmFtZXM7IHRoZSBzdGFuZGFyZCA4MDIuMTUuNCB3YXkgb2YgZG9pbmcgdGhpcyBpcyB0 byBpbmNsdWRlCiAgICBvbmUgb2YgbW9yZSBwYXlsb2FkIElFcyBpbiB0aGUgZnJhbWUgdGhhdCB3 aWxsIGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uLiBCZWNhdXNlCiAgICBvZiB0aGlzLCB0aGUgSUVU RiBuZWVkcyB0byBvYnRhaW4gYSBkZWRpY2F0ZWQgUGF5bG9hZCBJRSBmcm9tIHRoZSBJRUVFCiAg ICA4MDIuMTUgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKEFOQSkgPHhyZWYKICAgIHRhcmdl dD0nSUVFRS04MDItMTUtQU5BJyAvPi4gVGhlIHVwLXRvLWRhdGUgODAyLjE1IEFOQSBkYXRhYmFz ZQogICAgY2FuIGJlIGZvdW5kIGF0IDx4cmVmIHRhcmdldD0nSUVFRS04MDItMTUtQU5BLURCJyAv Pi48L3Q+CgogICAgPHQ+VGhlIDgwMi4xNS40IG9wZXJhdGlvbnMgbWFudWFsIDx4cmVmIHRhcmdl dD0nSUVFRS04MDItMTUtT1BTJwogICAgLz4gcHJvdmlkZXMgaW5mb3JtYXRpb24gb24gaG93IGEg c3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlvbiBtYXkKICAgIHJlcXVlc3QgYW4gYWxsb2NhdGlv biBvZiBhbiBJRS4gVG8gbWFrZSB0aGlzIHJlcXVlc3QsCiAgICB0aGUgc3RhbmRhcmRpemF0aW9u IG9yZ2FuaXphdGlvbiBuZWVkcyB0bzogcHJvdmlkZSB0aGUgcmVhc29uIGZvcgogICAgdGhlIHJl cXVlc3Q7IGEgZGVzY3JpcHRpb24gb2YgdGhlIHByb3RvY29sIGZvcm1hdCB0aGF0IHNob3dzIHRo ZXJlCiAgICBpcyBzdWZmaWNpZW50IHN1YnR5cGUgY2FwYWJpbGl0eTsgYSBzdGF0ZW1lbnQgdGhh dCB0aGUgZXh0ZXJuYWwKICAgIG9yZ2FuaXphdGlvbiB1bmRlcnN0YW5kcyB0aGF0IG9ubHkgb25l IElEIG51bWJlciB3aWxsIGJlCiAgICBpc3N1ZWQuPC90PgoKICAgIDx0PlRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlCiAgICByZXF1ZXN0LjwvdD4K CiAgIDwvc2VjdGlvbj4KCiAgIDxzZWN0aW9uIGFuY2hvcj0idGVybWlub2xvZ3kiIHRpdGxlPSJU ZXJtaW5vbG9neSI+CgogICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTAogICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiCiAgICBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYKICAgIHRhcmdl dD0nUkZDMjExOScvPi48L3Q+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbiB0aXRsZT0iVXNlcnMg b2YgdGhlIElFVEYgSUUiIGFuY2hvcj0idXNlcnMiPgogICAgPHQ+VGhlcmUgYXJlIHNldmVyYWwg SUVURiB3b3JraW5nIGdyb3VwcyBzdWNoIGFzIDZUaVNDSCwgNmxvLCBDb1JFCiAgICBldGMsIHdo aWNoIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBJRS4gVGhlIDZUaVNDSCB3b3JraW5nCiAg ICBncm91cCBoYXMgYWxyZWFkeSBleHByZXNzZWQgdGhlIG5lZWQgZm9yIHRoZSBJRSwgYW5kIHRo aXMKICAgIGFsbG9jYXRpb24gc2hvdWxkIHByb3ZpZGUgdGhlbSBhIHdheSBmb3J3YXJkLjwvdD4K ICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSdJRVRGIElFIFN1YnR5cGUgRm9ybWF0JyBh bmNob3I9J2lldGYtaWUnPgoKICAgIDx0PlRoZSBtYXhpbXVtIGxlbmd0aCBvZiB0aGUgUGF5bG9h ZCBJRSBjb250ZW50IGlzIDIwNDcgb2N0ZXRzLAogICAgYW5kIDgwMi4xNS40IGZyYW1lIGNvbnRh aW5zIGEgbGlzdCBvZiBwYXlsb2FkIElFcywgaS5lLiBhIHNpbmdsZQogICAgZnJhbWUgY2FuIGhh dmUgbXVsdGlwbGUgcGF5bG9hZCBJRXMsIHRlcm1pbmF0ZWQgd2l0aCB0aGUgcGF5bG9hZAogICAg SUUgdGVybWluYXRvciwgYW5kIG1heSBiZSBmb2xsb3dlZCBieSB0aGUgcGF5bG9hZC48L3Q+Cgog ICAgPHQ+QmVjYXVzZSB0aGUgZnJhbWUgY29udGFpbnMgYSBsaXN0IG9mIHBheWxvYWRzLCB0aGVy ZSBpcyBubwogICAgbmVlZCB0byBwcm92aWRlIGludGVybmFsIHN0cnVjdHVyZSBpbnNpZGUgdGhl IElFVEYgSUUuIFRoZSBQYXlsb2FkCiAgICBJRSBmb3JtYXQgb2YgdGhlIDgwMi4xNS40IGNvbnRh aW5zIHRoZSBMZW5ndGggZmllbGQsIHNvIHRoZQogICAgbGVuZ3RoIG9mIHRoZSBTdWItVHlwZSBD b250ZW50IGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aAogICAgZmllbGQgb2YgdGhl IElFVEYgSUUuPC90PgoKICAgIDx0PlRoZSBmb3JtYXQgb2YgdGhlIElFVEYgSUUgaXMgYXMgZm9s bG93czo8L3Q+CiAgICAKICAgIDxmaWd1cmUgYW5jaG9yPSJpZXRmLWllLWZpZ3VyZSIgdGl0bGU9 IklFVEYgSUUgU3VidHlwZSBGb3JtYXQiID48YXJ0d29yaz48IVtDREFUQVsKICAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwp8IFN1Yi1UeXBlIElEICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp+ICAgICAgICAgICAgICAgICAgICAgICBTdWIt VHlwZSBDb250ZW50ICAgICAgICAgICAgICAgICAgICAgICAgfgp8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwpd XT48L2FydHdvcms+PC9maWd1cmU+CgogICAgPHQ+PGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAg ICA8dD5TdWItVHlwZSBJRCBpcyB0aGUgSUFOQSBhbGxvY2F0ZWQgbnVtYmVyIHNwZWNpZnlpbmcg dGhlCiAgICAgIHN1Yi10eXBlIG9mIHRoZSBJRVRGIElFLiBWYWx1ZSAwIGlzIHJlc2VydmVkIGZv ciBmdXR1cmUKICAgICAgZXh0ZW5zaWJpbGl0eSwgaS5lLiwgaW4gY2FzZSBhIGxvbmdlciBTdWIt VHlwZSBJRCBmaWVsZCBpcwogICAgICBuZWVkZWQuPC90PgoKICAgICAgPHQ+U3ViLVR5cGUgQ29u dGVudCBpcyB0aGUgYWN0dWFsIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uCiAgICAgIGVsZW1l bnQsIGFuZCBpdHMgbGVuZ3RoIGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gdGhlIExlbmd0aCBmaWVs ZAogICAgICBvZiB0aGUgSUVURiBJRS4gPC90PgogICAgPC9saXN0PjwvdD4KCiAgICA8dD5PbmUg SUVFRSA4MDIuMTUuNCBmcmFtZSBjYW4gY29udGFpbiBtdWx0aXBsZSBJRVRGIElFcyB3aXRoIHRo ZSBzYW1lCiAgICBvciBkaWZmZXJlbnQgc3ViIHR5cGVzLjwvdD4KICAgIAogIDwvc2VjdGlvbj4K CiAgPHNlY3Rpb24gdGl0bGU9IlZlbmRvciBTcGVjaWZpYyBJRSI+CgogICAgPHQ+SUVFRSA4MDIu MTUuNCBoYXMgYWxyZWFkeSBzZXZlcmFsIG51bWJlcnMgZm9yIGRpZmZlcmVudCBWZW5kb3IKICAg IFNwZWNpZmljIElFIHR5cGVzLiBUaGVyZSBpcyBvbmUgZm9yIHRoZSBWZW5kb3IgU3BlY2lmaWMg SGVhZGVyIElFCiAgICBmb3IgSGVhZGVyIElFcy4gVGhlcmUgaXMgb25lIGluY29ycmVjdGx5IG5h bWVkIFZlbmRvciBTcGVjaWZpYwogICAgTmVzdGVkIElFIGZvciBQYXlsb2FkIElFcywgYW5kIHRo ZXJlIGlzIGFub3RoZXIgb25lIHdpdGgKICAgIGV4YWN0bHkgdGhlIHNhbWUgbmFtZSwgYnV0IHVu ZGVyIHRoZSBNTE1FIE5lc3RlZCBJRSBsb25nIGZvcm1hdC4gQWxsCiAgICBvZiB0aGUgVmVuZG9y IFNwZWNpZmljIElFcyBzdGFydCB3aXRoIGEgMy1vY3RldCB2ZW5kb3IgT1VJIHRvCiAgICBpZGVu dGlmeSB0aGUgb3JnYW5pemF0aW9uLjwvdD4KCiAgICA8dD5CZWNhdXNlIG9mIHRoaXMsIHRoZXJl IGlzIG5vIG5lZWQgdG8gcmVzZXJ2ZSB0aGUgc3BlY2lmaWMKICAgIFN1Yi1UeXBlIElEcyBmb3Ig dGhlIHZlbmRvci1zcGVjaWZpYyB1c2VzLCBhcyB0aG9zZSBvdGhlciBJRSB0eXBlcwogICAgY2Fu IGJlIHVzZWQgZm9yIHRoYXQuPC90PgoKICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRpdGxlPSJS ZXF1ZXN0IHRvIGFsbG9jYXRlIElFVEYgSUUiPgogICAgPHQ+SUVURiB3b3VsZCByZXF1ZXN0IHRo ZSA4MDIuMTUuNCBXb3JraW5nIEdyb3VwIHRvIGFsbG9jYXRlIGEKICAgIFBheWxvYWQgSUUgZm9y IElFVEYgdXNlLiBGdXJ0aGVybW9yZSBJRVRGIHVuZGVyc3RhbmRzIHRoYXQgb25seQogICAgb25l IElEIHdpbGwgYmUgaXNzdWVkIHRvIGl0LjwvdD4KICA8L3NlY3Rpb24+CgogIDxzZWN0aW9uIHRp dGxlPSdTZWN1cml0eSBDb25zaWRlcmF0aW9ucyc+CgogICAgPHQ+VGhpcyBkb2N1bWVudCBjcmVh dGVzIGFuIElBTkEgcmVnaXN0cnkgZm9yIElFVEYgSUUgU3ViLXR5cGUKICAgIElEcywgYW5kIHRo ZSBzZWN1cml0eSBvZiB0aGUgcHJvdG9jb2xzIHVzaW5nIHRoZSBJRXMgbmVlZHMgdG8gYmUKICAg IGRlc2NyaWJlZCBpbiB0aGUgYWN0dWFsIGRvY3VtZW50cyBhbGxvY2F0aW5nIHZhbHVlcyBmcm9t IHRoaXMKICAgIHJlZ2lzdHJ5LjwvdD4KCiAgICA8dD5UaGUgSUVFRSBTdGQgODAyLjE1LjQtMjAx NSA8eHJlZiB0YXJnZXQ9IklFRUUtODAyLTE1LTQiIC8+CiAgICBjb250YWlucyBtZXRob2RzIHdo ZXJlIHNlY3VyaXR5IG9mIHRoZSBJRSBjYW4gYmUgZW5mb3JjZWQgd2hlbiBhCiAgICBmcmFtZSBp cyByZWNlaXZlZCwgYnV0IHRoaXMgaXMgb25seSBwZXIgSUUgdHlwZSwgdGh1cyBhbGwgSUVURiBJ RXMKICAgIHdpbGwgaGF2ZSBzYW1lIHNlY3VyaXR5IGxldmVsIHJlcXVpcmVtZW50cyByZWdhcmRs ZXNzIG9mIHRoZQogICAgU3ViLVR5cGUgSUQgdXNlZC4gVGhpcyBjYW4gY2F1c2UgaXNzdWVzIGlm IGRpZmZlcmVudCBzZWN1cml0eQogICAgcHJvY2Vzc2luZyB3b3VsZCBiZSBuZWVkZWQgYW5kIGFu eSBvZiB0aG9zZSBJRXMgd291bGQgbmVlZCB0byBiZQogICAgcHJvY2Vzc2VkIGluIHRoZSBNQUMg bGV2ZWwuIEZvcnR1bmF0ZWx5LCBldmVyeXRoaW5nIElFVEYgZG9lcwogICAgc2hvdWxkIGJlIGlu IGEgaGlnaGVyIGxldmVsIHRoYW4gdGhlIE1BQyBsZXZlbCwgdGh1cyB0aGUgaGlnaGVyCiAgICBs YXllciBwcm9jZXNzaW5nIGZvciB0aGVzZSBJRXMgbmVlZHMgdG8gcGVyZm9ybSBzZXBhcmF0ZSBz ZWN1cml0eQogICAgcG9saWN5IGNoZWNraW5nIGJhc2VkIG9uIHRoZSBJRVRGIElFIFN1Yi1UeXBl IElEIGluIGFkZGl0aW9uIHRvCiAgICB0aGUgY2hlY2tzIGRvbmUgYnkgdGhlIE1BQy48L3Q+Cgog IDwvc2VjdGlvbj4KICAKICA8c2VjdGlvbiB0aXRsZT0nSUFOQSBDb25zaWRlcmF0aW9ucycgYW5j aG9yPSdpYW5hJz4KCiAgICA8dD5UaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnkg Zm9yIElFVEYgSUUgU3ViLXR5cGUgSURzCiAgICByZWdpc3RyeTo8L3Q+CgogICAgPGZpZ3VyZT48 YXJ0d29yaz48IVtDREFUQVsKVmFsdWUgICAgIFN1Yi10eXBlIElECjAgICAgICAgICBSZXNlcnZl ZAoxLTIwMCAgICAgVW5hc3NpZ25lZAoyMDEtMjU1ICAgRXhwZXJpbWVudGFsIFVzZQpdXT48L2Fy dHdvcms+PC9maWd1cmU+CgogICAgPHQ+Q2hhbmdlcyBhbmQgYWRkaXRpb25zIHRvIHRoaXMgcmVn aXN0cnkgaXMgYnkgZXhwZXJ0IHJldmlldy48L3Q+CiAgICAgICAKICA8L3NlY3Rpb24+Cgo8L21p ZGRsZT4KPGJhY2s+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+ CiAgICAmcmZjMjExOTsKICA8L3JlZmVyZW5jZXM+CgogIDxyZWZlcmVuY2VzIHRpdGxlPSdJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzJz4KICAgIDxyZWZlcmVuY2UgYW5jaG9yPSdJRUVFLTgwMi0xNS00 Jz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5JRUVFIFN0YW5kYXJkIGZvciBMb3ctUmF0 ZSBXaXJlbGVzcyBQZXJzb25hbCBBcmVhCiAgICAgICAgTmV0d29ya3MgKFdQQU5zKTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIHllYXI9JzIwMTUnLz4KICAgICAgPC9m cm9udD4KICAgICAgPHNlcmllc0luZm8gbmFtZT0iSUVFRSIgdmFsdWU9IlN0YW5kYXJkIDgwMi4x NS40IiAvPgogICAgPC9yZWZlcmVuY2U+CgogICAgPHJlZmVyZW5jZSBhbmNob3I9J0lFRUUtODAy LTE1LUFOQScKCSAgICAgICB0YXJnZXQ9Imh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvMTUvQU5BLmh0 bWwiPgogICAgICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5PC90aXRsZT4KCTxhdXRob3I+PC9hdXRob3I+CiAgICAgICAgPGRhdGUg Lz4KICAgICAgPC9mcm9udD4KICAgIDwvcmVmZXJlbmNlPgoKICAgIDxyZWZlcmVuY2UgYW5jaG9y PSdJRUVFLTgwMi0xNS1BTkEtREInCgkgICAgICAgdGFyZ2V0PSdodHRwczovL21lbnRvci5pZWVl Lm9yZy84MDIuMTUvZG9jdW1lbnRzP2lzX2Rjbj0yNTcmYW1wO2lzX2dyb3VwPTAwMDAnPgogICAg ICA8ZnJvbnQ+CiAgICAgICAgPHRpdGxlPklFRUUgODAyLjE1IEFOQSBkYXRhYmFzZTwvdGl0bGU+ Cgk8YXV0aG9yPjwvYXV0aG9yPgogICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8 L3JlZmVyZW5jZT4KCiAgICA8cmVmZXJlbmNlIGFuY2hvcj0nSUVFRS04MDItMTUtT1BTJwoJICAg ICAgIHRhcmdldD0naHR0cHM6Ly9tZW50b3IuaWVlZS5vcmcvODAyLjE1L2RvY3VtZW50cz9pc19k Y249MjM1JmFtcDtpc19ncm91cD0wMDAwJz4KICAgICAgPGZyb250PgogICAgICAgIDx0aXRsZT5J RUVFIDgwMi4xNSBPcGVyYXRpb25zIE1hbnVhbDwvdGl0bGU+Cgk8YXV0aG9yPjwvYXV0aG9yPgog ICAgICAgIDxkYXRlIC8+CiAgICAgIDwvZnJvbnQ+CiAgICA8L3JlZmVyZW5jZT4KCiAgPC9yZWZl cmVuY2VzPgo8L2JhY2s+Cgo8L3JmYz4K --001a11410ed46d946b05382dba70-- From nobody Thu Jul 21 16:45:32 2016 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 A283412D1E4; Thu, 21 Jul 2016 16:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 n9leZ6JS4IN0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 30F3B12D74E; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p74so88258870qka.0; Thu, 21 Jul 2016 16:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=oUZ9E3Wt2h9rs6qRtvwb5SNAoeNQCIWNEk/KfY2VJXvFciivrbUhBfdo2B2l84/l53 ysRJi4Ypae/wMtx2ky/tL3yJW8UXYf6y9z7LKZsmOYhWxon9hMILccrTWbxt2F4AyVuv dOJ5AMexwSLq2AigY2lKQXD7iTbKH5vqHseEFENKPZAyN0X091k8lUzgUu6C3F5BHzU3 l+43Eale5yjQUIMSuwXLe31Jpou6m5HY1WCv+JerfuS/EMncf6Dbv/8/dB9WhRQtE/Uy knEBdQGkaG5YgPDDvOEOgDDIPB+DkWH2PHF9LbY779I9scFfQEzmOhnWHufw9lSH2KIs /BuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Ehcii1hf2lKhGdgwu2igm6uToYpA6zsvT1M7SjEK2Wg=; b=d2B31SvMMGuGZjFP5DmrnZLb4p/nWIRpZwKLfCL2+OeKuDg3ygdJbaK9KBhY/tPAKn OYlreVImpvdFER8O03O2lspbFFbQOLVo1nJAFEXEZs3WI1/GOfD3GYr2nkwOjwHRPiYp v7+dCsjs6d+DrgcBTYGaFFNDvyCr15vUAUBRJK0cj0dvOyXkSDtn97kmEaTCaAWv0VQx xsS2Mql//8ag+iQTnYT+O4/6re/Gnz06kW/hZNaUuabz3n4eCg/jlPkQp9Z6RMUfCTRH 3LZu4zQx9B+enUTJJVw1pVNmkRPm/Q3cloPf09TlzAgMg5g/iXMdQlX7QJUyReldIhyz GIzA== X-Gm-Message-State: AEkooutPaZG0dmixy+Pxzf8y8JokN0C5vMRIfJXtwupfH5inVibS/uY6Xv29m6d4/BBPAw== X-Received: by 10.55.201.136 with SMTP id m8mr1237723qkl.166.1469144706328; Thu, 21 Jul 2016 16:45:06 -0700 (PDT) Received: from rtp-vpn1-1829.cisco.com ([173.38.117.78]) by smtp.gmail.com with ESMTPSA id e33sm5724375qta.47.2016.07.21.16.45.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 16:45:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Ralph Droms In-Reply-To: Date: Fri, 22 Jul 2016 01:45:02 +0200 Message-Id: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 23:45:10 -0000 --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seems to me this document could easily be a working group document. Why = have you decided to publish it as AD sponsored document? - Ralph > On Jul 18, 2016, at 2:39 PM 7/18/16, Suresh Krishnan = wrote: >=20 > Hi all, > I am considering AD sponsoring the following draft >=20 > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 >=20 > to request the allocation of an 802.15.4 information element from the = IEEE > for use in the IETF protocols that may need it. If you have any = concerns > either with the content of the draft or about requesting the IE at all = please > let me know before 2016/07/29. >=20 > Thanks > Suresh >=20 > NOTE: I have CCed: all the groups that I thought could be potentially > interested in this work. If you think I have missed out some WG(s) = please let > me know. >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXkV5+AAoJEINeeBNmFjV5NxYQAIjOdTko0MiOjEAbroyju3FG RiYcOCYrJ7iwbrNJhF86Wf15MPuY9JXHZX2B752yit3PnSuCZQMy1WkJa6YO3YtO 03AzOGhmTX/bX7qkxsrpHv3YbJaxjxQ27crqLZUzLcn2OX5QNETg/nfQkQI/eLN1 lhSZWyrHFhpY5Gr0xAO3nuQY5o9E5dx/LjeHi9aXGCDYBeGBhXhhFmlB3haxCz3+ hkFPx6c54wMMuX+/E+7SDExw2MichBsOO+HMU7jJiQEJGbNm39xBcbm59kP02ezC BpjRHO1QE+xUoyes4+byTGSA2dtzYb8p7EZMzN3+YVWY/FnVaZV8lMAoUdgus6+I VG9UyGjyMa9l8LV88q6ppBWan+8aTLLnIxOXrtzyT5ua2pWH7px3SczgsY18ygbN cRCmtQLT/uiwvfcawdRq1ufp1zsk3uC9/XQR65ml5ebIWSI+z03tryXmY59pAq1s rN3S58xRpjQk/kD408U9rLsSfnl9ojL4JT0Hs0Qfuag/A345dzZia5NNZVFBNGk3 Z7WK5Dwv4ILgpTdWzP6NGPTKseGADzX+ZnS7g/duZhwwjTdOZpj9+/genAK5VLby cypzeAL28SMz86SZmzRcSex/dPtso1MN7D/v2Euo6Jrzz1tceCHiOdI5r9vEU6Un TwQ7/wupFzDXRFhFHJkD =ASZI -----END PGP SIGNATURE----- --Apple-Mail=_6A727992-9D2B-4037-AD8D-6016FB149223-- From nobody Fri Jul 22 01:29:54 2016 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 CE2CA12DA35; Fri, 22 Jul 2016 01:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 cbKfsv38oIW2; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8DAFD12D1A4; Fri, 22 Jul 2016 01:29:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8TOvm016279 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:29:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8TNep008324; Fri, 22 Jul 2016 11:29:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.55651.808400.872940@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:29:23 +0300 From: Tero Kivinen To: Thomas Watteyne In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 1 min Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:29:30 -0000 Thomas Watteyne writes: > I'm attaching the XML of the the -02 version of that draft in which I have > corrected some typos. I'll let Tero and Pat decide what he wants to merge, if > anything. These changes are for the authors' information only, they do NOT > affect my support to publish this document. Thanks, I have taken your most of your changes to my xml version, and I will publish new version soon, with those fixes. -- kivinen@iki.fi From nobody Fri Jul 22 05:44:25 2016 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 B44FE12D1F0; Fri, 22 Jul 2016 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 5OyDcoL8Y0pf; Fri, 22 Jul 2016 05:44:21 -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 69B9812D62A; Fri, 22 Jul 2016 05:44:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,404,1464645600"; d="scan'208,217";a="227601884" Received: from mail-lf0-f41.google.com ([209.85.215.41]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jul 2016 14:44:18 +0200 Received: by mail-lf0-f41.google.com with SMTP id b199so84876429lfe.0; Fri, 22 Jul 2016 05:44:18 -0700 (PDT) X-Gm-Message-State: AEkooutVTV+wXjqVl5gni5zY2MkpPmjgG+/EfJQVVWhFV5fj6I/EnyrIQ0CJSK4uT58/QynUpuwPKISFqlsWuw== X-Received: by 10.25.89.65 with SMTP id n62mr2608729lfb.89.1469191457615; Fri, 22 Jul 2016 05:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.146.84 with HTTP; Fri, 22 Jul 2016 05:43:57 -0700 (PDT) In-Reply-To: <22417.55651.808400.872940@fireball.acr.fi> References: <22417.55651.808400.872940@fireball.acr.fi> From: Thomas Watteyne Date: Fri, 22 Jul 2016 14:43:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11411eb8f045cd053838ca21 Archived-At: Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [IoT-DIR] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 12:44:24 -0000 --001a11411eb8f045cd053838ca21 Content-Type: text/plain; charset=UTF-8 Awesome, thanks On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen wrote: > Thomas Watteyne writes: > > I'm attaching the XML of the the -02 version of that draft in which I > have > > corrected some typos. I'll let Tero and Pat decide what he wants to > merge, if > > anything. These changes are for the authors' information only, they do > NOT > > affect my support to publish this document. > > Thanks, I have taken your most of your changes to my xml version, and > I will publish new version soon, with those fixes. > -- > kivinen@iki.fi > -- _______________________________________ 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 _______________________________________ --001a11411eb8f045cd053838ca21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Awesome, thanks

On Fri, Jul 22, 2016 at 10:29 AM, Tero Kivinen <kivinen@= iki.fi> wrote:
Thomas Watte= yne writes:
> I'm attaching the XML of the the -02 version of that draft in whic= h I have
> corrected some typos. I'll let Tero and Pat decide what he wants t= o merge, if
> anything. These changes are for the authors' information only, the= y do NOT
> affect my support to publish this document.

Thanks, I have taken your most of your changes to my xml version, and
I will publish new version soon, with those fixes.
--
kivinen@iki.fi



--
_______________________________________

<= /font>
Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
= Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkele= y OpenWSN
Co-chair, IETF 6TiSCH

__________= _____________________________
--001a11411eb8f045cd053838ca21-- From nobody Sat Jul 23 06:53:53 2016 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 2CE1212DA7E; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 1mqmeRzUQhiA; Fri, 22 Jul 2016 01:12:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 BD0D912DAAC; Fri, 22 Jul 2016 01:12:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6M8CJkL019028 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jul 2016 11:12:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6M8CJ8i015184; Fri, 22 Jul 2016 11:12:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22417.54627.526844.924720@fireball.acr.fi> Date: Fri, 22 Jul 2016 11:12:19 +0300 From: Tero Kivinen To: Ralph Droms In-Reply-To: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: X-Mailman-Approved-At: Sat, 23 Jul 2016 06:53:52 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:12:38 -0000 Ralph Droms writes: > Seems to me this document could easily be a working group document. > Why have you decided to publish it as AD sponsored document? As this will allocate number for the IETF, not for just one WG, the authors though it would be better to get as wide coverage for it, meaning having longer last call time, and advertising it in several different working groups (who might use it in the future), instead of having it for one WG draft in some WG. Also it was not clear which WG it should be in. I think 6tisch is the one who might need it first, but 6lo is most likely also going to using it etc. -- kivinen@iki.fi From nobody Sat Jul 23 06:53:57 2016 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 3BAA712DA57; Sat, 23 Jul 2016 04:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 IugFUxgXJ9DV; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F38912D110; Sat, 23 Jul 2016 04:30:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BD3B2203AD; Sat, 23 Jul 2016 07:39:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B0170638BE; Sat, 23 Jul 2016 07:30:18 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-Mailman-Approved-At: Sat, 23 Jul 2016 06:53:52 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 11:30:22 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > meaning having longer last call time, and advertising it in several > different working groups (who might use it in the future), instead of > having it for one WG draft in some WG. > Also it was not clear which WG it should be in. I think 6tisch is the > one who might need it first, but 6lo is most likely also going to > using it etc. This makes me ask a question about 802.15.9: would a new KMP created by the IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtype? Or does 15.9 have it's own registry, and if so would we need different liason request for that? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NVR4CLcPvd0N1lAQIR7gf+PqzBdKtG9KHlsMZ+8Qadn0/717on1htM jmmFgtDNZGQZbqJEGhMcCHsOEgi7y6pwcrTiWgs8gQtV2y5NLEH5bmUL1W67TCa+ 7ggnoZuRNqU6404TmI/1XrLvjcPTamjMbeKv1JFhbUSUBhLUj7gOUisGNtIJW52u b3Sgxt9X69hcJ+Q17KTIZxdyMlqnMp8FmdrHYYMMP9vniYySzRZm6dL7eCrOQpFd iP952rBehCygTEpzHlSPRw5A9cBPCM/an/QGZzFuOhz920MlqPHlNp6XN7EqlzG8 07SB7UhuZ2jtH4fT59abialUpncY+aSnVLBFSvzqfPDJcswjKMwTyA== =jcGn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 23 13:09:57 2016 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 1E1CB12D78E for ; Sat, 23 Jul 2016 12:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.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 nLCNJUGSyILQ for ; Sat, 23 Jul 2016 12:26:36 -0700 (PDT) Received: from nm47-vm5.bullet.mail.ne1.yahoo.com (nm47-vm5.bullet.mail.ne1.yahoo.com [98.138.121.101]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329F612D78B for ; Sat, 23 Jul 2016 12:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1469301991; bh=N7v2GMKFE2NmnZumKgBTMmJH2KBK14YVaxesBSz2jNU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=SSWeqUOBfYj9aN6MbKkVgFmgYgzHcmEkR/TF9m1kJnjlQbFQac4TN4Ci2+H++SY8mZlUmYm14EVWvfzelsmo4kOcq0Hzt4C4RP6955OA1EkkMEcFpGFuaZzXWlRmbfCF22HIafA3kdtws7bTYDZ7pfDMQvWCqVW9/8jzmHwbMeQ= Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:26:31 -0000 Received: from [98.138.226.177] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:23:42 -0000 Received: from [98.138.226.58] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 Received: from [127.0.0.1] by smtp209.mail.ne1.yahoo.com with NNFMP; 23 Jul 2016 19:20:54 -0000 X-Yahoo-Newman-Id: 54038.44352.bm@smtp209.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: qRHBZqQVM1lXX.5le6Fw0oW3FhlNwv2H0MiGDH4ZPOyqkLQ CHo0a8ggOR3wDfmkvqw1_vPGn8lMEDgkDzhFQ_zKh3opf8oSEwQb2nsJJLu_ ciUjT8ZctkEhBAU4bZ9SNgyhD_0qc5hP08vC9M9AChKUX1fx6lXCjwQhjiNO NQoKsqapWlcxz3CQdzaCCHF5nOWMIxvs6IKEPAIJn35t6v5Rv4PpQiWb4C_R DNztc8Q4sa1tEBvVyJ.NFkx0eQZmLju04yWILHeAnk07VFzoaqYB_.D5x9Oi 9zsMhxrY0I4NpgS_U_j_3YCobD1NCpat0CgDU8ttzZwPQKCMBT8GhCiS.vOq rnCcAJhiUBQJE3e_G5VEy.Ee2uiA7nKZvQjGDKjwKSuAe9f24vWicKTBslaZ v9JX4sdjCZdnup8aODXT3dbLpQuWUDsXJqVPB1XOQ7DIO_mw4MM.XTXZnd1v VcGPS4us.bWyZLFB95wDfu16FBHfqK8wNm.8lllGX6sZbpIPnqK5zkT_h454 E08I8a5FBevX5_7QniBoiayP0_8brUoX1SwzjxJEvfRH0uQZTRgmc3FM2JlD qIAEF1klzxnD4vOSkNJULRg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Don Sturek X-Mailer: iPad Mail (13F69) In-Reply-To: <31079.1469273418@obiwan.sandelman.ca> Date: Sat, 23 Jul 2016 12:20:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> <31079.1469273418@obiwan.sandelman.ca> To: Michael Richardson Archived-At: X-Mailman-Approved-At: Sat, 23 Jul 2016 13:09:56 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , Tero Kivinen , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 19:26:38 -0000 Hi Michael IEEE 802.15.9 defines a multiplex ID covered by the IEEE 802.15 ANA. To def= ine a new KMP would only require a new annex that describes how the KMP work= s and an allocation of a new Multiplex ID. There is also a vendor specific multiplex ID that could be used now without a= ny written description in IEEE 802.15 Don Sent from my iPad > On Jul 23, 2016, at 4:30 AM, Michael Richardson wr= ote: >=20 >=20 > Tero Kivinen wrote: >> meaning having longer last call time, and advertising it in several >> different working groups (who might use it in the future), instead of >> having it for one WG draft in some WG. >=20 >> Also it was not clear which WG it should be in. I think 6tisch is the >> one who might need it first, but 6lo is most likely also going to >> using it etc. >=20 > This makes me ask a question about 802.15.9: would a new KMP created by t= he > IETF for 15.9 (such as OSCOAP or DTLS) need to use an IE under this subtyp= e? > Or does 15.9 have it's own registry, and if so would we need different lia= son > request for that? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Mon Jul 25 04:33:36 2016 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 CDBAE12D7C9; Mon, 25 Jul 2016 04:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 CtDlaLKNn14V; Mon, 25 Jul 2016 04:32:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 9A48312D7C0; Mon, 25 Jul 2016 04:32:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BU?= =?us-ascii?q?gaNJas4gXyGHQKBODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQ?= =?us-ascii?q?JBzIUCQgCBAENBQgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMh?= =?us-ascii?q?EKDKoIvBZkoAZhZhVSQIR42g3NuiA4BfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2H9AQDQ95VX/xUHmMZeGgEBAQGCdC2BUgaNJas4gXyGHQK?= =?us-ascii?q?BODgUAQEBAQEBAQNaJ4RcAQEBAQMSKD8MBAIBCA0EBAEBCxQJBzIUCQgCBAENB?= =?us-ascii?q?QgaiA4BmxKXfgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGK4RMhEKDKoIvBZkoAZh?= =?us-ascii?q?ZhVSQIR42g3NuiA4BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,419,1464667200"; d="scan'208";a="163382577" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jul 2016 07:32:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 25 Jul 2016 07:32:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Mon, 25 Jul 2016 07:32:35 -0400 From: "Romascanu, Dan (Dan)" To: Tero Kivinen , Ralph Droms Thread-Topic: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AQHR46nuMI5CehytXkWhPvcB61QhZqAj+K2AgAUPRgA= Date: Mon, 25 Jul 2016 11:32:35 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7524F552@AZ-FFEXMB04.global.avaya.com> References: <05585A06-3FE9-433D-B1DE-F4C553F726D9@gmail.com> <22417.54627.526844.924720@fireball.acr.fi> In-Reply-To: <22417.54627.526844.924720@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 25 Jul 2016 04:33:34 -0700 Cc: Internet Area , "its@ietf.org" , "roll@ietf.org" , Suresh Krishnan , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 11:32:48 -0000 > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Friday, July 22, 2016 11:12 AM > To: Ralph Droms > Cc: Internet Area; its@ietf.org; roll@ietf.org; Suresh Krishnan; iot- > dir@ietf.org; lpwan@ietf.org; core@ietf.org; 6lo; 6tisch > Subject: Re: [6lo] [6tisch] AD sponsoring draft-kivinen-802-15-ie-02 >=20 > Ralph Droms writes: > > Seems to me this document could easily be a working group document. > > Why have you decided to publish it as AD sponsored document? >=20 > As this will allocate number for the IETF, not for just one WG, the autho= rs > though it would be better to get as wide coverage for it, meaning having > longer last call time, and advertising it in several different working gr= oups > (who might use it in the future), instead of having it for one WG draft i= n > some WG. >=20 > Also it was not clear which WG it should be in. I think 6tisch is the one= who > might need it first, but 6lo is most likely also going to using it etc. > -- > kivinen@iki.fi >=20 The last argument is relatively easy to overcome. As both 6tisch and 6lo be= long in the INT area, this could be a good candidate for a intarea WG docum= ent. I also have a slight preference for this path, as a WG document has ty= pically a better level of scrutiny and review.=20 Regards, Dan From nobody Mon Jul 25 04:44:38 2016 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 D1C8E12D7E4 for ; Mon, 25 Jul 2016 04:44:36 -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 N2twz39fHM5x for ; Mon, 25 Jul 2016 04:44:29 -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 9ED4A12D7E2 for ; Mon, 25 Jul 2016 04:44:27 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud2.xs4all.net with ESMTP id NzkR1t00H4VN29601zkR4o; Mon, 25 Jul 2016 13:44:25 +0200 Received: from 2001:983:a264:1:29f5:262:bfce:acc1 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 25 Jul 2016 13:44:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 25 Jul 2016 13:44:25 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (w5z0J1YxdXquhyeXCCbSbx6BRbuCEVgF) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 11:44:37 -0000 Dear all, Following the ROLL Meeting at IETF 96, we would like to know your opinion about the drafts, presented during IETF95 and IETF96. This is the first set of three emails. The adoption of drafts as WG drafts will be asked independently dependent on the status of the draft. A: draft-gundogan-roll-dis-modifications-00 DIS Modifications • Is the draft relevant to the working group.? • Do you foresee to contribute to the work described in the draft ? • Are you willing to review the draft ? • Should the draft be rejected by the WG ? B: draft-jadhav-roll-no-path-dao-ps-01 No-Path DAO Problem Statement • Is the draft relevant to the working group.? • Do you foresee to contribute to the work described in the draft ? • Are you willing to review the draft ? • Should the draft be rejected by the WG ? It would be nice to know the reasons why you agree or disagree with the drafts Thank you very much, Peter and Ines From nobody Mon Jul 25 23:25:51 2016 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 0274112B05B for ; Mon, 25 Jul 2016 23:25:50 -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 24p0taYsI8LU for ; Mon, 25 Jul 2016 23:25:48 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DFE126579 for ; Mon, 25 Jul 2016 23:25:47 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud3.xs4all.net with ESMTP id PJRl1t00N4SmhUa01JRlVR; Tue, 26 Jul 2016 08:25:45 +0200 Received: from 2001:983:a264:1:814f:2dc6:1186:c12b by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 26 Jul 2016 08:25:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2016 08:25:45 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20160720210832.GP7377@cisco.com> References: <20160720210832.GP7377@cisco.com> Message-ID: <3b20f2c4d3bf93a40ea4ebb82b79d0c9@xs4all.nl> X-Sender: stokcons@xs4all.nl (xfj+Xyq51RlvmyiXvtRiD56iF2eWFF4d) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] Roll: multicast use-case X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 06:25:50 -0000 Hi Toerless, > > Now maybe i am overlooking some easier app design options, but here is > how i see it: > > - I have 256 lights > - I want to switch on/off eg: some 30 of them > - To do this efficiently i need to first do a lot of signaling to > tell those 30 lights: Pls. join this multicast group .. so that > later on i can efficiently send you a command to turn on/off. > - So ultimately i'd need to upfront assign a multicast group to every > desired subset of lights, signal to every light the subset groups > it is > a member off, have to maintain on every last-hop forwarder the MLD > member state for all these groups, and yeah, now i can start > sending > efficient multicast packets to the desired subsets. Up till here, I do follow But below, I am lost. There are lots of techniques and PHY/MACs to handle these complexities > - And i can forget more interesting lighting effects because i'll > never be able to have > even a reasonable percentage of subset groups of all lights i could > address. > - So then i want these effects, and i start broadcasting packets to > just every light, and the app-level of those packets will have a > bitstring > of which lights should act upon the packet. And we just created a > whole > useless level of complexity that had to be ignored because of IP > multicast scale limits and repeated inside in the app layer. > > This is just silly. > > What IMHO we really need is to throw out IP multicast and just use > end-to-end > BIER: Sender sends BIER packet, every bit is a possible receiver. I do agree with your conclusion. The same is true for MPL. The source sends to a multicast address; the wanted receiver interfaces are enabled for it. which is end-to-end MPL. We need to compare the feasibility of these alternatives: end-to-end delays reliability how easy/difficult to set up (commissioning) network loading > My original interest in the Bier RPL Mcast is the destination encoding in the header I thought it might be applied to reduce the source routing UNICAST headers used for the non-storing mode of RPL. Peter From nobody Mon Jul 25 23:50:01 2016 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 CB53812B014 for ; Mon, 25 Jul 2016 23:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fiGY7unntcHs for ; Mon, 25 Jul 2016 23:49:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546CD126579 for ; Mon, 25 Jul 2016 23:49:57 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A8B2422C9EA; Tue, 26 Jul 2016 08:49:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.62]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8868027C064; Tue, 26 Jul 2016 08:49:55 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 08:49:55 +0200 From: To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" Thread-Index: AQHR5mnuZVZh9kXVPkqOBOD3GmmhkqAqRv+A Date: Tue, 26 Jul 2016 06:49:54 +0000 Message-ID: <6190_1469515795_57970813_6190_1288_1_D3BCD406.37945%dominique.barthel@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1DDE9837151CEB47BB0C55B5CE4DF9C8@adroot.infra.ftgroup> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 06:50:00 -0000 Dear all, I support the adoption of both draft-gundogan-roll-dis-modifications-00 and draft-jadhav-roll-no-path-dao-ps-01 I think they both will help make RPL better in all sorts of environments. I foresee a contribution to the first one, and a review of both. Thanks Dominique Le 25/07/16 13:44, =AB Roll on behalf of peter van der Stok =BB a =E9crit : >Dear all, > >Following the ROLL Meeting at IETF 96, we would like to know your >opinion about the drafts, presented during IETF95 and IETF96. This is >the first set of three emails. The adoption of drafts as WG drafts >will be asked independently dependent on the status of the draft. > >A: draft-gundogan-roll-dis-modifications-00 > DIS Modifications > >=80 Is the draft relevant to the working group.? >=80 Do you foresee to contribute to the work described in the draft ? >=80 Are you willing to review the draft ? >=80 Should the draft be rejected by the WG ? > >B: draft-jadhav-roll-no-path-dao-ps-01 > No-Path DAO Problem Statement > >=80 Is the draft relevant to the working group.? >=80 Do you foresee to contribute to the work described in the draft ? >=80 Are you willing to review the draft ? >=80 Should the draft be rejected by the WG ? > > >It would be nice to know the reasons why you agree or disagree with the >drafts > > >Thank you very much, > >Peter and Ines > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 26 03:39:08 2016 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 83AD512D5AE for ; Tue, 26 Jul 2016 03:39: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=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 FRN4a2kzz5Aw for ; Tue, 26 Jul 2016 03:39:04 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789F312D1C0 for ; Tue, 26 Jul 2016 03:39:04 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m101so11671187ioi.2 for ; Tue, 26 Jul 2016 03:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vLssniL4gC21mE+Sp5dsgO/bkEQJQvZQKZbX2E2wY9o=; b=XVogbmB/O4RtzJGZRyTNDaCoIUI9XlKqJ4wR6GGyiJCeHkID4ox1WRJt1+Fl/FSVPt y2lX+SddGCTZ5t++B14Ut1OCPVg3Nx8UqUzzIBWd4Wl1/5VkNAyEiAmXuwskHpV0eKGn ME7Ieh7yxZgnJw8tGgPmmyC9R2QNNK2EhWtqumVuv8M6QgW5zkzJeEvSXwfkuy+DTuZC CWcKfDelShUeHBxX/LbjRx1gsGfkL5RrD6wmycT8FdWmptfaiRLbHFOILuciLkIt7SE7 wGaQoWyHMlzLTpx5VIcOoQrkRunmNQZ3HndaXzD9WmhaTOja/Vd+b7JbAi668JQYXMMK oKXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vLssniL4gC21mE+Sp5dsgO/bkEQJQvZQKZbX2E2wY9o=; b=UZ//m/UUyZk8Sl9/EMee4Q2EQVBdhugScktLSfpsiO+jqTtZQc4LbiUomuJBJgcbAO OjOCfHYJIEInjUOqN8isAdVgoQEK3qjbGCNM9lmVJUgQSInsJaPvQGzu90MSu9+enL6k fEm0t2EDQc4x2ywk9wkY2Ldws9U2HN/V+6mh5ZAiVDxvnUmNhJkKVoWBO0YQsI8Ly9xX aHrb6Vg3qXvBc84Q8crorRZOKY4pEQfEFxZCMDy3atCAxZG3x54RZVIUYhvJrfdL0Tes MLiAJd+wZaF/U8avLB1KJKri827fPGk2VdoVYRLdLqBUGDXR6LhRw1B1Fi6n7ST7Q5zx UQUQ== X-Gm-Message-State: AEkoouv3hGAJWiguhnt7f9pxqYZI9KnRAqgh1Edg8AnR52Bb1n3wTf9dpB7wfSM98z3pzjbRYnx8LDsvmll6eQ== MIME-Version: 1.0 X-Received: by 10.202.239.69 with SMTP id n66mr12653209oih.108.1469529543607; Tue, 26 Jul 2016 03:39:03 -0700 (PDT) Received: by 10.202.181.193 with HTTP; Tue, 26 Jul 2016 03:39:03 -0700 (PDT) Received: by 10.202.181.193 with HTTP; Tue, 26 Jul 2016 03:39:03 -0700 (PDT) In-Reply-To: <6190_1469515795_57970813_6190_1288_1_D3BCD406.37945%dominique.barthel@orange.com> References: <6190_1469515795_57970813_6190_1288_1_D3BCD406.37945%dominique.barthel@orange.com> Date: Tue, 26 Jul 2016 12:39:03 +0200 Message-ID: From: Rahul Jadhav To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=94eb2c09411e6f0caa05388782bf Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 10:39:06 -0000 --94eb2c09411e6f0caa05388782bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I too support both the drafts. Please note I m a co-author for the later (no-path dao) draft. A: draft-gundogan-roll-dis-modifications-00 =E2=80=A2 Is the draft relevant to the working group.? Yes. The draft aims at reducing control overhead in RPL signaling. I m especially interested in the reduction of DIO network footprint proposed in the draft. =E2=80=A2 Do you foresee to contribute to the work described in the draf= t ? Yes. I could help in testing the draft. =E2=80=A2 Are you willing to review the draft ? Yes =E2=80=A2 Should the draft be rejected by the WG ? No B: draft-jadhav-roll-no-path-dao-ps-01 =E2=80=A2 Is the draft relevant to the working group.? Yes. The draft aims to characterize and improve upon existing no-path DAO messaging. =E2=80=A2 Do you foresee to contribute to the work described in the draf= t ? Yes. I intend to find a tech soln for the problem stmt and test it in simulation/real deployments. =E2=80=A2 Are you willing to review the draft ? Yes. As a co-author. =E2=80=A2 Should the draft be rejected by the WG ? No -Rahul On 26 Jul 2016 12:20 p.m., wrote: > Dear all, > > I support the adoption of both draft-gundogan-roll-dis-modifications-00 > and draft-jadhav-roll-no-path-dao-ps-01 > I think they both will help make RPL better in all sorts of environments. > I foresee a contribution to the first one, and a review of both. > Thanks > > Dominique > > Le 25/07/16 13:44, =C2=AB Roll on behalf of peter van der Stok =C2=BB > a =C3=A9crit : > > >Dear all, > > > >Following the ROLL Meeting at IETF 96, we would like to know your > >opinion about the drafts, presented during IETF95 and IETF96. This is > >the first set of three emails. The adoption of drafts as WG drafts > >will be asked independently dependent on the status of the draft. > > > >A: draft-gundogan-roll-dis-modifications-00 > > DIS Modifications > > > >=E2=82=AC Is the draft relevant to the working group.? > >=E2=82=AC Do you foresee to contribute to the work described in the d= raft ? > >=E2=82=AC Are you willing to review the draft ? > >=E2=82=AC Should the draft be rejected by the WG ? > > > >B: draft-jadhav-roll-no-path-dao-ps-01 > > No-Path DAO Problem Statement > > > >=E2=82=AC Is the draft relevant to the working group.? > >=E2=82=AC Do you foresee to contribute to the work described in the d= raft ? > >=E2=82=AC Are you willing to review the draft ? > >=E2=82=AC Should the draft be rejected by the WG ? > > > > > >It would be nice to know the reasons why you agree or disagree with the > >drafts > > > > > >Thank you very much, > > > >Peter and Ines > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --94eb2c09411e6f0caa05388782bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I too support both the drafts.
Please note I m a co-author for the later (no-path dao) draft.

A: draft-gundogan-roll-dis-modifications-00
=E2=80=A2=C2=A0=C2=A0=C2=A0 Is the draft relevant to the working group.? Yes. The draft aims at reducing control overhead in RPL signaling. I m espe= cially interested in the reduction of DIO network footprint proposed in the= draft.
=E2=80=A2=C2=A0=C2=A0=C2=A0 Do you foresee to contribute to the work descri= bed in the draft ?
Yes. I could help in testing the draft.
=E2=80=A2=C2=A0=C2=A0=C2=A0 Are you willing to review the draft ?
Yes
=E2=80=A2=C2=A0=C2=A0=C2=A0 Should the draft be rejected by the WG ?
No

B: draft-jadhav-roll-no-path-dao-ps-01
=E2=80=A2=C2=A0=C2=A0=C2=A0 Is the draft relevant to the working group.? Yes. The draft aims to characterize and improve upon existing no-path DAO m= essaging.
=E2=80=A2=C2=A0=C2=A0=C2=A0 Do you foresee to contribute to the work descri= bed in the draft ?
Yes. I intend to find a tech soln for the problem stmt and test it in simul= ation/real deployments.
=E2=80=A2=C2=A0=C2=A0=C2=A0 Are you willing to review the draft ?
Yes. As a co-author.
=E2=80=A2=C2=A0=C2=A0=C2=A0 Should the draft be rejected by the WG ?
No

-Rahul


On 26 Jul 2016 12= :20 p.m., <dominique.ba= rthel@orange.com> wrote:
Dear all,

I support the adoption of both draft-gundogan-roll-dis-modifications-00
and draft-jadhav-roll-no-path-dao-ps-01
I think they both will help make RPL better in all sorts of environments. I foresee a contribution to the first one, and a review of both.
Thanks

Dominique

Le 25/07/16 13:44, =C2=AB Roll on behalf of peter van der Stok =C2=BB
<roll-bounces@ietf.org on b= ehalf of stokcons@xs4all.nl> a= =C3=A9crit :

>Dear all,
>
>Following the ROLL Meeting at IETF 96, we would like to know your
>opinion about the drafts, presented during IETF95 and IETF96. This is >the first set of three emails. The adoption of drafts as WG drafts
>will be asked independently dependent on the status of the draft.
>
>A: draft-gundogan-roll-dis-modifications-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DIS Modifications
>
>=E2=82=AC=C2=A0 =C2=A0 Is the draft relevant to the working group.?
>=E2=82=AC=C2=A0 =C2=A0 Do you foresee to contribute to the work describ= ed in the draft ?
>=E2=82=AC=C2=A0 =C2=A0 Are you willing to review the draft ?
>=E2=82=AC=C2=A0 =C2=A0 Should the draft be rejected by the WG ?
>
>B: draft-jadhav-roll-no-path-dao-ps-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0No-Path DAO Problem Statement
>
>=E2=82=AC=C2=A0 =C2=A0 Is the draft relevant to the working group.?
>=E2=82=AC=C2=A0 =C2=A0 Do you foresee to contribute to the work describ= ed in the draft ?
>=E2=82=AC=C2=A0 =C2=A0 Are you willing to review the draft ?
>=E2=82=AC=C2=A0 =C2=A0 Should the draft be rejected by the WG ?
>
>
>It would be nice to know the reasons why you agree or disagree with the=
>drafts
>
>
>Thank you very much,
>
>Peter and Ines
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--94eb2c09411e6f0caa05388782bf-- From nobody Tue Jul 26 14:40:56 2016 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 E554D12D9BD for ; Tue, 26 Jul 2016 14:40:37 -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, 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 qeZkAp_dAl92 for ; Tue, 26 Jul 2016 14:40:34 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 45A8812D9BB for ; Tue, 26 Jul 2016 14:40:27 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 35so5459649uap.1 for ; Tue, 26 Jul 2016 14:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Q1LGlq+8KBxk+FxdSIIFpPcZdrcsl6aWr69jdsOsn5Y=; b=1BfiMB+TMy+bgFn+G56g+QAKWgZt+a+WWbEahOgvC8s+Y6D8jYAHaJxhTHwbpUC99M 0veAZJXSan9Ydzd8NSccwZs7pRTjVz6wDGClqsgiAjZQmr2ij1nIJOYniE+eMjqHH36L /Gvei6oyIU/CBYhTTzZJdY+MQE1ctfvvvCqwYdonGRCQsV1OZKHf0AcObHkDD2fdYGGW mgAunaXPqVMEa49JDD3enZsF+rPjyTHi+3q8hurwEVkxyc/j2SIlzUZEXeits9n16zWU /z2Hxiw/E3S1UKf5asmFE2QsFilYQqj+DsdRG3ki6OuvQ3wIZUsfHoJMttk2MOMqQkp1 ti0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Q1LGlq+8KBxk+FxdSIIFpPcZdrcsl6aWr69jdsOsn5Y=; b=PdZ6whOWKUQCfoKcAwRtp5Udt0MjJBG6YnQw1HD2ylfI123mue9CPvkr/AB/XntmPL 3RnDxwJwpdEXJjdfNpAWDJH0lmB4mJAzYGXWZT0eaUjAh/6ia9Wp8eITScO273iYXW49 NsJ6cv0CN54NIePg2xwoAyM19ikc9id0Q16V/zEaPkBf5cbTLYBk7V0obFoY23gzgztZ oxGYNBfyAtyJ0Fw2YboVvozA1DNNOKtrWFYZbQK/XTC8NYuSt50pGHLqM3s1fhDmiZ4i r0txEhuTImNsSrgU4UhwQU+NsgCH08YThfGPfTzpz7bMdaKG5bY5gCQ0XIe97/GB/lQI 9wjQ== X-Gm-Message-State: AEkooussJMXVeRETA7ufo5W1RlI1GZGinIlMdSPpwW0rPOUCpvEf9OTYsPcJfuztnM/ZtOzqYGjWd8V+E1aYmA== X-Received: by 10.176.4.162 with SMTP id 31mr11392217uaw.81.1469569226117; Tue, 26 Jul 2016 14:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.241 with HTTP; Tue, 26 Jul 2016 14:40:25 -0700 (PDT) In-Reply-To: References: From: Ines Robles Date: Wed, 27 Jul 2016 00:40:25 +0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=94eb2c125290b21893053890bf65 Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 21:40:38 -0000 --94eb2c125290b21893053890bf65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, As an individual (co-chair hat off), I support to include in the charter The DIS Modifications work. It would be interesting to see the performance of the new DIS flags and the selectivity of multicast DIS messages. I am willing to review the draft. I support to include the No-Path DAO work as well. It is relevant to work on the solutions to the problems of No-Path DAO messaging. I am willing to review the draft. Thanks to the authors for proposing these works, Cheers, Ines. 2016-07-25 14:44 GMT+03:00 peter van der Stok : > Dear all, > > Following the ROLL Meeting at IETF 96, we would like to know your > opinion about the drafts, presented during IETF95 and IETF96. This is > the first set of three emails. The adoption of drafts as WG drafts > will be asked independently dependent on the status of the draft. > > A: draft-gundogan-roll-dis-modifications-00 > DIS Modifications > > =E2=80=A2 Is the draft relevant to the working group.? > =E2=80=A2 Do you foresee to contribute to the work described in the dr= aft ? > =E2=80=A2 Are you willing to review the draft ? > =E2=80=A2 Should the draft be rejected by the WG ? > > B: draft-jadhav-roll-no-path-dao-ps-01 > No-Path DAO Problem Statement > > =E2=80=A2 Is the draft relevant to the working group.? > =E2=80=A2 Do you foresee to contribute to the work described in the dr= aft ? > =E2=80=A2 Are you willing to review the draft ? > =E2=80=A2 Should the draft be rejected by the WG ? > > > It would be nice to know the reasons why you agree or disagree with the > drafts > > > Thank you very much, > > Peter and Ines > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --94eb2c125290b21893053890bf65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As an individual (co-cha= ir hat off), I support to include in the charter The DIS Modifications work= . It would be interesting to see the performance of the new DIS flags and t= he selectivity of multicast DIS messages. I am willing to review the draft.=

I support to include the No-Path DAO work as well= . It is relevant to work on the solutions to the problems of No-Path DAO me= ssaging. I am willing to review the draft.

Thanks = to the authors for proposing these works,

Cheers,<= /div>

Ines.

2016-07-25 14:44 GMT+03:00 peter van der Stok <stokco= ns@xs4all.nl>:
Dear all,
Following the ROLL Meeting at IETF 96, we would like to know your
opinion about the drafts, presented during IETF95 and IETF96. This is
the first set of three emails. The adoption of drafts as WG drafts
will be asked independently dependent on the status of the draft.

A: draft-gundogan-roll-dis-modifications-00
=C2=A0 =C2=A0 =C2=A0 DIS Modifications

=E2=80=A2=C2=A0 =C2=A0 Is the draft relevant to the working group.?
=E2=80=A2=C2=A0 =C2=A0 Do you foresee to contribute to the work described i= n the draft ?
=E2=80=A2=C2=A0 =C2=A0 Are you willing to review the draft ?
=E2=80=A2=C2=A0 =C2=A0 Should the draft be rejected by the WG ?

B: draft-jadhav-roll-no-path-dao-ps-01
=C2=A0 =C2=A0 =C2=A0 No-Path DAO Problem Statement

=E2=80=A2=C2=A0 =C2=A0 Is the draft relevant to the working group.?
=E2=80=A2=C2=A0 =C2=A0 Do you foresee to contribute to the work described i= n the draft ?
=E2=80=A2=C2=A0 =C2=A0 Are you willing to review the draft ?
=E2=80=A2=C2=A0 =C2=A0 Should the draft be rejected by the WG ?


It would be nice to know the reasons why you agree or disagree with the dra= fts


Thank you very much,

Peter and Ines

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

--94eb2c125290b21893053890bf65-- From nobody Wed Jul 27 00:16:44 2016 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 5AA7312D0A6 for ; Wed, 27 Jul 2016 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 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=-1.287, 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 Zl79DC5d5Lle for ; Wed, 27 Jul 2016 00:16:40 -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 CE6E712D5C2 for ; Wed, 27 Jul 2016 00:16:39 -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 CTG85027; Wed, 27 Jul 2016 07:16:36 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jul 2016 08:16:35 +0100 Received: from SZXEML592-MBS.china.huawei.com ([169.254.4.58]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Wed, 27 Jul 2016 15:15:54 +0800 From: "Zuojing (2012 Laboratories)" To: "roll@ietf.org" Thread-Topic: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" Thread-Index: AdHn1rSQkFg4xTDYROO+KvCcGqQmew== Date: Wed, 27 Jul 2016 07:15:54 +0000 Message-ID: <4AD902A48032F745A3D7866E6CAE8CB0641C6A59@szxeml592-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.113] Content-Type: multipart/alternative; boundary="_000_4AD902A48032F745A3D7866E6CAE8CB0641C6A59szxeml592mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57985FD5.00F2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.58, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7704c87ccc6130f05bd7ef003c75cc69 Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 07:16:42 -0000 --_000_4AD902A48032F745A3D7866E6CAE8CB0641C6A59szxeml592mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I support the adoption of both drafts as WG drafts and I would be very happ= y to review them if required. DIS Modifications helps to reduce the RPL control overhead and nopath DAO c= an help to solve the problem stated in current RPL specification regarding = non-optimal NPDAO messaging. Hence, both of them could contribute to the RP= L environment. Kind regards, Jing Jing Zuo Huawei Technologies Co., Ltd. Mobile: +86 186 1704 8515 Email: jing.zuo@huawei.com Address: Bantian, Longgang District,Shenzhen 518129, P.R.China Website: http://www.huawei.com --_000_4AD902A48032F745A3D7866E6CAE8CB0641C6A59szxeml592mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I support the adoption of bo= th drafts as WG drafts and I would be very happy to review them if required= .

DIS Modifications helps to r= educe the RPL control overhead and nopath DAO can help to solve the problem= stated in current RPL specification regarding non-optimal NPDAO messaging.= Hence, both of them could contribute to the RPL environment.

 

Kind regards,

Jing

 

 

 

Jing Zu= o

Huawei Technologies Co., Ltd.
Mobile: +86 186 1704 8515
Email: ji= ng.zuo@huawei.com

Address: Bantian, Longgang District,Shenzhen 518= 129, P.R.China
Website: http:= //www.huawei.com

 

--_000_4AD902A48032F745A3D7866E6CAE8CB0641C6A59szxeml592mbschi_-- From nobody Wed Jul 27 02:28:27 2016 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 32E5D12D699 for ; Wed, 27 Jul 2016 02:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 AOKvwbDQPcNL for ; Wed, 27 Jul 2016 02:28:23 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3437912B039 for ; Wed, 27 Jul 2016 02:28:23 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id l32so13235462ual.2 for ; Wed, 27 Jul 2016 02:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=vkNplgeMKoixaUqceca8O3LQMb5qEpG8sXh8ZiW6mb0=; b=mVQbLweGfeFpE8PSA6vaXjRSbn509nthfeNiPybqit1rr1Kem9brUeVz2bu5Gj1syE yalvc2Jipww3LftWUgtudpMFk9DoZJ3wFme7JXHyoE7FHi86og2/4kV8JA2OFi8gZmV6 SZhPq6oCJaUr5QDmyn3+/s3uzc8QRx0R7VXmbxPxPw/SYSgCO1jKa9sUxTlt8ULH36rM lft0k4lRnu2ZMBbGNuQ/65V1ZV/EggPFYhuZMI4R/hm8N6rxy3lWJglkc5k3MxCNiJ7R 1JieDAOM9A9Tub1iKkACLO7Itzg3o2/JFoeKVge5psafaUWdPDYGRB99c5GvdvCSAMRU RN/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=vkNplgeMKoixaUqceca8O3LQMb5qEpG8sXh8ZiW6mb0=; b=gjg4MtKr86Squjju+Jh3BAyWuJjOI/TVRY/9QPP6vlVQbUrP/R1dSCPXeDNy8xY4rp hjhKUwsxvEXWoitBcVGlI7aQJXhVgSoQGnIROaNxGbsZOe5daebwwkST/UHtGYb2J+S2 L7diJpZ8El837Dfj2UZeQaANUo0/zLrC3YVhPNrwr8vjecqLlXLTmzSmVTSmpZ7OdjtJ s5asenM+eogGY4ghG2RTqc5TP/HZ3Xu7b3jVWLrZuVmiWOdYf3wjjJA8UFTPmdMyFsgw YMV9LZZqXCtvbbk1Zn94ZjoVkIBzw2EXmRmSOBmV3ZODYl69yijWHbAgg8G10D3tTezg g4VQ== X-Gm-Message-State: AEkooutQaAdUUxO+tVVLvsr12j0ClgjOD1no3zVbYsY+peSJRH7TQl3D9PYscHrdXxSL5iPMdJQpVqJ1yywfGQ== X-Received: by 10.176.69.210 with SMTP id u76mr10217057uau.16.1469611701953; Wed, 27 Jul 2016 02:28:21 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.159.35.82 with HTTP; Wed, 27 Jul 2016 02:28:02 -0700 (PDT) In-Reply-To: <4AD902A48032F745A3D7866E6CAE8CB0641C6A59@szxeml592-mbs.china.huawei.com> References: <4AD902A48032F745A3D7866E6CAE8CB0641C6A59@szxeml592-mbs.china.huawei.com> From: Emmanuel Baccelli Date: Wed, 27 Jul 2016 11:28:02 +0200 X-Google-Sender-Auth: kyXzTdVnUeZfCxn07wzZHzc0Ca4 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=94eb2c11c30473ef5905389aa3aa Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 09:28:25 -0000 --94eb2c11c30473ef5905389aa3aa Content-Type: text/plain; charset=UTF-8 Hi everyone, I also support both drafts. (I'm co-authoring one and would be ready to review the other one). Best, Emmanuel On Wed, Jul 27, 2016 at 9:15 AM, Zuojing (2012 Laboratories) < jing.zuo@huawei.com> wrote: > Dear all, > > > > I support the adoption of both drafts as WG drafts and I would be very > happy to review them if required. > > DIS Modifications helps to reduce the RPL control overhead and nopath DAO > can help to solve the problem stated in current RPL specification regarding > non-optimal NPDAO messaging. Hence, both of them could contribute to the > RPL environment. > > > > Kind regards, > > Jing > > > > > > > > Jing Zuo > > Huawei Technologies Co., Ltd. > Mobile: +86 186 1704 8515 > Email: jing.zuo@huawei.com > > Address: Bantian, Longgang District,Shenzhen 518129, P.R.China > Website: http://www.huawei.com > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --94eb2c11c30473ef5905389aa3aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,
I also support both drafts.
(I&= #39;m co-authoring one and would be ready to review the other one).
Best,
Emmanuel

On Wed, Jul 27, 2016 at 9:15 AM, Zuojing (2012 Labora= tories) <jing.zuo@huawei.com> wrote:

Dear all,<= /p>

=C2=A0

I support the adoption of both drafts as WG drafts = and I would be very happy to review them if required.<= /p>

DIS Modifications helps to reduce the RPL control o= verhead and nopath DAO can help to solve the problem stated in current RPL = specification regarding non-optimal NPDAO messaging. Hence, both of them co= uld contribute to the RPL environment.

=C2=A0

Kind regards,

Jing

=C2=A0

=C2=A0

=C2=A0

Jing Zu= o

Huawei Technologies Co., Ltd.
Mobile: +86 186 1704 8515
Email: jing.zuo@huawei.com

Address: Bantian, Longgang District,Shenzhen 518= 129, P.R.China
Website: http://www.huawei.com

=C2=A0


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


--94eb2c11c30473ef5905389aa3aa-- From nobody Thu Jul 28 03:16:37 2016 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 A9DE312DE63 for ; Thu, 28 Jul 2016 03:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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=-1.287, 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 TIikyMq_W0cF for ; Thu, 28 Jul 2016 03:16:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A651412DE49 for ; Thu, 28 Jul 2016 03:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1469700994; x=1470910594; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FjF/3owGQ8f/vv66qiox6ElY4QvHDQ/U9u7KdoZ1los=; b=JqXUgueJ1CzgsmmdR8ldGn0gfsbvNYb0Gbti3tzpJq4uAQh0x4iP9cRK hKTJNqnS0GCCAVZuFcsb5faAt2tEyamI/Q7+zMy3Gu8RHDYy1H6e9X7oC 9rsBCqC7fyw44RFU4c2KKNbohgyCE1fvLPoHle0Yl8AKv7Z7xeDF3tyWq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgBW2plX/5pdJa1dg0WBWLhsgX2GH?= =?us-ascii?q?QIcgR04FAEBAQEBAQFdJ4RcAQEEASMRSgsCAQgaAiYCAgIwFRACBBuIIQiuJ41?= =?us-ascii?q?RAQEBAQEBAQMBAQEBAQEBIIEBhSmETYdBgloFiDCHGoQmhUIBjnWPRpAlAR42g?= =?us-ascii?q?WZfgTWIZn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,433,1464652800"; d="scan'208";a="302619911" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2016 10:16:33 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6SAGXWV027056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Jul 2016 10:16:33 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 28 Jul 2016 05:16:33 -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, 28 Jul 2016 05:16:32 -0500 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" Thread-Index: AQHR5mnvtJfRNsl3Kki/hSk7uVfyyKAtpFUw Date: Thu, 28 Jul 2016 10:16:21 +0000 Deferred-Delivery: Thu, 28 Jul 2016 10:16:14 +0000 Message-ID: <1092c21d76024722b1e865be879e5dab@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.61.218.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS Mod. - No-Path DAO" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 10:16:37 -0000 IA0KPiBGb2xsb3dpbmcgdGhlIFJPTEwgTWVldGluZyBhdCBJRVRGIDk2LCB3ZSB3b3VsZCBsaWtl IHRvIGtub3cgeW91ciBvcGluaW9uDQo+IGFib3V0IHRoZSBkcmFmdHMsIHByZXNlbnRlZCBkdXJp bmcgSUVURjk1IGFuZCBJRVRGOTYuIFRoaXMgaXMgdGhlIGZpcnN0IHNldCBvZg0KPiB0aHJlZSBl bWFpbHMuIFRoZSBhZG9wdGlvbiBvZiBkcmFmdHMgYXMgV0cgZHJhZnRzIHdpbGwgYmUgYXNrZWQg aW5kZXBlbmRlbnRseQ0KPiBkZXBlbmRlbnQgb24gdGhlIHN0YXR1cyBvZiB0aGUgZHJhZnQuDQo+ IA0KPiBBOiBkcmFmdC1ndW5kb2dhbi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLTAwDQo+ICAgICAg ICBESVMgTW9kaWZpY2F0aW9ucw0KPiANCj4g4oCiICAgIElzIHRoZSBkcmFmdCByZWxldmFudCB0 byB0aGUgd29ya2luZyBncm91cC4/DQoNClllcy4gVGhpcyB3aWxsIGltcHJvdmUgdGhlIFJQTCBv cGVyYXRpb24uIFVuc3VyZSB3aGV0aGVyIHRoZSBjbGllbnQgc2hvdWxkIGFsd2F5cyB3ZSBwcm9w b3NpbmcgdGhlIGJpdCBzZXR0aW5ncy4gUHJvYmFibHkgaW4gc29tZSBpbnN0YW5jZXMgdGhlIHJv dXRlciBrbm93cyBiZXR0ZXIuDQoNCj4g4oCiICAgIERvIHlvdSBmb3Jlc2VlIHRvIGNvbnRyaWJ1 dGUgdG8gdGhlIHdvcmsgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCA/DQoNCk5vDQoNCj4g4oCiICAg IEFyZSB5b3Ugd2lsbGluZyB0byByZXZpZXcgdGhlIGRyYWZ0ID8NCg0KWWVzDQoNCj4g4oCiICAg IFNob3VsZCB0aGUgZHJhZnQgYmUgcmVqZWN0ZWQgYnkgdGhlIFdHID8NCg0KQ2VydGFpbmx5IG5v dCENCg0KPiANCj4gQjogZHJhZnQtamFkaGF2LXJvbGwtbm8tcGF0aC1kYW8tcHMtMDENCj4gICAg ICAgIE5vLVBhdGggREFPIFByb2JsZW0gU3RhdGVtZW50DQo+IA0KPiDigKIgICAgSXMgdGhlIGRy YWZ0IHJlbGV2YW50IHRvIHRoZSB3b3JraW5nIGdyb3VwLj8NCg0KWWVzDQoNCj4g4oCiICAgIERv IHlvdSBmb3Jlc2VlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIHdvcmsgZGVzY3JpYmVkIGluIHRoZSBk cmFmdCA/DQoNCk1heWJlDQoNCj4g4oCiICAgIEFyZSB5b3Ugd2lsbGluZyB0byByZXZpZXcgdGhl IGRyYWZ0ID8NCg0KWWVzDQoNCj4g4oCiICAgIFNob3VsZCB0aGUgZHJhZnQgYmUgcmVqZWN0ZWQg YnkgdGhlIFdHID8NCg0KVW5zdXJlIHRoZSBQUyBzaG91bGQgZ28gUkZDLiBJbiBmYWN0IGFuIGVy cmF0YSB0byBSRkMgNjU1MCBtYXkgc3VmZmljZQ0KDQogOiApDQoNClBhc2NhbA0K From nobody Fri Jul 29 00:23:45 2016 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 E149B12D099 for ; Fri, 29 Jul 2016 00:23:43 -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 IIAbSp4culX3 for ; Fri, 29 Jul 2016 00:23:41 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0FF12B04C for ; Fri, 29 Jul 2016 00:23:41 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.213]) by smtp-cloud3.xs4all.net with ESMTP id QXPf1t0054bqPqS01XPfdN; Fri, 29 Jul 2016 09:23:39 +0200 Received: from 2001:983:a264:1:f145:e579:90df:b2a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 29 Jul 2016 09:23:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 29 Jul 2016 09:23:39 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <1071131a33c924ddca105e42ae68313b@xs4all.nl> X-Sender: stokcons@xs4all.nl (afLbg2BTk5yt0ixDjT+gQjAhjAjJV3mo) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] "Charter inclusion: Work in Multicast: Forward selec - BIER CCAST - MPL YANG" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:23:44 -0000 Hi all, Following the ROLL Meeting at IETF 96, we would like to know your opinion about the drafts, presented during IETF95 and IETF96. This is the second of three messages. The adoption of drafts as WG drafts will be asked independently dependent on the status of the draft. C: draft-vanderstok-roll-mpl-forw-select-00 MPL Forwarder Select (MPLFS) • Is the draft relevant to the working group.? • Do you foresee to contribute to the work described in the draft ? • Are you willing to review the draft ? • Should the draft be rejected by the WG ? D: draft-bergmann-bier-ccast Source-Routed Multicast for RPL - • Is the draft relevant to the working group.? • Do you foresee to contribute to the work described in the draft ? • Are you willing to review the draft ? • Should the draft be rejected by the WG ? E: draft-vanderstok-roll-mpl-yang-01 A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) • Is the draft relevant to the working group.? • Do you foresee to contribute to the work described in the draft ? • Are you willing to review the draft ? • Should the draft be rejected by the WG ? It would be nice to know the reasons why you agree or disagree with the drafts Thank you very much, Peter and Ines