From nobody Sun Jan 4 04:00:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403891A8710; Sun, 4 Jan 2015 03:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.381 X-Spam-Level: X-Spam-Status: No, score=-98.381 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, THIS_AD=0.819, USER_IN_WHITELIST=-100] autolearn=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 9GDJjGHgDWHn; Sun, 4 Jan 2015 03:59:57 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B1F1A87E3; Sun, 4 Jan 2015 03:59:56 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04BxtC1027462; Sun, 4 Jan 2015 11:59:55 GMT Received: from 950129200 (089144214152.atnat0023.highway.a1.net [89.144.214.152]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04Bxq4N027451 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 11:59:53 GMT From: "Adrian Farrel" To: "'Routing Over Low power and Lossy networks'" References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <54942758.6090705@innovationslab.net> <549440F0.8040407@innovationslab.net> <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org> <12622.1420055894@sandelman.ca> In-Reply-To: <12622.1420055894@sandelman.ca> Date: Sun, 4 Jan 2015 11:59:52 -0000 Message-ID: <000701d02815$f43df5f0$dcb9e1d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDYSrdREYQBBbqMEJ13pvROSVU0ZwFOrF3lAq5NWmYCDPN/2QIHrEpgAnP0kfoCE4LtBAH8RX/fnirl8mA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.006 X-TM-AS-Result: No--12.096-10.0-31-10 X-imss-scan-details: No--12.096-10.0-31-10 X-TMASE-MatchedRID: X4bcv0S75KlfsB4HYR80ZuYAh37ZsBDC9Pf8r56P8OiqvcIF1TcLYMNG 97DfmZl73ucgpE8r324LCX72pQ57z7mvMSppeWbN3/BiYwVwlIgJDfFL7Mvp7focnZ1sVcITTeW AzLg7201bizXT95VspZznAshKWsZCD71CZKFRa8Ld+fuf9kcapl3KZkFy4YZEQQ1XgvCe7sG0cU TKeVbLpDw2VCzpS/odKAsRrYCoSQzJQQZfFiWFP2iYls8x2M90fkuZtv/FS5rFJnEpmt9OE5HI/ wLXJM6E94TFEi/V+KrNN/jZbR84GVgD5mh+pVM14nbwqqmOd2kIKlg5gvgW3Lv408/GP5HqV3F3 xxDh6Cu4ZfkBlKsszRBsLigpdrdHnyr1pF6DLcRWeFNzK1vl0n0tCKdnhB581kTfEkyaZdz6C0e Ps7A07SQvY0ueKrc1OQXtnknU6N0rqvWELjUtyykqqCDox+4bXnjHx8W4ea8= Archived-At: http://mailarchive.ietf.org/arch/msg/roll/jScd9D3Iyy56wOoxWDJLLSF5dXE Cc: 6man-chairs@tools.ietf.org, int-ads@tools.ietf.org, 6tisch@ietf.org, 6lo-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 04 Jan 2015 11:59:59 -0000 Michael, Thanks for continuing to try to wrangle this situation. > someone wrote; > >> So, it seems prudent (to me) to look at each of the = alternatives and > >> determine which warts everyone concerned is willing to live = with. > >> Running code is a good way to do that. >=20 > Carsten Bormann wrote: > > I agree with Xavi here: This is a good way to gather data for > > implementation issues (such as the implementation complexity of = the > > =E2=80=9Cefficient=E2=80=9D variant of the NHC approach). It is = not so good >=20 > so, I think that we have consensus that this can not be left to the = plugfest. I understand that the plugfest has to have a baseline: you can't arrive = at the plugfest with lots of implementations of different things! On the other hand, I don't think that the WG has to agree what the = plugfest will do. I think it is fine for some group of people to make = that agreement (by all means point at existing I-Ds or even write a = brief I-D or wiki page saying "this is what we will test"). If everyone has energy, the plugfest could even test more than one = approach. > A number of people have not replied; some ADs and some WG chairs. > (I realize that Gabriel Montenegro is new in this position; maybe he = can > bring a fresh viewpoint?) Is there a specific question you'd like this AD to answer? > I am going to put up a doodle poll for the week of Jan. 12. > My goal is not to need it, that we will have a plan for the Jan 9, = 6tisch > call. I didn't see anything further on this. > Please: how do we proceed? Consensus can sometimes be hard-won and slow. It is one of the things = that makes people claim the IETF is slow. On the other hand, the = alternative to consensus is, erm, no consensus. In agreeing consensus, however, we may need to declare minority opinions = "in the rough" [RFC7282] if there is a body of opinion that one way of = doing things is preferred and if the drawbacks of that approach are = clearly recognised and accepted. I see the plugfest as an important way of reaching consensus on this = issue. That is, if the plugfest shows that a particular approach is = functional and not harmful it provides a strong case for documenting and = standardising the mechanism. Beyond that it may be most helpful to note the objections to the = "preferred" approach and to write text that explains the concerns and = how they are mitigated (for example, not sending traffic out of admin = domains without applying some magic policy). Adrian From nobody Mon Jan 5 01:20:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59A1A3B9C for ; Mon, 5 Jan 2015 01:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 RPGLNnI8u8Jp for ; Mon, 5 Jan 2015 01:20:38 -0800 (PST) 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 6CBAD1A212D for ; Mon, 5 Jan 2015 01:20:38 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id c9Lb1p0034Hiz6i019Lba5; Mon, 05 Jan 2015 10:20:36 +0100 Received: from AMontpellier-654-1-150-230.w90-0.abo.wanadoo.fr ([90.0.221.230]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 05 Jan 2015 10:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 05 Jan 2015 10:20:35 +0100 From: peter van der Stok To: "Kumar, Sandeep" , roll@ietf.org, Michael Richardson , anders Brandt , emmanuel baccelli , yoshihiro.ohba@toshiba.co.jp, robert cragie Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl> X-Sender: stokcons@xs4all.nl (AV78m+eKgNUMQGkvlO3zQiWOyvp/kh+D) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/OM-r6OktfEhW0aVPJ1l6BYJR_vI Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jan 2015 09:20:41 -0000 I made some new text for section 7.1. below Suggestions for improvement will be appreciated, Peter At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access (PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] provides a framework for network access and delivery of common link keys. New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. Other initiatives are likely to emerge in the context of minimal intervention configuration. At this moment it is not clear what the final most widely deployed solution will be. At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access (PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) provides a framework for network access and delivery of common link keys. Several versions of EAP exist. ZigBee specifies the use of EAP-TLS [RFC5216]. For building control EAP-PSK [RFC4764] is the most suitable approach at this moment. New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only. Other initiatives are likely to emerge in the context of minimal intervention configuration. > > -------- Oorspronkelijke bericht -------- > Onderwerp: RE: [Roll] home-building-requirements section 7.1 > Datum: 2014-12-11 00:24 > Afzender: > Ontvanger: , , > > Kopie: , > > It depends on the requirements on the target system. If the target > system is formed in a totally ad-hoc fashon, then the joining order > is > not determined by network topology. > > But in home and building networks where some a central management > entity > typically exists, there will be a connectivity issue if the joining > order is not determined by network topology. In such a managed > network, > the application in a node should be ready to work when the node > successfully connected to the network, which happens when the node > successfully connected to its neighbor that is "already" connected to > > the network (that's why joining order comes). > > Having said that I think it is OK to mention PANA in section 7.1. For > > EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for > Wi-SUN HAN, AFAIK. On the other hand, I do not mind having DTLS-relay > > and ongoing 6tisch security work. > > Regards, > Yoshihiro Ohba > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Tuesday, December 9, 2014 4:56 PM > To: Michael Richardson > Cc: roll@ietf.org; mcr@sandelman.ca; Anders Brandt > Subject: Re: [Roll] home-building-requirements section 7.1 > > Probably we are not going the EAP-PANA route because EAP PANA imposes > an > order of joining determined by the network topology. > Today, that order will not, cannot, is unlikely to, be respected by > the > installation protocol. > > Consequently, I like to keep the uncertainty in the document. > > Michael Richardson schreef op 2014-12-08 19:47: > > You ask: > What are enrollment tools? > > > > By this, I mean that the combination of protocols and/or > provisioning > > equipment that allows an installer to make a lightbulb join a > > particular network. > > > > That's why I want to know, if you are going the EAP-PANA route, > that > > one needs to know what EAP methods ought to be supported. > > > > > > peter van der Stok wrote: > > > thanks for the encouragement. > > > Concerning bootstrap and security in general. Many things are > > going on and > > > there are two approaches to this document: > > > 1) a conservative one; restrict to what exists and is is proven > > to work > > > 2) leaving the doubt that exists today. > > > > > For the moment I like to leave the doubt, because in 5 years, > > what is sure > > > today will not be implemented is my conviction > > > > > Concerning switching on/off: > > > That is SDO stuff; KNX , BACnet , etc... are preparing > > additional standards. > > > > > What are enrollment tools? > > > > > Peter > > > > > > > Michael Richardson schreef op 2014-11-23 22:16: > > >> I am very pleased with the document; I hope the WG is reading > > it, and is > > >> also happy with it. > > >> > > >> In secton 7.1 you mention use of PANA to secure new nodes. > > >> The reference seems very hesistant, and the DTLS relay is just > > kind of > > >> thrown in. Can you make this recommendation more concrete? Or > > remove it. > > >> > > >> If it's PANA, I assume EAP is involved, and so what what EAP > > methods should > > >> be used? > > >> > > >> I think that, having read this document, I ought to be able to > > create a > > >> light-bulb or light switch --- I think that I can make it > > function in the > > >> network, but I don't think it will use the same enrollment > > tools at all, > > >> and > > >> I'd sure like to change that. I don't mind being really really > > specific > > >> here: I encourage it. > > >> > > >> I also don't know what protocol to use for turning lights > > on/off, but I > > >> acknowledge that is out of scope for the ROLL WG to specify. > > Perhaps there > > >> is an informative reference I missed. > > >> > > >> I think that unless you have a specific way to use the DTLS > > relay, you > > >> should > > >> remove the reference -- it doesn't help anyone trying to > > implement an > > >> interoperable device. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll [1] > > ------------------------- > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > > > Links: > ------ > [1] https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 5 07:31:11 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD11A017D for ; Mon, 5 Jan 2015 07:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TnciPso6OTbW for ; Mon, 5 Jan 2015 07:31:08 -0800 (PST) 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 54E2F1A015F for ; Mon, 5 Jan 2015 07:31:08 -0800 (PST) Received: from localhost ([::1]:58625 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y89cS-0002Hf-N6; Mon, 05 Jan 2015 07:31:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Mon, 05 Jan 2015 15:31:00 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/168#comment:1 Message-ID: <082.4a449dc33fcf0549934838f1185ee2c0@trac.tools.ietf.org> References: <067.bc060c97f072e7fceebc88a26ab4814e@trac.tools.ietf.org> X-Trac-Ticket-ID: 168 In-Reply-To: <067.bc060c97f072e7fceebc88a26ab4814e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org, 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: consultancy@vanderstok.org, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/IhTJfMJXsyiM-EtJrbD05VZIYM4 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #168 (admin-local-policy): Editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jan 2015 15:31:10 -0000 #168: Editorial comments Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: As also suggested by Adrian Farrel, MPL has been expanded in the title, the abstract and the introduction -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll-admin- mariainesrobles@gmail.com | local-policy@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: admin-local-policy | Version: Severity: In WG Last Call | Resolution: fixed Keywords: Request to expand MPL | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Jan 5 14:28:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAFF1A9039; Mon, 5 Jan 2015 14:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 DhJ96jBuWgCH; Mon, 5 Jan 2015 14:28:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8B1A9038; Mon, 5 Jan 2015 14:28:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9E0AE1832B6; Mon, 5 Jan 2015 14:27:49 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150105222749.9E0AE1832B6@rfc-editor.org> Date: Mon, 5 Jan 2015 14:27:49 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/iKb6-5hVl6ctg_OLZjjJwdDb4l0 Cc: drafts-update-ref@iana.org, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 7416 on A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jan 2015 22:28:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7416 Title: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) Author: T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed. Status: Informational Stream: IETF Date: January 2015 Mailbox: tzetatsao@eaton.com, rogeralexander@eaton.com, mischa.dohler@kcl.ac.uk, vanesa.daza@upf.edu, angel.lozano@upf.edu, mcr+ietf@sandelman.ca Pages: 40 Characters: 94452 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-security-threats-11.txt URL: https://www.rfc-editor.org/rfc/rfc7416.txt This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jan 5 14:29:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6951A9048; Mon, 5 Jan 2015 14:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Eh_g946BUpPs; Mon, 5 Jan 2015 14:29:40 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D3D1A903F; Mon, 5 Jan 2015 14:29:39 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id j5so4905935qga.21; Mon, 05 Jan 2015 14:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZheBZCVtYqybEwrmcVcKpJATP4r7Ih/6gBTtbEe99es=; b=kcFjgN7ogHimCnxOp/+3mdVYQe4lbwUH89GFSaZePPfUpKkDcZLcXheERFy8Tk1S/d dOM+8zOVLvIksoyI1FML0R3bkPaWiH6X3/KdOqF0FfUaVt+P1aMLwLjjrvsPrmkcgXiu 3nWj41HQyxc/gnqKZ9aU4O4x0LNUx2+NcldKrtYzTVAW94kbYS155jWlPrynqH0TyfCH jlrgWxO8xS8FadjcR6F2PTb7jeX/dXKTYgeK0q1LZABR7GThpBLuHVDlg9TDRJ3Nlyf5 l21Q2RenAS6YhDfccqKL2wZLD4QPEZRF8TZjY3j4iKKPvD/Zz6tJlSOC8e18DwSzk6dW M3+w== X-Received: by 10.224.8.137 with SMTP id h9mr89289148qah.55.1420496979160; Mon, 05 Jan 2015 14:29:39 -0800 (PST) Received: from che-vpn-cluster-1-258.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id w63sm33498079qgd.44.2015.01.05.14.29.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 14:29:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Mon, 5 Jan 2015 17:29:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HmENXb9OGrrepHQRrPK_RDar7Og Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jan 2015 22:29:41 -0000 Do I have it right that: 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be extended = to compress RH3 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and RH3 In discussion during the IETF-91 6lo working group meeting, a concern = was raised about further consumption of NHC codepoints beyond what is = defined in draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression = scheme. Pascal, Carsten - as you have devised a mechanism for RH3 compression in = draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit a = version of that mechanism into draft-thubert-6lo-rpl-nhc-02? This = extension to NHC compression would provide an explicit proposal for = evaluation of RPL header compression in NHC. - Ralph From nobody Mon Jan 5 22:22:24 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2582F1A90FD; Mon, 5 Jan 2015 22:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ABbNr6NBIwpQ; Mon, 5 Jan 2015 22:22:14 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006D71A90F8; Mon, 5 Jan 2015 22:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1420525334; x=1421734934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1/LBeTUmCA01mnZ2R2VSzpESjcU+V0d22LhwWHixWfU=; b=PBQT9ExkPzmc2R88IVrBIG6a5uKBvaDvdYolJtXD81OLKhtmcUO2xWpq +GzQtg4EZ4FVNVfe5OVU1SOSQOgTm1pR0tKtJ0FgbY0Ty/W9DChKR8YYV PaQiub16Kgp1xTPwq6t5lzNq9NKb0NE6Vidna9OJ9DKsw9b144kyJS31Q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAO99q1StJV2d/2dsb2JhbABcgwZSWMQOghsKhXMCgQsWAQEBAQF9hA0BAQMBAQEBGlELBQsCAQhGIQYLJQIEDgWIGAMJCA29JQ2DbgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjU6BWQEBHDMHgxaBEwWJJ4MhgViHMYFEgQ2KcoIhgzkig25vgQyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,705,1413244800"; d="scan'208";a="110626681" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 06 Jan 2015 06:22:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t066MDEv014842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 06:22:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 00:22:13 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQKTccIER4yneI6UuQFsYm6imsn5yyn8j8 Date: Tue, 6 Jan 2015 06:22:11 +0000 Message-ID: <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/_jQpeMUR_3LSw5sb1u5bfqc8tso Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 06:22:16 -0000 Hello Ralph=20 You certainly got it all right. To your question we started through the NHC and found that path less effici= ent than Laurent's initial suggestion to place all the LLN routing artifact= s in a different header/dispatch whatever the correct term is for that obje= ct. One additional concern that doesn't show in your mail is the need for IP en= capsulation when the artifacts are added by a router on the way or must be = removed at LLN egress. By leaving the original IPv6 packet intact we simpli= fy that matter and optimize the overall result by providing an improved com= pression for the outter header. The new proposal also reopens the dispatch space (1/3 of the total) that is= used is mesh under for mesh header, so it can also be use AND extended as = TLV in route over. Makes sense? Pascal > Le 5 janv. 2015 =E0 23:29, Ralph Droms a =E9crit = : >=20 > Do I have it right that: >=20 > 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3 > 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be extended = to compress RH3 > 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and RH3 >=20 > In discussion during the IETF-91 6lo working group meeting, a concern was= raised about further consumption of NHC codepoints beyond what is defined = in draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression scheme. >=20 > Pascal, Carsten - as you have devised a mechanism for RH3 compression in = draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit a vers= ion of that mechanism into draft-thubert-6lo-rpl-nhc-02? This extension to= NHC compression would provide an explicit proposal for evaluation of RPL h= eader compression in NHC. >=20 > - Ralph >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jan 6 00:24:59 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14AB1A9117 for ; Tue, 6 Jan 2015 00:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FdnT-n_hEj_W for ; Tue, 6 Jan 2015 00:24:54 -0800 (PST) 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 A92521A9115 for ; Tue, 6 Jan 2015 00:24:54 -0800 (PST) Received: from localhost ([::1]:50733 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8PRW-0008PP-Ul; Tue, 06 Jan 2015 00:24:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Tue, 06 Jan 2015 08:24:46 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/167#comment:1 Message-ID: <082.f943a09147fd574dc576c8fa068c4b09@trac.tools.ietf.org> References: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org, 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: consultancy@vanderstok.org, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/UxzsE5scpJlfIGBHUw2t3zM6Rp4 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 08:24:57 -0000 #167: Not match the requirement for administrative configuration of the admin- local scope Comment (by consultancy@vanderstok.org): - The following text is added in alinea 2 of the introduction to explain the meaning of "administratively configured": 'In this document "administratively configured" does not imply actions by a human beyond installing the here specified protocol. "Administratively configured" means an automatic derivation as described in this document.' In addition the relation between zone and MPL4 zone is clarified. The following text is added in section 5: 'MPL4 messages remain bounded within a zone as defined in . Consequently, MPL4 messages cannot be routed between interfaces belonging to different zones. When the concept of zone is unknown or disabled in a router, all interfaces belong to the same zone. For example, consider a router with 5 interfaces where interfaces A and B belong to zone 1 and interfaces C,D, and E belong to zone 2. MPL4 messages can be routed freely between interfaces A and B, and freely between C,D, and E. However, a MPL4 message MUST NOT be routed from Interface A to interface D.' The text for rules and the MPL4 zone is changed accordingly. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll-admin- mariainesrobles@gmail.com | local-policy@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: admin-local-policy | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Tue Jan 6 00:25:49 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E17B1A9125 for ; Tue, 6 Jan 2015 00:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FOmDugic-FW5 for ; Tue, 6 Jan 2015 00:25:39 -0800 (PST) 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 673911A9115 for ; Tue, 6 Jan 2015 00:25:28 -0800 (PST) Received: from localhost ([::1]:50771 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8PS7-000386-Qv; Tue, 06 Jan 2015 00:25:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Tue, 06 Jan 2015 08:25:23 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/167#comment:2 Message-ID: <082.255e990dac7592a0b779dfd7d603297b@trac.tools.ietf.org> References: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-admin-local-policy@tools.ietf.org, consultancy@vanderstok.org, 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: consultancy@vanderstok.org, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/iWHfTTrj46ox7YmKS2pOOzGrJeY Cc: roll@ietf.org Subject: Re: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 08:25:44 -0000 #167: Not match the requirement for administrative configuration of the admin- local scope Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll-admin- mariainesrobles@gmail.com | local-policy@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: admin-local-policy | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Tue Jan 6 07:26:32 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F251A00E1; Tue, 6 Jan 2015 07:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 o0kqJrfF93gY; Tue, 6 Jan 2015 07:26:16 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D5D1A00A8; Tue, 6 Jan 2015 07:26:16 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so31343221pad.10; Tue, 06 Jan 2015 07:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JHZRPpvMVNRCAbo7XYtpu0uZBKGGRJkRfRyVtpsxGuY=; b=y4gixdctYoa1bqWmm4IjyneJsYUnZ2mepeCXlihMaNWcDs8UYlqbsr1KJPWMrKxX/q 9HBOGU/gBjon1mC70KQe+9N/hjeEAa8YEP37jUCtIR4gxdH1vwq9GblkWYYNAC8nHvfW Z0Y2GMpuFbn4PXK+ONaTSLjwno2f+fjrc3KX/Aa/Z/59yV3pDHgW/m/ckFEmw/7z/dVT ZtUnA7RdJO2bw7GdcrwIXAlxAJykOwbkSQAH5Vm57LGeSbPMQHmMthPTm8i9iegxc+tu clG0n+WnZSINwXbEMcOMuIxEds170JTCx90TulEHM19VYbxvWDAKiHxlLKdHSc04zj/K YG3Q== X-Received: by 10.70.89.129 with SMTP id bo1mr160246583pdb.23.1420557975552; Tue, 06 Jan 2015 07:26:15 -0800 (PST) Received: from [10.82.101.41] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id wi15sm57689798pac.21.2015.01.06.07.26.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 07:26:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> Date: Tue, 6 Jan 2015 09:33:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <97A18603-2934-481E-8859-711B00FB359F@gmail.com> References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Qg3g1WkwQFCayHcNrIcexhaLj9Y Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 15:26:20 -0000 (Adding 6man because of architecture issues) On Jan 6, 2015, at 1:22 AM 1/6/15, Pascal Thubert (pthubert) = wrote: > Hello Ralph=20 >=20 > You certainly got it all right. >=20 > To your question we started through the NHC and found that path less = efficient than Laurent's initial suggestion to place all the LLN routing = artifacts in a different header/dispatch whatever the correct term is = for that object. >=20 > One additional concern that doesn't show in your mail is the need for = IP encapsulation when the artifacts are added by a router on the way or = must be removed at LLN egress. By leaving the original IPv6 packet = intact we simplify that matter and optimize the overall result by = providing an improved compression for the outter header. Yeah, I noticed the issue of IP encap hasn't been addressed (if I recall = correctly) in draft-thubert-6lo-rpl-nhc... But ... in my opinion, moving the LLN artifacts to the header/dispatch = in the way defined in draft-thubert-6lo-routing-dispatch raises, = implicitly, an important architectural issue: is the information in the = dispatch header compressed IPv6 headers or headers for an independent, = sub-IP protocol? My understanding is that the IETF has made an architectural decision to = do all the mesh network forwarding and routing in IPv6, so as to reuse = as much as possible existing technology and associated infrastructure = such as OAM. If the dispatch header does not contain compressed IPv6 = headers, per se, then this architectural question would lead me to = investigate the completeness of the new protocol and the impacts of the = new protocol on IPv6 and network operations. =20 >=20 > The new proposal also reopens the dispatch space (1/3 of the total) = that is used is mesh under for mesh header, so it can also be use AND = extended as TLV in route over. There are both architectural and pragmatic issues in the design of the = RPL-in-dispatch protocol. The upcoming bakeoff might be a way to stimulate some running code that = would check out all the potential impacts of moving the RPL information = to a sub-IP protocol. - Ralph >=20 > Makes sense? >=20 > Pascal >=20 >> Le 5 janv. 2015 =E0 23:29, Ralph Droms a = =E9crit : >>=20 >> Do I have it right that: >>=20 >> 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3 >> 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be = extended to compress RH3 >> 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and = RH3 >>=20 >> In discussion during the IETF-91 6lo working group meeting, a concern = was raised about further consumption of NHC codepoints beyond what is = defined in draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression = scheme. >>=20 >> Pascal, Carsten - as you have devised a mechanism for RH3 compression = in draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit = a version of that mechanism into draft-thubert-6lo-rpl-nhc-02? This = extension to NHC compression would provide an explicit proposal for = evaluation of RPL header compression in NHC. >>=20 >> - Ralph >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Tue Jan 6 07:31:10 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BE81A0211; Tue, 6 Jan 2015 07:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8tXwRTcY0kLk; Tue, 6 Jan 2015 07:31:02 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A784D1A00DB; Tue, 6 Jan 2015 07:30:56 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id i50so16517624qgf.24; Tue, 06 Jan 2015 07:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc:reply-to :content-transfer-encoding:message-id:references:to; bh=D79qegj4l2no82i5Hq2/nlbBOzYMBDxby9wBXBYgI3Y=; b=Tf+gjgL7ZCJpE1e0+Q4DdlSX+BFBN8VYBS++31Y7VmTabXYMD6vPZUry2JjEA8V4Hp x++LUPbGTz5Jupqv9aLt27Rn+MLC1GaIv3uvPaOV/WwKHfD1U1eDf459Gy6mXQXBHiWM jKRWVBGOy9S+XcRp2yCy/vrTPZ9djP+h6b3gzcs1U5/9XZbz1u7PJHQ3iJgb8ikVee64 X2d2JJ585FX0REbOOm3M/rKb1JCvKdQd4KGM709SJqRO7I0iH+HUDxPVNlDVzZsVYqsu RyxwiPA9UZ/oUumuYErZSsrLyFSlrfRlsMcy5OlG2IRbDMDJybJc5+O3Y+aOY0eRaV+R e6Gw== X-Received: by 10.140.28.200 with SMTP id 66mr130317171qgz.16.1420558255516; Tue, 06 Jan 2015 07:30:55 -0800 (PST) Received: from [10.82.101.41] (rtp-isp-nat-pool1-1.cisco.com. [64.102.254.34]) by mx.google.com with ESMTPSA id 77sm53566540qgx.43.2015.01.06.07.30.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 07:30:55 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <000701d02815$f43df5f0$dcb9e1d0$@olddog.co.uk> Date: Tue, 6 Jan 2015 10:30:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3FFF5CDE-5C65-4AC1-AAAB-A6CBCE2BC087@gmail.com> References: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <54942758.6090705@innovationslab.net> <549440F0.8040407@innovationslab.net> <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org> <12622.1420055894@sandelman.ca> <000701d02815$f43df5f0$dcb9e1d0$@olddog.co.uk> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/J4ZXnW4t4Dmq4CAqh683jrGcNyQ Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6lo-chairs@tools.ietf.org, 6man WG , rtg-ads@tools.ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, int-ads@tools.ietf.org, 6tisch@ietf.org Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 15:31:05 -0000 On Jan 4, 2015, at 6:59 AM 1/4/15, Adrian Farrel = wrote: > Michael, >=20 > Thanks for continuing to try to wrangle this situation. Agreeing - thanks. > [...] >> Please: how do we proceed? >=20 > Consensus can sometimes be hard-won and slow. It is one of the things = that makes people claim the IETF is slow. On the other hand, the = alternative to consensus is, erm, no consensus. >=20 > In agreeing consensus, however, we may need to declare minority = opinions "in the rough" [RFC7282] if there is a body of opinion that one = way of doing things is preferred and if the drawbacks of that approach = are clearly recognised and accepted. Yes, and, in this particular case, there are at least 4 working groups = involved, which will make determining and declaring consensus even more = difficult. >=20 > I see the plugfest as an important way of reaching consensus on this = issue. That is, if the plugfest shows that a particular approach is = functional and not harmful it provides a strong case for documenting and = standardising the mechanism. Another outcome of the plugfest would be to assess the quality of the = existing drafts (can an implementation be built from just the text in = the draft) and the impact of the new mechanisms on other parts of the = IPv6 suite as well as network operation. >=20 > Beyond that it may be most helpful to note the objections to the = "preferred" approach and to write text that explains the concerns and = how they are mitigated (for example, not sending traffic out of admin = domains without applying some magic policy). I don't know that we have enough detail and discussion, yet, to have = determined a "preferred" approach.=20 - Ralph =20 >=20 > Adrian >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jan 6 08:08:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1541A0072; Tue, 6 Jan 2015 08:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JFOe2WYWX1AJ; Tue, 6 Jan 2015 08:08:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656C21A005D; Tue, 6 Jan 2015 08:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2501; q=dns/txt; s=iport; t=1420560481; x=1421770081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mK4wrhCNBjKl+J9FMlVdN4GNuObTJ0HGLPsfQksxBMs=; b=ZkiK9HnX0vhJ3tGIWwg31BFWYyyan5sH3bbwNoyoHkC00kP0L4R5Itpx GUfY8kVUV1t4X2pUG2p+NegQjEIMkZ3usmk6YnSblBftgox2/Yfm0blkp Lx/WElFxZVrhOvZP8Vf1RnhQX45ZY3Tp3WlLwVyTgcSmMk7xPVZHubMeB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFABQHrFStJV2b/2dsb2JhbABcgwZSWATEG4IbCoUpSgKBDhYBAQEBAX2EDQEBAwEBAQEaUQsFCwIBCA4UJCEGCyUCBA4FCIgQAwkIDb4ODYNOAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNToFSJzEHgxaBEwWJJ4R5hzGNQ4VaIoNub4EDQn4BAQE X-IronPort-AV: E=Sophos;i="5.07,708,1413244800"; d="scan'208";a="384759607" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jan 2015 16:08:00 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t06G7xPZ006736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 16:07:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 10:07:59 -0600 From: "Pascal Thubert (pthubert)" To: Ralph Droms , "Routing Over Low power and Lossy networks" Thread-Topic: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQKcUicqdmXylOn02aReH7B74uTpyzP7vQ Date: Tue, 6 Jan 2015 16:07:58 +0000 Deferred-Delivery: Tue, 6 Jan 2015 16:07:00 +0000 Message-ID: References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> In-Reply-To: <97A18603-2934-481E-8859-711B00FB359F@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/MSzpnRVLE73fnpq9WjDZfJzHJv4 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 16:08:03 -0000 Hello Ralph: > Yeah, I noticed the issue of IP encap hasn't been addressed (if I recall = correctly) > in draft-thubert-6lo-rpl-nhc... [PT] Yes, by design. The NHC draft has a more pragmatic and limited scope.= =20 It covers the compression of the RPL option.=20 Whatever is used for IP in IP compression and RH3 is unchanged by that draf= t. > But ... in my opinion, moving the LLN artifacts to the header/dispatch in= the way > defined in draft-thubert-6lo-routing-dispatch raises, implicitly, an impo= rtant > architectural issue: is the information in the dispatch header compressed= IPv6 > headers or headers for an independent, sub-IP protocol? [PT] That would not be the goal, Ralph.=20 The idea is that there is a biunivocal correspondence between the compresse= d and the uncompressed format. The outter header with the RPL option and the RH3 (whichever are needed) wo= uld be placed in the new dispatch.=20 But the 6LoWPAN expansion would result in the packet as it stands today. Makes sense? Pascal > > > >> Le 5 janv. 2015 =E0 23:29, Ralph Droms a =E9cr= it : > >> > >> Do I have it right that: > >> > >> 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3 > >> 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be extend= ed to > compress RH3 > >> 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and R= H3 > >> > >> In discussion during the IETF-91 6lo working group meeting, a concern = was > raised about further consumption of NHC codepoints beyond what is defined= in > draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression scheme. > >> > >> Pascal, Carsten - as you have devised a mechanism for RH3 compression = in > draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit a ve= rsion of > that mechanism into draft-thubert-6lo-rpl-nhc-02? This extension to NHC > compression would provide an explicit proposal for evaluation of RPL head= er > compression in NHC. > >> > >> - Ralph > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Tue Jan 6 09:02:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40B1A1A25; Tue, 6 Jan 2015 09:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EOtdsv0dgEEu; Tue, 6 Jan 2015 09:01:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E66D1A1A09; Tue, 6 Jan 2015 09:01:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CB97D20098; Tue, 6 Jan 2015 12:07:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E92BB637FE; Tue, 6 Jan 2015 12:01:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D7802637EA; Tue, 6 Jan 2015 12:01:54 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <97A18603-2934-481E-8859-711B00FB359F@gmail.com> References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/N1wkeHxd1uruE1N_bXt21ofXyDU Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 17:01:58 -0000 --=-=-= Content-Type: text/plain Ralph Droms wrote: > But ... in my opinion, moving the LLN artifacts to the header/dispatch > in the way defined in draft-thubert-6lo-routing-dispatch raises, > implicitly, an important architectural issue: is the information in the > dispatch header compressed IPv6 headers or headers for an independent, > sub-IP protocol? My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets. In particular, one can have overlapping IP addressing contexts, and there is no implicit l3-routing assumed between sub-IP protocols. In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL Instance ID) is used to select a particular QoS much like the DSCP can do. Routing between instanceIDs is assumed; but potentially not every node has the specific routes that permits it to do that. > My understanding is that the IETF has made an architectural decision to > do all the mesh network forwarding and routing in IPv6, so as to reuse > as much as possible existing technology and associated infrastructure > such as OAM. If the dispatch header does not contain compressed IPv6 > headers, per se, then this architectural question would lead me to > investigate the completeness of the new protocol and the impacts of the > new protocol on IPv6 and network operations. I think that all of the HC methods *can* be implemented as Bump-in-the-Stack activities; and in particular the loop LLN->ethernet->LLN should be lossless(%). (ethernet->LLN->ethernet is both out of scope [the LLN is never a transit network], and also potentially lossy as some generality of 6553 and 6554 may sacrificed. (%)-lossless definition assumes flow label is always zero. A think that concerns me is that I think that most constrained devices will not implement HC as a bump in the stack, but will uncompress the headers directly into internal control structures, and may have loose the ability to process uncompressed 6553/6554 headers. One could view this as a vestigal appendix-like thing that evolved away. This could be regarded as good: less unused/untested code that will get exploited. This could be regarded as bad: as frame sizes in LLN radios grow (802.15.4g, I'm told, has much larger frames) some systems might have no 6lowpan layer, and interoperation opportunities might become difficult. (I picked the appendix on purpose: some say that it was used to digest grasses/cellulose. If we had a useful appendix, humans might never starve...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVKwU/4CLcPvd0N1lAQJwJAgAiXGfFH0Nai5lmxoLoi8+QCLZXkbfwPzS PLxKQE0gxQuftKPm95vBSBV5sU0deLNMv0PhtL5agLiXkRVB601grTrohE3xjqeD khW7da/pURiL4BKIs+eRQaaKH33nJ3XUHDd02MCJsFNKPWGTYZ8YmKiM6q7HtFEN wdr3IRFtcl/3/0dqA/VzhePG5xrfftLKGb/+Zs2IhSfW2eKFoKY7JFMnEuYg9T9R mhTQPMdzpMzjt1huBHVS3mB+GzTofGO27iCiLsk22i5wz64N0jR1rcWhjGjhkuEQ alHAjbpow0+it8BPXesaqG6jfT9P43ZNCX8uG1Gj4r1NFDFsBgTkwg== =YlTl -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 6 09:04:08 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B461A1A34; Tue, 6 Jan 2015 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CNVyeta_1Mku; Tue, 6 Jan 2015 09:03:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7201A1A32; Tue, 6 Jan 2015 09:03:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 014E020098; Tue, 6 Jan 2015 12:09:03 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 721A2637FE; Tue, 6 Jan 2015 12:03:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 61CD2637EA; Tue, 6 Jan 2015 12:03:43 -0500 (EST) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/047DkfglT80Co5gGingWApvYDnE Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 17:03:56 -0000 An experiment which I have yet to do is to see what happens if one applies GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554. -- ] 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 Tue Jan 6 11:40:49 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CBE1A1B34; Tue, 6 Jan 2015 11:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 BnetIxXrzfaz; Tue, 6 Jan 2015 11:40:44 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B500C1A1AA8; Tue, 6 Jan 2015 11:40:44 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id s7so17003756qap.14; Tue, 06 Jan 2015 11:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c2dSJTgsnSvMeCXfCDkHqCTAory24XN31jK8ud/2cE4=; b=RnhbWBvj3DQX/ax97jVeuG4l6yqj56AYDJm4J++99EwMACwgNcXSsnjX6vDNz35fbX hzuQNlb421KKnm6nlcIEaDlNeZ/Rv3Kev54JIBAHQV11pD1NgymnwY23M7Adh1MKcOg2 QymSmOwbnwC/U+b/3BppS+468z3sjCmPR/CagTrJ/SSsdJMT2FPDbE2W/psu7pfedb57 +sQeHobsJLRgGxNv65RbUN5a3t3tKmt0VXxhFHm5w8YNNskpqN2JhkyMHQP56wz4CPhf m5P1HcFwPxiSkjEeZ18m9qcJqJadWK1QBCXxLNfaqg0Bqvm+N9edjUiEm3tIX+usOdkS JGIA== X-Received: by 10.224.147.197 with SMTP id m5mr124300241qav.51.1420573243883; Tue, 06 Jan 2015 11:40:43 -0800 (PST) Received: from [10.82.101.41] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id 91sm17422815qgf.1.2015.01.06.11.40.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 11:40:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <29592.1420563714@sandelman.ca> Date: Tue, 6 Jan 2015 14:40:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/jt7v14JE8oqlfk7jt3D0_Xz0DdI Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 19:40:47 -0000 On Jan 6, 2015, at 12:01 PM 1/6/15, Michael Richardson = wrote: >=20 > Ralph Droms wrote: >> But ... in my opinion, moving the LLN artifacts to the = header/dispatch >> in the way defined in draft-thubert-6lo-routing-dispatch raises, >> implicitly, an important architectural issue: is the information in = the >> dispatch header compressed IPv6 headers or headers for an = independent, >> sub-IP protocol? >=20 > My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 = packets. > In particular, one can have overlapping IP addressing contexts, "addressing contexts"? > and there is > no implicit l3-routing assumed between sub-IP protocols. OK. > In the LLN case, the l3-layer is constrained; the additional "tag" = (the RPL > Instance ID) is used to select a particular QoS much like the DSCP can = do. > Routing between instanceIDs is assumed; ..instanceIDs covering intersecting sets of nodes; i.e., some nodes are = part of multiple instances? > but potentially not every node has > the specific routes that permits it to do that. Not sure how that relates to a sub-IP protocol for carrying source = routes and RPL tags? >=20 >> My understanding is that the IETF has made an architectural decision = to >> do all the mesh network forwarding and routing in IPv6, so as to = reuse >> as much as possible existing technology and associated infrastructure >> such as OAM. If the dispatch header does not contain compressed IPv6 >> headers, per se, then this architectural question would lead me to >> investigate the completeness of the new protocol and the impacts of = the >> new protocol on IPv6 and network operations. >=20 > I think that all of the HC methods *can* be implemented as = Bump-in-the-Stack > activities; That statement gets to part of my question about = draft-thubert-6lo-routing-dispatch: in the abstract, is = draft-thubert-6lo-routing-dispatch intended to provide a mechanism = through which the original RPI, RH3 and IP-in-IP headers can be = reconstructed before sending the resulting IPv6 datagram up to the IPv6 = stack? At the risk of being overly concerned with the details, I really = mean "reconstruct the header" as opposed to "carry information that can = be used to perform the same function". > and in particular the loop LLN->ethernet->LLN should be > lossless(%). ...where both LLNs and ethernet are part of the same RPL instance? > (ethernet->LLN->ethernet is both out of scope [the LLN is never > a transit network], and also potentially lossy as some generality of = 6553 and > 6554 may sacrificed. >=20 > (%)-lossless definition assumes flow label is always zero. >=20 > A think that concerns me is that I think that most constrained devices = will > not implement HC as a bump in the stack, but will uncompress the = headers > directly into internal control structures, and may have loose the = ability to > process uncompressed 6553/6554 headers. Yeah. We already see a side-effect of this form of implementation in = the desire for compression techniques that do not result in expansion = during transit, because such expansion can require re-fragmentation of a = datagram that might otherwise be forwarded in place without explicitly = uncompressing to the full IPv6 representation. >=20 > One could view this as a vestigal appendix-like thing that evolved = away. > This could be regarded as good: less unused/untested code that will = get > exploited. This could be regarded as bad: as frame sizes in LLN = radios grow > (802.15.4g, I'm told, has much larger frames) some systems might have = no > 6lowpan layer, and interoperation opportunities might become = difficult. I think there are also important issues to think about the interaction = between a sub-IP protocol and the rest of the IPv6 protocol. If the = abstraction is that the sub-IP bits reconstruct into IPv6 headers, we = may have less collateral damage to worry about. Documents defining that = behavior will beed to be careful to show the details and that the = conversions are lossless. - Ralph >=20 > (I picked the appendix on purpose: some say that it was used to digest > grasses/cellulose. If we had a useful appendix, humans might never = starve...) >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Tue Jan 6 15:13:49 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1633B1A01CB; Tue, 6 Jan 2015 15:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lDJLgH6ySPKD; Tue, 6 Jan 2015 15:13:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B925A1A016A; Tue, 6 Jan 2015 15:13:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0351320098; Tue, 6 Jan 2015 18:18:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 585E0637FE; Tue, 6 Jan 2015 18:13:31 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D87A63745; Tue, 6 Jan 2015 18:13:31 -0500 (EST) From: Michael Richardson To: Ralph Droms In-Reply-To: <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DI7SSV3u_mRSbWUDiNou9UvbH5Q Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 23:13:36 -0000 --=-=-= Content-Type: text/plain Ralph Droms wrote: >> Ralph Droms wrote: >>> But ... in my opinion, moving the LLN artifacts to the header/dispatch >>> in the way defined in draft-thubert-6lo-routing-dispatch raises, >>> implicitly, an important architectural issue: is the information in the >>> dispatch header compressed IPv6 headers or headers for an independent, >>> sub-IP protocol? >> >> My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets. >> In particular, one can have overlapping IP addressing contexts, > "addressing contexts"? It's a meaningless and ambiguous term, particularly in IPv6. Perhaps there is a better one in some BEHAVE document. What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks simultaneously on the same link using one of the sub-IP protocols... >> In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL >> Instance ID) is used to select a particular QoS much like the DSCP can do. >> Routing between instanceIDs is assumed; > ..instanceIDs covering intersecting sets of nodes; i.e., some nodes are > part of multiple instances? Correct, any node could be part of multiple DODAGs which have been optimized differently. Whether those nodes will route traffic along a shorter path than going to (respective) DODAG roots, and then out again is really outside of our scope, let's just agree that it is a reasonable. (Consider a powered light bulb router that participates in both the light control DODAG, and also the TV remote control DODAG) >> but potentially not every node has >> the specific routes that permits it to do that. > Not sure how that relates to a sub-IP protocol for carrying source routes and RPL tags? I guess it depends upon what you mean by "sub-IP". I think that we are speaking about it in the former IETF AREA sense; things which are below IP, which have a layering distinction from IP, and which can simultaenously carry a multitude of layer-3 protocols. MPLS for instance. Are you considering 6lowpan HC to be a sub-IP protocol? Is PPP a sub-IP protocol? Is PPP VJ compression a sub-IP protocol? >>> My understanding is that the IETF has made an architectural decision to >>> do all the mesh network forwarding and routing in IPv6, so as to reuse >>> as much as possible existing technology and associated infrastructure >>> such as OAM. If the dispatch header does not contain compressed IPv6 >>> headers, per se, then this architectural question would lead me to >>> investigate the completeness of the new protocol and the impacts of the >>> new protocol on IPv6 and network operations. >> >> I think that all of the HC methods *can* be implemented as Bump-in-the-Stack >> activities; > That statement gets to part of my question about > draft-thubert-6lo-routing-dispatch: in the abstract, is > draft-thubert-6lo-routing-dispatch intended to provide a mechanism > through which the original RPI, RH3 and IP-in-IP headers can be > reconstructed before sending the resulting IPv6 datagram up to the IPv6 > stack? At the risk of being overly concerned with the details, I > really mean "reconstruct the header" as opposed to "carry information > that can be used to perform the same function". I think that this is the intent, and I see this as a good thing. >> and in particular the loop LLN->ethernet->LLN should be >> lossless(%). > ...where both LLNs and ethernet are part of the same RPL instance? Yes, exactly: ethernet bridge of LLN between metal floors or other radio opaque barriers. >> A think that concerns me is that I think that most constrained devices will >> not implement HC as a bump in the stack, but will uncompress the headers >> directly into internal control structures, and may have loose the ability to >> process uncompressed 6553/6554 headers. > Yeah. We already see a side-effect of this form of implementation in > the desire for compression techniques that do not result in expansion > during transit, because such expansion can require re-fragmentation of > a datagram that might otherwise be forwarded in place without > explicitly uncompressing to the full IPv6 representation. >> One could view this as a vestigal appendix-like thing that evolved away. >> This could be regarded as good: less unused/untested code that will get >> exploited. This could be regarded as bad: as frame sizes in LLN radios grow >> (802.15.4g, I'm told, has much larger frames) some systems might have no >> 6lowpan layer, and interoperation opportunities might become difficult. > I think there are also important issues to think about the interaction > between a sub-IP protocol and the rest of the IPv6 protocol. If the > abstraction is that the sub-IP bits reconstruct into IPv6 headers, we > may have less collateral damage to worry about. Documents defining > that behavior will beed to be careful to show the details and that the > conversions are lossless. I agree completely. One of the concerns I realized with rpl-flow-label was that it created an alternative to 6553 which was not equivalent. It's better actually, even on Ethernet-like media. It's also easier to implement in ASICs and current protocol stacks because filters which match the flow label area available already. As such, if we go the rpl-flow-label way, we should probably obsolete 6553 since we have present way to negotiate or announce what should be used for a given network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVKxsG4CLcPvd0N1lAQIk7AgAuY6dxr+5HGmVA1uNASiYVKR74Lj8zpSk ZUqCAu2GJ3si2hk1ha2bXEc6V003hcq9rdM3dKbmg3vTxNKDUfmHpSBYj2neJDIH Y/jfMRJNKYLIqbemuLag0ouazAXAftCkfcM2az04IQffbq5KOXHA2hi6J+6Ritn0 vH0lxt63F5CF5m8Kt4paQz2avxJVnVTSfT+4ASL56A6IrsCihLbXApXFsASTKRK6 Clg5UNeybQVQrYqRIDZaIlygaXFeFeQelf4X+7zLalbvSmHyB9HWZznXZLTMIqgZ zE7cYQuOJf7dqKPnssRPs9OqV3nXF6O/QwGmEv1/S8qqbpn6vgPrUw== =acVE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 6 22:54:51 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF811A01F4; Tue, 6 Jan 2015 15:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 O0kAurEnHKqI; Tue, 6 Jan 2015 15:20:19 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6CF1A016B; Tue, 6 Jan 2015 15:20:19 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id vy18so738237iec.9; Tue, 06 Jan 2015 15:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xqEaaGjF/c1yCvBEK86ctCZ1s/VIliMCMIUpOzy4BPc=; b=Gcv9Ds5/LXXILbX0SiIRMTNEuN470aLLiSMEMt1CU5NWe1/5afRejsDQFrLJNVYgUG gFeD4tgu+8lwwc0TepL61lVCI05MZAFcsZyBb9eYIIpUZkb1jLW8eDX0gzruDC5dopOQ 65Boaxapo4EHxttvp1NPaLEuC9dnp841R4xlO2o1HkWH4qeaqj2WXjJbGISQl4EVI5nE EtGNBDY/+CLRfCbdAgLAktyiu8zfxbe16atIJKabiUmyX2/dF3J0Ws/wHIZFfvxpjvHR jAM0QT4yd6B2kBGAltHbbWSy307oPdPQpJMyklE+r5dDC7UocbvesJ1nMijKBKsU85eH 6JRA== X-Received: by 10.107.46.28 with SMTP id i28mr88501557ioo.73.1420586417690; Tue, 06 Jan 2015 15:20:17 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-8-163.tor.primus.ca. [173.206.8.163]) by mx.google.com with ESMTPSA id qr1sm5644925igb.18.2015.01.06.15.20.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 15:20:17 -0800 (PST) Message-ID: <54AC6DA6.1050707@gmail.com> Date: Tue, 06 Jan 2015 18:20:06 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Richardson , Ralph Droms References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> <11092.1420586011@sandelman.ca> In-Reply-To: <11092.1420586011@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/8UV6O49j9fb4AN__fJtusegqi9o X-Mailman-Approved-At: Tue, 06 Jan 2015 22:54:45 -0800 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 23:20:22 -0000 On 06/01/2015 6:13 PM, Michael Richardson wrote: > > Ralph Droms wrote: > >> Ralph Droms wrote: > >>> But ... in my opinion, moving the LLN artifacts to the header/dispatch > >>> in the way defined in draft-thubert-6lo-routing-dispatch raises, > >>> implicitly, an important architectural issue: is the information in the > >>> dispatch header compressed IPv6 headers or headers for an independent, > >>> sub-IP protocol? > >> > >> My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets. > >> In particular, one can have overlapping IP addressing contexts, > > > "addressing contexts"? > > It's a meaningless and ambiguous term, particularly in IPv6. Perhaps there > is a better one in some BEHAVE document. > What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks > simultaneously on the same link using one of the sub-IP protocols... [PTT] The Behave term is "address domain". Initial definition in RFC 2663, repeated in subsequent documents. .... From nobody Tue Jan 6 22:54:53 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042421A00C5 for ; Mon, 5 Jan 2015 07:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.912 X-Spam-Level: X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 2EUbPBBBUBr9 for ; Mon, 5 Jan 2015 07:36:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 030591A0199 for ; Mon, 5 Jan 2015 07:36:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B504A181C64; Mon, 5 Jan 2015 07:35:50 -0800 (PST) To: 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, akatlas@gmail.com, adrian@olddog.co.uk, maria.ines.robles@ericsson.com, mcr+ietf@sandelman.ca X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150105153550.B504A181C64@rfc-editor.org> Date: Mon, 5 Jan 2015 07:35:50 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/iApyff7H3PIVh6rKJSPwZ6j_XyM X-Mailman-Approved-At: Tue, 06 Jan 2015 22:54:46 -0800 Cc: mcr+ietf@sandelman.ca, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (4219) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jan 2015 15:36:14 -0000 The following errata report has been submitted 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=4219 -------------------------------------- Type: Editorial Reported by: pronounciation of RPL Section: 1.0 Original Text ------------- This document specifies the IPv6 Routing Protocol for LLNs (RPL). Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications. Corrected Text -------------- This document specifies the IPv6 Routing Protocol for LLNs (RPL). The acronym RPL is used extensively in other documents and in other acronyms,and it is pronounced "ripple". As such, it is appropriate to write "a RPL root" as if the acronym was pronounced, rather than "an RPL root" if the letters were spelt out "arr peee ell". Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications. Notes ----- newcomers to the IoT space do not know what "ripple" is. this is recorded as errata so that it does not get lost on 6550bis. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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 Tue Jan 6 22:54:55 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F861A924A; Tue, 6 Jan 2015 03:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.912 X-Spam-Level: X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 eigfL6iGWgpU; Tue, 6 Jan 2015 03:28:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB151ABD36; Tue, 6 Jan 2015 03:28:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B92F71832B8; Tue, 6 Jan 2015 03:27:43 -0800 (PST) To: mcr+ietf@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: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150106112743.B92F71832B8@rfc-editor.org> Date: Tue, 6 Jan 2015 03:27:43 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3dS0JQC_2-8tF_gqdhywKPepN0k X-Mailman-Approved-At: Tue, 06 Jan 2015 22:54:46 -0800 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6550 (4219) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 11:28:09 -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=4219 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Michael Richardson Date Reported: 2015-01-05 Held by: Adrian Farrel (IESG) Section: 1.0 Original Text ------------- This document specifies the IPv6 Routing Protocol for LLNs (RPL). Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications. Corrected Text -------------- This document specifies the IPv6 Routing Protocol for LLNs (RPL). The acronym RPL is used extensively in other documents and in other acronyms,and it is pronounced "ripple". As such, it is appropriate to write "a RPL root" as if the acronym was pronounced, rather than "an RPL root" if the letters were spelt out "arr peee ell". Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications. Notes ----- Pronunciation of RPL Newcomers to the IoT space do not know what "ripple" is. This is recorded as errata so that it does not get lost on 6550bis. -------------------------------------- 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 Wed Jan 7 04:00:52 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DED1A6FD5 for ; Wed, 7 Jan 2015 04:00:50 -0800 (PST) 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 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 lKMMKRStuXnq for ; Wed, 7 Jan 2015 04:00:42 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan27.extendcp.co.uk [176.32.228.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 2015E1A0071 for ; Wed, 7 Jan 2015 04:00:41 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Y8pHx-0004U0-VM; Wed, 07 Jan 2015 12:00:37 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Y8pHv-0000SB-Tl; Wed, 07 Jan 2015 12:00:37 +0000 Received: from host86-167-170-172.range86-167.btcentralplus.com ([86.167.170.172] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y8pHt-0007GN-AX; Wed, 07 Jan 2015 12:00:33 +0000 Message-ID: <54AD1FDA.6040207@gridmerge.com> Date: Wed, 07 Jan 2015 12:00:26 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks , "'Joel M. Halpern'" , consultancy@vanderstok.org References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl> <54999605.1010402@joelhalpern.com> <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk> In-Reply-To: <013101d0227d$c9f04ed0$5dd0ec70$@olddog.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080804040200040909000902" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qhtFk6mefe7aJ_y4x-deOHflpEI Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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, 07 Jan 2015 12:00:51 -0000 This is a cryptographically signed message in MIME format. --------------ms080804040200040909000902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I agree with Adrian's assessment. "Administratively configured" is=20 loosely defined and it is not a black and white case. With regard to the = draft, the configuration (i.e. presence/absence) of MPL interfaces in=20 the node implies the scope and thus can be considered "administratively=20 configured" in that it is not automatically derived but implies by a=20 manual configuration. I agree it does need some clarifying text though. Robert On 28/12/2014 09:08, Adrian Farrel wrote: > To reduce this to the most trivial (and put it in IPv4 terms)... > Is the configuration of 127.0.0.1 "administratively configured" as the = loopback > address? > Clearly no human intervention is needed to make it happen, yet there is= no > "process" that is run. > > I think the 4291 quote is not very helpful since it defines "administra= tively > configured" as "not automatically derived." In particular, an NMS might= be > unsupervised and include software that issues addresses as if it were a= human > making configuration choices. That is clearly "automatic" yet still qua= lifies as > "administratively configured" in my mind. > > This document is trying to use a different definition of "administrativ= ely > configured" as Peter has stated. I don't believe this has to be derived= from > 4291, but perhaps it should be clearly stated in this document as he ha= s > offered. > > Peter/authors: you have some minor edits to do, and perhaps you can wor= k up a > clear definition and include it early in the document with a statement = like "In > this document, the term administratively configured is used to mean..."= > > Cheers, > Adrian > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 23 December 2014 16:19 >> To: consultancy@vanderstok.org; roll@ietf.org >> Cc: Adrian Farrel >> Subject: Re: Fwd: Re: [roll] #167 (admin-local-policy): Not match the > requirement >> for administrative configuration of the admin-local scope >> >> Looking at that quote, I can not see how a behavior that the device >> exhibits without any human intervention can possibly be >> "administratively configured, i.e., not automatically derived" since >> what you are defining is an automatic derivation process. >> >> I Suppose if you had a knob with two settings, one of which was >> "admin-local <=3D=3D realm" and one of which was "admin-local <=3D=3D = this >> procedure" you would meet the minimum requirement of the text you quot= e. >> That at least would have a human cause something. In the document = as >> written, I do not see a human agent. >> >> Yours, >> Joel >> >> On 12/23/14 3:52 AM, peter van der Stok wrote: >>> Hi Joel, >>> >>> There has been a lot of discussion on the roll mailing list of what >>> administratively configured means. >>> A message on the roll mailing list from Michael Richardson summarizes= a >>> meeting we had on the subject, and probably cuts to the core of your >>> argument as well. >>> See: >>> http://www.ietf.org/mail-archive/web/roll/current/msg08335.html >>> >>> In particular: >>> >>> The origin of the second mis-understanding was that the text in >>> multicast-scopes (and rfc 4291) says: >>> >>> Admin-Local scope is the smallest scope that must be >>> administratively configured, i.e., not automatically deriv= ed >>> >>> The understanding of "administratively configured" for many people >>> implies truck rolls, or ssh logins or router CLI commands. It was >>> only when this assumption was clearly articulated that the origin of = the >>> conflict became clear to all parties. >>> >>> The new understanding is that "administratively configured" is not >>> limited to the things that a human did it, but rather includes any >>> processes or operations that a human (including an IETF document) mig= ht >>> cause. The intent of multicast-scopes is not to limit ways that >>> scopes 4+ can be determined, but to clarify that scopes <=3D3 are *no= t* >>> intended to be defined by a physical (or physical-like) topologies. >>> >>> >>> Does this indeed address your issue? >>> And, do you want me to site the explanation of administratively >>> configured in the draft? >>> accompanied by text that the proposed policy is a default policy. >>> >>> Greetings, >>> >>> Peter >>> >>> Joel M. Halpern schreef op 2014-12-22 16:05: >>>> There are two issues intertwined here. >>>> First, the spec you point to says that the behavior shall be >>>> administratively configured. So we need to recognize the conflict >>>> between that assertion and the effort to define an automated policy.= >>>> What I had thought on my previous reading was that you were resolvin= g >>>> the conflict by having a small number of knobs which guided an >>>> automated behavior. >>>> >>>> If I am reading your comments properly, what you are doing is defini= ng >>>> a default policy, without any administrative configuration. If so, >>>> you need to do two things: >>>> >>>> 1) You need to identify that you are violating the underlying RFC in= >>>> order to simplify operations. At that point, it would be up to the >>>> community to decide if that is acceptable. I would expect such a >>>> decision to be clearly identified in the last call. >>>> >>>> 2) You need to describe the policy you want to implement as the >>>> default policy. >>>> >>>> With regard to item 2, the policy in the document or the policy you >>>> propose here are both defensible. The question would be what policy= >>>> the working group wants to enforce. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/22/14 2:21 AM, peter van der Stok wrote: >>>>> Hi Joel, >>>>> >>>>> Thanks for pointing this out. >>>>> After some thought, the best solution seems to embed the MPL admin = local >>>>> scope within the zone concept. >>>>> I propose the following addition: >>>>> >>>>> MPL4 messages remain bounded within a zone. Consequently, MPL4 >> messages >>>>> cannot be routed between interfaces belonging to different zones. >>>>> For example, consider a router with 5 interfaces where interfaces A= and >>>>> B beloing to zone 1 and interfaces C,D, and E belong to zone 2. >>>>> Mpl4 messages can be routed freely between interfaces A and B, and >>>>> freely between C,D, and E. However, a MPL4 message MUST NOT be rout= ed >>>>> from Interface A to interface D. >>>>> >>>>> When the concept of zone is unknown or disabled in a router, all >>>>> interfaces belong to the same zone. >>>>> >>>>> This means adding the zone concept to rules of section 4.2, and tex= t to >>>>> relate zone better to MPL4 zone. >>>>> >>>>> Does this address your issue? >>>>> >>>>> If yes, I will make a new draft along these lines beginning January= >>>>> 2015. >>>>> >>>>> Greetings, >>>>> >>>>> Peter >>>>> >>>>> roll issue tracker schreef op 2014-12-16 00:19: >>>>>> #167: Not match the requirement for administrative configuration o= f >>>>>> the admin- >>>>>> local scope >>>>>> >>>>>> From: Joel M. Halpern >>>>>> Date: 2014-12-16 0:59 GMT+02:00 >>>>>> >>>>>> Major issues: >>>>>> There seems to be a disconnect between the notion of >>>>>> administratively >>>>>> configured and the behavior described in this draft for admin-lo= cal >>>>>> multicast scope. As far as I can tell, the forwarding behavior >>>>>> described >>>>>> here has no mechanism for administratively configuring the >>>>>> administrative >>>>>> boundary. The only knob that is used is PROACTIVE_FORWARDING, >>>>>> which is >>>>>> used for intra-realm multicast forwarding. Thus, if you have a = roll >>>>>> multicast router with two interfaces in one realm and two >>>>>> interfaces in >>>>>> another realm, in order to provide realm multicast services for = each >>>>>> realm, this router according to this draft will always forward >>>>>> admin-local >>>>>> multicast messages between the two realms. That does not seem t= o >>>>>> me to >>>>>> match the requirement for administrative configuration of the >>>>>> admin-local >>>>>> scope > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms080804040200040909000902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAxMDcxMjAwMjZaMCMGCSqGSIb3DQEJBDEWBBQBF8MK+7KmP/0mhrpezBK4hKRprzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQAQW3ApysVD7oIfjwy4T3Li184/ndbX7Mzt 82XfLjo84DpIlU8RJOwSeT7qW1pnZLdxPqwmAedfYNRXjm5N2Mymc2V61A+OG8T1l2aKt9Bf bU6sv4FDqOAnDlGF+oeMhmRke2QBz98FrYn1UlrmNa2mRUGRuEuXo0KRbvx75//Ixe44ps3p rUeTSdj2H8uTSBiCRwGvIQ7EVHBYC3Jt25DYnt3E7hUeMXETutEQSNnj9uUiZaPqPLehFJkS nYIqnPvAXxe5d0mgHW4zD2kPTjOnmcIr5z1WUWWonYZV/wgfsF3adH3uGMonXtmXJfu1cnVL DzFqZoHfg89pOtifCRDwAAAAAAAA --------------ms080804040200040909000902-- From nobody Wed Jan 7 04:54:36 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F621A8A48; Wed, 7 Jan 2015 04:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 XxsygcY6rIVU; Wed, 7 Jan 2015 04:54:24 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B88A1A8A45; Wed, 7 Jan 2015 04:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7495; q=dns/txt; s=iport; t=1420635263; x=1421844863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BjiYphW+Am0WHEWSh+Aa7BDJRvFRojCP9tmr217KH2M=; b=eDxA+8aXI1WY+J1z+DFGX3T1qRzyTHpjn8yWTZeQQrswrFtq0QRj1iTX y/yF7WWBWfUJlqrY9LkRLcYSJq5qr9wgofMykwBO96UOqKSoN04PTNj1S yD/87U/gFRsw79tyTVuTWOHt6l0EhK3GSS5PWgR+0XL9D8EkoKsXR3OFj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAE0rrVStJV2d/2dsb2JhbABcgwZSWATEDIIhhGmBDgKBDkMBAQEBAX2EDAEBAQQdChM/DAQCAQgRBAEBAQoUCQchERQJCAIEAQ0FCIgQAxG+dA2DWgEBAQEBAQEBAQEBAQEBAQEBAQEBAReNToFcHTEHBoMQgRMBBI4uhzyNS4VdIoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,714,1413244800"; d="scan'208";a="111046709" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 07 Jan 2015 12:54:21 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t07CsLDo027005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 12:54:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 06:54:21 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , Ralph Droms Thread-Topic: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQKTccIER4yneI6UuQFsYm6imsn5y0nQ2w Date: Wed, 7 Jan 2015 12:54:20 +0000 Deferred-Delivery: Wed, 7 Jan 2015 12:54:00 +0000 Message-ID: References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> <11092.1420586011@sandelman.ca> In-Reply-To: <11092.1420586011@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/IDhkPvFxFPkoptm5ks3QP39S8gI Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 12:54:26 -0000 Hi: 6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from the f= low label) are encoding procedures that can be reversed so as to restore th= e original packet. The term sub IP, should it refer to an encapsulation like a vlan, would be = inappropriate. If it refers to an adaptation layer below IP, it would apply= .=20 But if the meaning is unclear, then we need to clarify before using it.=20 Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: mercredi 7 janvier 2015 00:14 > To: Ralph Droms > Cc: 6man-chairs@tools.ietf.org; 6lo-chairs@tools.ietf.org; 6man WG; Routi= ng > Over Low power and Lossy networks; 6lo@ietf.org WG; int-ads@tools.ietf.or= g; > 6tisch@ietf.org > Subject: Re: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / R= H3 > compression >=20 >=20 > Ralph Droms wrote: > >> Ralph Droms wrote: > >>> But ... in my opinion, moving the LLN artifacts to the header/dis= patch > >>> in the way defined in draft-thubert-6lo-routing-dispatch raises, > >>> implicitly, an important architectural issue: is the information = in the > >>> dispatch header compressed IPv6 headers or headers for an indepen= dent, > >>> sub-IP protocol? > >> > >> My answer is that a sub-IP protocol can encapsulate arbitrary laye= r-3 > packets. > >> In particular, one can have overlapping IP addressing contexts, >=20 > > "addressing contexts"? >=20 > It's a meaningless and ambiguous term, particularly in IPv6. Perhaps the= re is a > better one in some BEHAVE document. > What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks > simultaneously on the same link using one of the sub-IP protocols... >=20 > >> In the LLN case, the l3-layer is constrained; the additional "tag"= (the RPL > >> Instance ID) is used to select a particular QoS much like the DSCP= can do. > >> Routing between instanceIDs is assumed; >=20 > > ..instanceIDs covering intersecting sets of nodes; i.e., some nodes= are > > part of multiple instances? >=20 > Correct, any node could be part of multiple DODAGs which have been optimi= zed > differently. Whether those nodes will route traffic along a shorter path= than > going to (respective) DODAG roots, and then out again is really outside o= f our > scope, let's just agree that it is a reasonable. > (Consider a powered light bulb router that participates in both the light= control > DODAG, and also the TV remote control DODAG) >=20 > >> but potentially not every node has > >> the specific routes that permits it to do that. >=20 > > Not sure how that relates to a sub-IP protocol for carrying source = routes > and RPL tags? >=20 > I guess it depends upon what you mean by "sub-IP". > I think that we are speaking about it in the former IETF AREA sense; thin= gs which > are below IP, which have a layering distinction from IP, and which can > simultaenously carry a multitude of layer-3 protocols. MPLS for instance= . >=20 > Are you considering 6lowpan HC to be a sub-IP protocol? > Is PPP a sub-IP protocol? > Is PPP VJ compression a sub-IP protocol? >=20 > >>> My understanding is that the IETF has made an architectural decis= ion to > >>> do all the mesh network forwarding and routing in IPv6, so as to = reuse > >>> as much as possible existing technology and associated infrastruc= ture > >>> such as OAM. If the dispatch header does not contain compressed = IPv6 > >>> headers, per se, then this architectural question would lead me t= o > >>> investigate the completeness of the new protocol and the impacts = of the > >>> new protocol on IPv6 and network operations. > >> > >> I think that all of the HC methods *can* be implemented as Bump-in= -the- > Stack > >> activities; >=20 > > That statement gets to part of my question about > > draft-thubert-6lo-routing-dispatch: in the abstract, is > > draft-thubert-6lo-routing-dispatch intended to provide a mechanism > > through which the original RPI, RH3 and IP-in-IP headers can be > > reconstructed before sending the resulting IPv6 datagram up to the = IPv6 > > stack? At the risk of being overly concerned with the details, I > > really mean "reconstruct the header" as opposed to "carry informati= on > > that can be used to perform the same function". >=20 > I think that this is the intent, and I see this as a good thing. >=20 > >> and in particular the loop LLN->ethernet->LLN should be > >> lossless(%). >=20 > > ...where both LLNs and ethernet are part of the same RPL instance? >=20 > Yes, exactly: ethernet bridge of LLN between metal floors or other radio = opaque > barriers. >=20 > >> A think that concerns me is that I think that most constrained dev= ices will > >> not implement HC as a bump in the stack, but will uncompress the h= eaders > >> directly into internal control structures, and may have loose the = ability to > >> process uncompressed 6553/6554 headers. >=20 > > Yeah. We already see a side-effect of this form of implementation = in > > the desire for compression techniques that do not result in expansi= on > > during transit, because such expansion can require re-fragmentation= of > > a datagram that might otherwise be forwarded in place without > > explicitly uncompressing to the full IPv6 representation. >=20 > >> One could view this as a vestigal appendix-like thing that evolved= away. > >> This could be regarded as good: less unused/untested code that wil= l get > >> exploited. This could be regarded as bad: as frame sizes in LLN r= adios grow > >> (802.15.4g, I'm told, has much larger frames) some systems might h= ave no > >> 6lowpan layer, and interoperation opportunities might become diffi= cult. >=20 > > I think there are also important issues to think about the interact= ion > > between a sub-IP protocol and the rest of the IPv6 protocol. If th= e > > abstraction is that the sub-IP bits reconstruct into IPv6 headers, = we > > may have less collateral damage to worry about. Documents defining > > that behavior will beed to be careful to show the details and that = the > > conversions are lossless. >=20 > I agree completely. > One of the concerns I realized with rpl-flow-label was that it created an > alternative to 6553 which was not equivalent. It's better actually, even= on > Ethernet-like media. It's also easier to implement in ASICs and current = protocol > stacks because filters which match the flow label area available already.= As > such, if we go the rpl-flow-label way, we should probably obsolete 6553 s= ince > we have present way to negotiate or announce what should be used for a gi= ven > network. >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jan 7 06:59:20 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE341A90D7; Wed, 7 Jan 2015 06:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iCXAIthAPyqv; Wed, 7 Jan 2015 06:59:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25711A6F2B; Wed, 7 Jan 2015 06:59:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E62C920098; Wed, 7 Jan 2015 10:04:23 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2B6DB637FE; Wed, 7 Jan 2015 09:59:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14E9963745; Wed, 7 Jan 2015 09:59:01 -0500 (EST) From: Michael Richardson To: "6man-chairs\@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs\@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , Routing Over Low power and Lossy networks , "6lo\@ietf.org WG" <6lo@ietf.org>, "int-ads\@tools.ietf.org" , "6tisch\@ietf.org" <6tisch@ietf.org> In-Reply-To: References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> <11092.1420586011@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/uIQnBUpF4aHvcAFq_tZNhk4VFj0 Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 14:59:06 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thank you Tom for point at RFC2663 for "address domain".=20 Pascal Thubert (pthubert) wrote: > 6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from > the flow label) are encoding procedures that can be reversed so as to > restore the original packet.=20 > The term sub IP, should it refer to an encapsulation like a vlan, wou= ld > be inappropriate. If it refers to an adaptation layer below IP, it > would apply.=20=20 So, again, I think a key reason why the various HC are not a sub-IP protocol is because rfc6553 does not create new addressing domains with the RPL InstanceID. Can we agree that this is not a sub-IP signalization problem. =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.4.12 (GNU/Linux) iQEVAwUBVK1JsYCLcPvd0N1lAQJlkwf+JgaYP6XWpONle9riPxXc/cP29p7PV/GK tSRKNBbGiJxZr1NlhHgIRdoNzIulJ13d2acGU/p8qievraWEhkTBadLURgPznk8A uMY/wVpFxrrI6f37jN2ITFMiBky2nxwXXcweF3cO8y+Qyb1BCpY7SGwn8k4qejtG JEJaZLPGDFuDkHiurSqTmFvKPs54w5QOy4WqljNfvE3kW89ykKMjAMe4klz+/3TT SPKpKauP46BRponm6Aq1u0ifRN207w/4N7bBzRlRtpfhwdZandfogXRdt3tb1fD+ WV8MZEsJe+6dJvRJOBiZXRIa7y/ailRPXVDofZbp9ZPojYHvmn0vaA== =wilf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 7 07:15:30 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDDF1A911A; Wed, 7 Jan 2015 07:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 x4bZMS6PFpHR; Wed, 7 Jan 2015 07:15:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA741A9118; Wed, 7 Jan 2015 07:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1431; q=dns/txt; s=iport; t=1420643722; x=1421853322; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1SRL2UQkdU6H1jdDwUF7xT8+ZGuEU8JCxbT1yMN4uQE=; b=I+a0jQRter+UXwvcok8s/G0xGeRgc7jG2QWrQSaHGPlgKFl1/78ei781 lRfDo4JYVVE/21lcCrsgC+5sAv3FBKpZgOv2krcqvJ7NHgNZUNcF/qDFa ursyT86QatfM1yWXnAsReligHGOZCJ/Pg3KH1T4tNk4/gtYxRKA0Rz9tJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAEZNrVStJA2N/2dsb2JhbABcgwaBKgTEDYcKgQ4CgQ9DAQEBAQF9hAwBAQEEHR1LBAIBCBEEAQEBChQJBzIUCQgCBAESCIgkwzwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjyodOAaDEIETAQSOLppkIoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,715,1413244800"; d="scan'208";a="111087628" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 07 Jan 2015 15:15:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t07FFKlK014042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 15:15:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 09:15:20 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG , "Routing Over Low power and Lossy networks" , "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / RH3 compression Thread-Index: AQHQKTccIER4yneI6UuQFsYm6imsn5yyn8j8gAIiyjiAAAQPQA== Date: Wed, 7 Jan 2015 15:15:20 +0000 Deferred-Delivery: Wed, 7 Jan 2015 15:15:00 +0000 Message-ID: References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> <11092.1420586011@sandelman.ca> <14523.1420642741@sandelman.ca> In-Reply-To: <14523.1420642741@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3deduEluCFmWE-g2U_33Ov7Bdyw Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 15:15:23 -0000 Yes, Michael. I think it would help to take that out of the equation. Cheers, Pascal > -----Original Message----- > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michael Richar= dson > Sent: mercredi 7 janvier 2015 15:59 > To: 6man-chairs@tools.ietf.org; 6lo-chairs@tools.ietf.org; 6man WG; Routi= ng > Over Low power and Lossy networks; 6lo@ietf.org WG; int-ads@tools.ietf.or= g; > 6tisch@ietf.org > Subject: Re: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / R= H3 > compression >=20 >=20 > Thank you Tom for point at RFC2663 for "address domain". >=20 > Pascal Thubert (pthubert) wrote: > > 6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart fr= om > > the flow label) are encoding procedures that can be reversed so as = to > > restore the original packet. > > The term sub IP, should it refer to an encapsulation like a vlan, w= ould > > be inappropriate. If it refers to an adaptation layer below IP, it > > would apply. >=20 > So, again, I think a key reason why the various HC are not a sub-IP proto= col is > because rfc6553 does not create new addressing domains with the RPL > InstanceID. >=20 > Can we agree that this is not a sub-IP signalization problem. >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jan 7 08:43:45 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CDF1A0074; Wed, 7 Jan 2015 08:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 Qd6zvgXFqIK7; Wed, 7 Jan 2015 08:43:40 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19701A0069; Wed, 7 Jan 2015 08:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t07GhVfI020650; Wed, 7 Jan 2015 17:43:31 +0100 (CET) Received: from alma.local (p54890325.dip0.t-ipconnect.de [84.137.3.37]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kHbxF5Rkzz83Hn; Wed, 7 Jan 2015 17:43:29 +0100 (CET) Message-ID: <54AD622F.1030502@tzi.org> Date: Wed, 07 Jan 2015 17:43:27 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <29967.1420563823@sandelman.ca> In-Reply-To: <29967.1420563823@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DH8IJFnKYWSoUyR7sDHQSOHNkuU Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "int-ads@tools.ietf.org" , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 16:43:42 -0000 On 2015-01-06 18:03, Michael Richardson wrote: > An experiment which I have yet to do is to see what happens if one applies > GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554. Little point -- there is very little inherent redundancy on the byte sequence level. Gruesse, Carsten From nobody Wed Jan 7 14:32:57 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3031A1B94 for ; Wed, 7 Jan 2015 14:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fZY3AtlIwv6C for ; Wed, 7 Jan 2015 14:32:54 -0800 (PST) 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 DF2A81A1B93 for ; Wed, 7 Jan 2015 14:32:54 -0800 (PST) Received: from localhost ([::1]:41430 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8z9a-0001Yi-4D; Wed, 07 Jan 2015 14:32:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.com X-Trac-Project: roll Date: Wed, 07 Jan 2015 22:32:38 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/137#comment:2 Message-ID: <082.efcc53261c99e89c00079e6e6b36e107@trac.tools.ietf.org> References: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.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: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rNHSVkKrtvT99e4v4m6W9TFJB2w Cc: roll@ietf.org Subject: Re: [Roll] [roll] #137 (applicability-ami): - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 22:32:56 -0000 #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments Comment (by ncamwing@cisco.com): Hi Chris and Ines, I'm not sure how FCAPS applies to the Security Considerations section as it is focused on the Security component of FCAPS (not Fault, Configuration, Accounting or Performance)? Initial and update/incremental sections have been added as well as (in the next revision) reference to RFC 6550's Security considerations as well....is that sufficient enough, or was there other content required? Thanks, Nancy. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Fri Jan 9 04:23:40 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C402D1A8784 for ; Fri, 9 Jan 2015 04:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 9uho4giTaGXm for ; Fri, 9 Jan 2015 04:23:32 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7AC1A8780 for ; Fri, 9 Jan 2015 04:23:32 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id t09CN3bv005545; Fri, 9 Jan 2015 21:23:03 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id t09CN34N009009; Fri, 9 Jan 2015 21:23:03 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA09007; Fri, 9 Jan 2015 21:23:03 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t09CN3W8023399; Fri, 9 Jan 2015 21:23:03 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id t09CN3Dh028788; Fri, 9 Jan 2015 21:23:03 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.24]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 21:23:03 +0900 From: To: , , , , , , Thread-Topic: RE: [Roll] home-building-requirements section 7.1 Thread-Index: AQHQKMjm9fDu+Yc+Ika2TwmYkN6Hupy3u4Qw Date: Fri, 9 Jan 2015 12:23:02 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local> References: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl> In-Reply-To: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.219] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 12:23:37 -0000 Hi Peter Thank you for the new text. I have one comment: The following sentence is incorrect because EAP-PSK is used for Wi-SUN HAN = (Home Area Network) not building control.=20 "For building control EAP-PSK [RFC4764] is the most suitable approach at th= is moment." Since Wi-SUN HAN is mostly specific to Japanese HAN use case, I do not mind= removing the sentence. Thanks, Yoshihiro Ohba -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Monday, January 5, 2015 6:21 PM To: Kumar, Sandeep; roll@ietf.org; Michael Richardson; anders Brandt; emman= uel baccelli; ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#= N#S#L=1B(B); robert cragie Subject: RE: RE: [Roll] home-building-requirements section 7.1 I made some new text for section 7.1. below Suggestions for improvement will be appreciated, Peter At initial deployment the network is secured by consecutively securing node= s at the link layer, thus building a network of secured nodes. The Protocol= for carrying Authentication for Network Access (PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] provides = a framework for network access and delivery of common link keys. New approaches to initial security deployment are being developed in [I-D.k= umar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. Other ini= tiatives are likely to emerge in the context of minimal intervention config= uration. At this moment it is not clear what the final most widely deployed= solution will be. At initial deployment the network is secured by consecutively securing node= s at the link layer, thus building a network of secured nodes. The Protocol= for carrying Authentication for Network Access (PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) provides = a framework for network access and delivery of common link keys. Several ve= rsions of EAP exist. ZigBee specifies the use of EAP-TLS [RFC5216]. For bui= lding control EAP-PSK [RFC4764] is the most suitable approach at this momen= t. New approaches to initial security deployment are being developed in [I-D.k= umar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assu= me a partial ordering of the nodes, such that unsecured nodes are added seq= uentially with the restriction that a path between two secured nodes exists= which passes through secured nodes only. Other initiatives are likely to e= merge in the context of minimal intervention configuration. >=20 > -------- Oorspronkelijke bericht -------- > Onderwerp: RE: [Roll] home-building-requirements section 7.1 > Datum: 2014-12-11 00:24 > Afzender: > Ontvanger: , , =20 > > Kopie: , >=20 > It depends on the requirements on the target system. If the target =20 > system is formed in a totally ad-hoc fashon, then the joining order is =20 > not determined by network topology. >=20 > But in home and building networks where some a central management=20 > entity typically exists, there will be a connectivity issue if the=20 > joining order is not determined by network topology. In such a=20 > managed network, the application in a node should be ready to work=20 > when the node successfully connected to the network, which happens=20 > when the node successfully connected to its neighbor that is=20 > "already" connected to >=20 > the network (that's why joining order comes). >=20 > Having said that I think it is OK to mention PANA in section 7.1. For >=20 > EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for =20 > Wi-SUN HAN, AFAIK. On the other hand, I do not mind having DTLS-relay >=20 > and ongoing 6tisch security work. >=20 > Regards, > Yoshihiro Ohba >=20 > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der =20 > Stok > Sent: Tuesday, December 9, 2014 4:56 PM > To: Michael Richardson > Cc: roll@ietf.org; mcr@sandelman.ca; Anders Brandt > Subject: Re: [Roll] home-building-requirements section 7.1 >=20 > Probably we are not going the EAP-PANA route because EAP PANA imposes=20 > an order of joining determined by the network topology. > Today, that order will not, cannot, is unlikely to, be respected by=20 > the installation protocol. >=20 > Consequently, I like to keep the uncertainty in the document. >=20 > Michael Richardson schreef op 2014-12-08 19:47: > > You ask: > What are enrollment tools? > > > > By this, I mean that the combination of protocols and/or=20 > provisioning > equipment that allows an installer to make a lightbulb=20 > join a > particular network. > > > > That's why I want to know, if you are going the EAP-PANA route,=20 > that > one needs to know what EAP methods ought to be supported. > > > > > > peter van der Stok wrote: > > > thanks for the encouragement. > > > Concerning bootstrap and security in general. Many things are >=20 > going on and > > there are two approaches to this document: > > > 1) a conservative one; restrict to what exists and is is proven =20 > > to work > > 2) leaving the doubt that exists today. > > > > > For the moment I like to leave the doubt, because in 5 years, >=20 > what is sure > > today will not be implemented is my conviction > >=20 > > Concerning switching on/off: > > > That is SDO stuff; KNX , BACnet , etc... are preparing >=20 > additional standards. > > > > > What are enrollment tools? > > > > > Peter > > > > > > > Michael Richardson schreef op 2014-11-23 22:16: > > >> I am very pleased with the document; I hope the WG is reading >=20 > it, and is > >> also happy with it. > > >> > > >> In secton 7.1 you mention use of PANA to secure new nodes. > > >> The reference seems very hesistant, and the DTLS relay is just =20 > > kind of > >> thrown in. Can you make this recommendation more=20 > concrete? Or > remove it. > > >> > > >> If it's PANA, I assume EAP is involved, and so what what EAP >=20 > methods should > >> be used? > > >> > > >> I think that, having read this document, I ought to be able to =20 > > create a > >> light-bulb or light switch --- I think that I can=20 > make it > function in the > >> network, but I don't think it will=20 > use the same enrollment > tools at all, > >> and > >> I'd sure like=20 > to change that. I don't mind being really really > specific > >>=20 > here: I encourage it. > > >> > > >> I also don't know what protocol to use for turning lights >=20 > on/off, but I > >> acknowledge that is out of scope for the ROLL WG=20 > to specify. > > Perhaps there > > >> is an informative reference I missed. > > >> > > >> I think that unless you have a specific way to use the DTLS >=20 > relay, you > >> should > >> remove the reference -- it doesn't help=20 > anyone trying to > implement an > >> interoperable device. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll [1] >=20 > ------------------------- > The information contained in this message may be confidential and=20 > legally protected under applicable law. The message is intended solely=20 > for the addressee(s). If you are not the intended recipient, you are=20 > hereby notified that any use, forwarding, dissemination, or=20 > reproduction of this message is strictly prohibited and may be=20 > unlawful. If you are not the intended recipient, please contact the=20 > sender by return e-mail and destroy all copies of the original=20 > message. >=20 >=20 > Links: > ------ > [1] https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 12 00:17:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932531A8A75 for ; Mon, 12 Jan 2015 00:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 1ehL-uleY-lV for ; Mon, 12 Jan 2015 00:17:34 -0800 (PST) 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 81BD81A8A67 for ; Mon, 12 Jan 2015 00:17:34 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud3.xs4all.net with ESMTP id ewHT1p00H4Hiz6i01wHTAn; Mon, 12 Jan 2015 09:17:29 +0100 Received: from AMontpellier-654-1-150-230.w90-0.abo.wanadoo.fr ([90.0.221.230]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Jan 2015 09:17:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Jan 2015 09:17:27 +0100 From: peter van der Stok To: yoshihiro.ohba@toshiba.co.jp Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local> References: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl> <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local> Message-ID: <83c4345653211a6d3bcac7a8e39a9696@xs4all.nl> X-Sender: stokcons@xs4all.nl (3vwxqljoX35nDVFyuAftAyd9pzgASUBj) User-Agent: XS4ALL Webmail Archived-At: Cc: mcr@sandelman.ca, roll@ietf.org, sandeep.kumar@philips.com, anders_Brandt@sigmadesigns.com Subject: Re: [Roll] home-building-requirements section 7.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 08:17:37 -0000 Hi Yoshira Ohba, I changed the phrasing in . Is this better? see below Peter yoshihiro.ohba@toshiba.co.jp schreef op 2015-01-09 13:23: > Hi Peter > > Thank you for the new text. I have one comment: > > The following sentence is incorrect because EAP-PSK is used for Wi-SUN > HAN (Home Area Network) not building control. > > "For building control EAP-PSK [RFC4764] is the most suitable approach > at this moment." > > Since Wi-SUN HAN is mostly specific to Japanese HAN use case, I do not > mind removing the sentence. > > Thanks, > Yoshihiro Ohba > > > I made some new text for section 7.1. below > > Suggestions for improvement will be appreciated, > > Peter > > > At initial deployment the network is secured by consecutively securing > nodes at the link layer, thus building a network of secured nodes. The > Protocol for carrying Authentication for Network Access > (PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] > provides a framework for network access and delivery of common link > keys. > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. Other initiatives are likely > to emerge in the context of minimal intervention configuration. At > this moment it is not clear what the final most widely deployed > solution will be. > > > > At initial deployment the network is secured by consecutively securing > nodes at the link layer, thus building a network of secured nodes. The > Protocol for carrying Authentication for Network Access > (PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) > provides a framework for network access and delivery of common link > keys. Several versions of EAP exist. ZigBee specifies the use of > EAP-TLS [RFC5216]. Wi-SUN > HAN (Home Area Network) uses EAP-PSK [RFC4764], which also looks > promising for building control at this moment. > > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial ordering > of the nodes, such that unsecured nodes are added sequentially with > the restriction that a path between two secured nodes exists which > passes through secured nodes only. Other initiatives are likely to > emerge in the context of minimal intervention configuration. > > >> >> -------- Oorspronkelijke bericht -------- >> Onderwerp: RE: [Roll] home-building-requirements section 7.1 >> Datum: 2014-12-11 00:24 >> Afzender: >> Ontvanger: , , >> >> Kopie: , >> >> It depends on the requirements on the target system. If the target >> system is formed in a totally ad-hoc fashon, then the joining order is >> not determined by network topology. >> >> But in home and building networks where some a central management >> entity typically exists, there will be a connectivity issue if the >> joining order is not determined by network topology. In such a >> managed network, the application in a node should be ready to work >> when the node successfully connected to the network, which happens >> when the node successfully connected to its neighbor that is >> "already" connected to >> >> the network (that's why joining order comes). >> >> Having said that I think it is OK to mention PANA in section 7.1. For >> >> EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for >> Wi-SUN HAN, AFAIK. On the other hand, I do not mind having DTLS-relay >> >> and ongoing 6tisch security work. >> >> Regards, >> Yoshihiro Ohba >> >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der >> Stok >> Sent: Tuesday, December 9, 2014 4:56 PM >> To: Michael Richardson >> Cc: roll@ietf.org; mcr@sandelman.ca; Anders Brandt >> Subject: Re: [Roll] home-building-requirements section 7.1 >> >> Probably we are not going the EAP-PANA route because EAP PANA imposes >> an order of joining determined by the network topology. >> Today, that order will not, cannot, is unlikely to, be respected by >> the installation protocol. >> >> Consequently, I like to keep the uncertainty in the document. >> >> Michael Richardson schreef op 2014-12-08 19:47: >> > You ask: > What are enrollment tools? >> > >> > By this, I mean that the combination of protocols and/or >> provisioning > equipment that allows an installer to make a lightbulb >> join a > particular network. >> > >> > That's why I want to know, if you are going the EAP-PANA route, >> that > one needs to know what EAP methods ought to be supported. >> > >> > >> > peter van der Stok wrote: >> > > thanks for the encouragement. >> > > Concerning bootstrap and security in general. Many things are > >> going on and > > there are two approaches to this document: >> > > 1) a conservative one; restrict to what exists and is is proven >> > to work > > 2) leaving the doubt that exists today. >> > >> > > For the moment I like to leave the doubt, because in 5 years, > >> what is sure > > today will not be implemented is my conviction > > >> > Concerning switching on/off: >> > > That is SDO stuff; KNX , BACnet , etc... are preparing > >> additional standards. >> > >> > > What are enrollment tools? >> > >> > > Peter >> > >> > >> > > Michael Richardson schreef op 2014-11-23 22:16: >> > >> I am very pleased with the document; I hope the WG is reading > >> it, and is > >> also happy with it. >> > >> >> > >> In secton 7.1 you mention use of PANA to secure new nodes. >> > >> The reference seems very hesistant, and the DTLS relay is just >> > kind of > >> thrown in. Can you make this recommendation more >> concrete? Or > remove it. >> > >> >> > >> If it's PANA, I assume EAP is involved, and so what what EAP > >> methods should > >> be used? >> > >> >> > >> I think that, having read this document, I ought to be able to >> > create a > >> light-bulb or light switch --- I think that I can >> make it > function in the > >> network, but I don't think it will >> use the same enrollment > tools at all, > >> and > >> I'd sure like >> to change that. I don't mind being really really > specific > >> >> here: I encourage it. >> > >> >> > >> I also don't know what protocol to use for turning lights > >> on/off, but I > >> acknowledge that is out of scope for the ROLL WG >> to specify. >> > Perhaps there >> > >> is an informative reference I missed. >> > >> >> > >> I think that unless you have a specific way to use the DTLS > >> relay, you > >> should > >> remove the reference -- it doesn't help >> anyone trying to > implement an > >> interoperable device. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll [1] >> >> ------------------------- >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> >> >> Links: >> ------ >> [1] https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 12 12:38:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724D81ACDE4; Mon, 12 Jan 2015 12:38:37 -0800 (PST) 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 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 8ZxU9jld1Zrf; Mon, 12 Jan 2015 12:38:34 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan28.extendcp.co.uk [176.32.228.2]) (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 6C7E81ACDE0; Mon, 12 Jan 2015 12:38:34 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YAlku-00087U-UJ; Mon, 12 Jan 2015 20:38:32 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YAlkr-00062G-J7; Mon, 12 Jan 2015 20:38:32 +0000 Received: from host86-155-118-56.range86-155.btcentralplus.com ([86.155.118.56] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YAlkk-0000u9-Dd; Mon, 12 Jan 2015 20:38:22 +0000 Message-ID: <54B430BA.6080301@gridmerge.com> Date: Mon, 12 Jan 2015 20:38:18 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: , <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <29967.1420563823@sandelman.ca> <54AD622F.1030502@tzi.org> In-Reply-To: <54AD622F.1030502@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040808080101060109030703" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" Subject: Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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: Mon, 12 Jan 2015 20:38:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040808080101060109030703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable My views on what I think are the salient points in the discussion so far:= 1) Use of interop to validate a way forward I don't agree that a specification has to be set in stone for an=20 interop. The whole point of an interop sometimes is to test the=20 specification and expect it to change afterwards. If there are a number=20 of proposals, then it doesn't seem unreasonable to clearly specify each=20 proposal and implement all proposals. This in itself will give an idea=20 of complexity; the interop will give an idea of issues arising and=20 therefore it should help in deciding which one is the best as clearly=20 there doesn't seem to be consensus based solely on the drafts. 2) Choice of proposals Assuming elimination isn't going to occur via the mailing list, the=20 three options are: a. draft-thubert-roll-flow-label-02 (RPI only) b. draft-thubert-6lo-rpl-nhc-02 but pick one of the three (greedy,=20 conservative, efficient) first (RPI only) c. draft-thubert-6lo-routing-dispatch-01 (RPI and RH3) This implies the current method would be used for RH3 in cases (a) and (b= ). 3) Compression of RH3 using NHC This could be developed as an alternative. I don't recall the NHC=20 approach being abandoned. 4) Time schedule Carsten gave a good summary earlier. I can't see why=20 draft-thubert-6lo-routing-dispatch-01 would take any longer to finalise=20 than draft-thubert-6lo-rpl-nhc-02, especially if the latter would=20 include RH3 as well. 5) Sub-IP protocol The mesh header as it stands is not significantly different to what is=20 being proposed for 6LoRH as it too could be used to carry IPv6 addresses = in a compressed format on the basis that link layer addresses are=20 already used with autoconfigured IPv6 addresses. I would therefore see=20 6LoRH as a general more flexible replacement for the mesh header and=20 therefore 6LoRH used in conjunction with RPI/RH3 would not be a sub-ip=20 protocol. In essence, the difference is really this: RFC4944: mesh[0..a] | FRAG1 | IPHC | {IPHC[0..b] | NHC[0..c]}[0..d] | Payload mesh[0..a] | FRAGN | Payload draft-thubert-6lo-routing-dispatch-01: 6LoRH[0..a] | FRAG1 | 6LoRH[0..b] | IPHC | {IPHC[0..c] |=20 NHC[0..d]}[0..e} | Payload 6LoRH[0..a] | FRAGN | Payload All the above really shows is that 6LoRH can be used in place of a mesh=20 header for sub-ip purposes simply as a "less greedy" way or it can be=20 used to replace an IPHC header as used currently in conjunction with a=20 more efficient header extension. If I have one issue, it is calling them = all "6LoRH" - the RPI can sit a "6LoRH-style" header extension alongside = an IPHC header if there is no encapsulation, I believe? This is where I have some sympathy with James Woodyatt's e-mail - the=20 options start to look a little hairy and it becomes significantly more=20 complex to figure out what goes where. 6) Bump-in-the-stack I have seen both bump-in-the-stack and full decompression/recompression. = In addition to what Pascal points out, there are some other subtle=20 considerations which need to be applied for BITS, especially with regard = to eliding what look like padding fields - I have seen one issue where a = value of 0 was considered to be padding and not included correctly. On 07/01/2015 16:43, Carsten Bormann wrote: > On 2015-01-06 18:03, Michael Richardson wrote: >> An experiment which I have yet to do is to see what happens if one=20 >> applies >> GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554. > > Little point -- there is very little inherent redundancy on the byte=20 > sequence level. > > Gruesse, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms040808080101060109030703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAxMTIyMDM4MThaMCMGCSqGSIb3DQEJBDEWBBQ2iFhxn9qvjC6M+M3lXDcbzkNn5DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQC0AipZq0an90Fk02BDkoZrKoT83B7wwfw4 XxlJLBTYUHi7iqiUV+D7BvBH8RiOVamW+o3euz9Sw7ytjFgsF0TX8ZjujPrj6YqUynJAc+3+ sb6E8jwzI41pzHn/w6Fxcn7UimS6cylskoPc5vdG5SwE30+FkmQJI9ne7IKgnDLd56lck4ei qQtPpbcQj6ogsfM5brcnLImt4o2X51ZiVhdBzCo2uVh6H3EdY7aPjq83CR/4t+7QkiZn/CfG /pB5wY74gho3Cyz1W6gSSMc7kUicFD5Ru0cTMAvc7CvdMAGNufYATizO6j/OFQ66pYZ9yrpW 1Pus5SCuFsrJBiOitQATAAAAAAAA --------------ms040808080101060109030703-- From nobody Thu Jan 15 14:00:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0745D1A1B91; Thu, 15 Jan 2015 14:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=ham 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 s8PUHT9g8Adr; Thu, 15 Jan 2015 14:00:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4851A8838; Thu, 15 Jan 2015 14:00:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DFC7B20098; Thu, 15 Jan 2015 17:06:08 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BF8F063B0E; Thu, 15 Jan 2015 17:00:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A95E1637EC; Thu, 15 Jan 2015 17:00:16 -0500 (EST) From: Michael Richardson To: iesg-secretary@ietf.org, roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: 6tisch@ietf.org, 6man@ietf.org, Brian Haberman , 6lo@ietf.org Subject: [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 15 Jan 2015 22:00:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In accordance with: https://www.ietf.org/iesg/statement/interim-meetings.ht= ml the ROLL Working Group Chairs are announcing a virtual interim meeting for February 10, 2015, from 15:00 UTC to 18:00 UTC. (please see: http://goo.gl/NVefsy to convert the time) The very draft agenda is in development, and can be seen at: http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-int= erim-2015-roll-1 The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options. This could involve compression or recoding, or??? We invite submissions on this. Please post your -00 draft by January 23 if possible, or point us at your other drafts. We will use JITSI for audio, video and slides, with the following URL: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim Participants are encouraged to visit this URL in advance to verify that it works for them. If you need another participant to help verify, pleas= e=20 email me. There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that are unable to connect with a computer, but it won't be toll-free.=20=20 The phone numbers involved will be posted to the agenda as it is finalized, and we expect to distribute slides by January 27, 2015. (BTW: we do not believe that ROLL will meet in Dallas/IETF92) =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVLg4bYCLcPvd0N1lAQLphQgAghZ8y49HRk0Vbq2vf+o+brNTF4feOYv/ vWMh80LWmsiSIcmYKBblXKRFP61HSY4USlQz3dt0kUme91+kPsL8oFGQzYw2ZhQf kwrhr+z0q9iOHSHqzLok4aUS9WJo158Hxj55AOA52CWsjLtRvlnBe+6SGUDcvhmj TE4HeobrKIlFY7hE2SPMYYo08gHNVlc/7QBHq19B9OLD/5fQ8wLGp2OALDgEnWnP Kyhd4FE4c2PhPtWly1bVxk24hJcfGdp7/TM0kIKyTp4N0yeMYPhvI/+ZLxbCRuGE Mj5oofsEXXTP/yugBi9rbbE4b7/HkJcbI+4Uh+fz66NwhKe7ZNn5qg== =JwC+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 15 14:00:32 2015 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 9A9B51A8838; Thu, 15 Jan 2015 14:00:22 -0800 (PST) From: "IETF-IESG via RT" In-Reply-To: <7200.1421359216@sandelman.ca> References: <7200.1421359216@sandelman.ca> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #72411 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: roll@ietf.org Auto-Submitted: auto-replied To: roll@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 15 Jan 2015 14:00:22 -0800 Archived-At: Subject: [Roll] [www.ietf.org/rt #72411] AutoReply: virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iesg-secretary@ietf.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, 15 Jan 2015 22:00:22 -0000 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #72411]. Please include the string: [www.ietf.org/rt #72411] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- In accordance with: https://www.ietf.org/iesg/statement/interim-meetings.html the ROLL Working Group Chairs are announcing a virtual interim meeting for February 10, 2015, from 15:00 UTC to 18:00 UTC. (please see: http://goo.gl/NVefsy to convert the time) The very draft agenda is in development, and can be seen at: http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options. This could involve compression or recoding, or??? We invite submissions on this. Please post your -00 draft by January 23 if possible, or point us at your other drafts. We will use JITSI for audio, video and slides, with the following URL: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim Participants are encouraged to visit this URL in advance to verify that it works for them. If you need another participant to help verify, please email me. There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that are unable to connect with a computer, but it won't be toll-free. The phone numbers involved will be posted to the agenda as it is finalized, and we expect to distribute slides by January 27, 2015. (BTW: we do not believe that ROLL will meet in Dallas/IETF92) -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From nobody Thu Jan 15 15:06:30 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944931A908D; Thu, 15 Jan 2015 15:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_DBL_ABUSE_REDIR=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 eMNBQrjJGces; Thu, 15 Jan 2015 15:06:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1D1A9087; Thu, 15 Jan 2015 15:06:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115230624.26912.73516.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 15:06:24 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] ROLL WG Virtual Interim Meeting: 10 February 2015 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.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, 15 Jan 2015 23:06:25 -0000 In accordance with: https://www.ietf.org/iesg/statement/interim-meetings.html the ROLL Working Group Chairs are announcing a virtual interim meeting for February 10, 2015, from 15:00 UTC to 18:00 UTC. (please see: http://goo.gl/NVefsy to convert the time) The very draft agenda is in development, and can be seen at: http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options. This could involve compression or recoding, or??? We invite submissions on this. Please post your -00 draft by January 23 if possible, or point us at your other drafts. We will use JITSI for audio, video and slides, with the following URL: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim Participants are encouraged to visit this URL in advance to verify that it works for them. If you need another participant to help verify, please email me. There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that are unable to connect with a computer, but it won't be toll-free. The phone numbers involved will be posted to the agenda as it is finalized, and we expect to distribute slides by January 27, 2015. (BTW: we do not believe that ROLL will meet in Dallas/IETF92) From nobody Thu Jan 15 15:08:21 2015 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id E5FBC1A909A; Thu, 15 Jan 2015 15:08:19 -0800 (PST) From: "Cindy Morgan via RT" References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #72411 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: roll@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 15 Jan 2015 15:08:19 -0800 Archived-At: Subject: [Roll] [www.ietf.org/rt #72411] Resolved: virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iesg-secretary@ietf.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, 15 Jan 2015 23:08:20 -0000 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From nobody Mon Jan 19 00:33:21 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E501A8A66; Mon, 19 Jan 2015 00:33:17 -0800 (PST) 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] autolearn=ham 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 CSkYiMuIOC19; Mon, 19 Jan 2015 00:33:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D96671AD2A9; Mon, 19 Jan 2015 00:33:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119083313.12420.32744.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 00:33:13 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 08:33:17 -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 Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-07.txt Pages : 31 Date : 2015-01-19 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-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 Mon Jan 19 00:37:18 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857181AD2C0; Mon, 19 Jan 2015 00:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 L7y3RJLUo5Vb; Mon, 19 Jan 2015 00:37:14 -0800 (PST) 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 77D8A1AD2A9; Mon, 19 Jan 2015 00:37:14 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id hkdB1p0014NtgTm01kdBS9; Mon, 19 Jan 2015 09:37:11 +0100 Received: from AMontpellier-654-1-171-51.w92-145.abo.wanadoo.fr ([92.145.38.51]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 19 Jan 2015 09:37:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Jan 2015 09:37:11 +0100 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: <20150119083313.12420.32744.idtracker@ietfa.amsl.com> References: <20150119083313.12420.32744.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (mra3XW0Cdm4XeT7PUqjcQ3u+DeEScQBS) User-Agent: XS4ALL Webmail Archived-At: Cc: i-d-announce@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 08:37:16 -0000 Dear all, the new version of draft-ietf-roll-applicability-home-building-07.txt includes new text for section 7.1, in which more stringent security recommendations are done than in version 06. Peter internet-drafts@ietf.org schreef op 2015-01-19 09:33: > 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 Working Group of the IETF. > > Title : Applicability Statement: The use of the RPL > protocol suite in Home Automation and Building Control > Authors : Anders Brandt > Emmanuel Baccelli > Robert Cragie > Peter van der Stok > Filename : draft-ietf-roll-applicability-home-building-07.txt > Pages : 31 > Date : 2015-01-19 > > Abstract: > The purpose of this document is to provide guidance in the selection > and use of protocols from the RPL protocol suite to implement the > features required for control in building and home environments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-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/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 19 02:11:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02FF1B29C8; Mon, 19 Jan 2015 02:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2toPm8TSMAHS; Mon, 19 Jan 2015 02:10:55 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8961B29A8; Mon, 19 Jan 2015 02:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1421662255; x=1422871855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IEOhsru9dSPTncpeiu/AYNUPETF1W3t56O32a1lV8d0=; b=e4elNKGVSYBz5bzk/5CDh7ZXEXmLYbQH+slxLNM05UNyNGA0RT3fQF3N zPLRknRO3J/RwahrCQWlmxs7sw2CdPnJLnQo3T8Xum09awfesp0juBCf4 JRHqNWsfmel3+LKT3NMoFtdrHFINqE8t+NblFhP0ZAwSfGkOcKRgt7WVT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAHvXvFStJA2L/2dsb2JhbABbgwZSUwmDAsEHgieFbwIcgQVDAQEBAQF9hAwBAQEEIxFDAgwEAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBA4FCAGIIwgFulOTZgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIY4nMQcGgmIugRMFjlmDR4ZkNoJGh2yGLiKDbm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,426,1418083200"; d="scan'208";a="388089988" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jan 2015 10:10:54 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0JAAsRl022396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Jan 2015 10:10:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.100]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 04:10:53 -0600 From: "Pascal Thubert (pthubert)" To: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-02.txt Thread-Index: AQHQM8nqrLZlUvHeOEiHB4/k5fO0kZzHN/ag Date: Mon, 19 Jan 2015 10:10:53 +0000 Deferred-Delivery: Mon, 19 Jan 2015 10:10:00 +0000 Message-ID: References: <20150119092535.2156.7494.idtracker@ietfa.amsl.com> In-Reply-To: <20150119092535.2156.7494.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 10:10:57 -0000 RGVhciBhbGw6DQoNCkZvbGxvd2luZyBxdWVzdGlvbnMgYW5kIGRpc2N1c3Npb25zIG9uIHRoZSA2 bG8gTUwsIHdlIHB1Ymxpc2hlZCBhbiB1cGRhdGUgb2YgdGhlIHJvdXRpbmcgZGlzcGF0Y2ggKG9y IGhlYWRlcikgZHJhZnQgd2l0aCBjbGFyaWZpY2F0aW9ucy4gDQpBbHNvLCBjb25zaWRlcmluZyB0 aGUgYnJlYWR0aCBvZiBoaXMgY29udHJpYnV0aW9uLCBSb2JlcnQgam9pbmVkIGFzIGEgY28tYXV0 aG9yLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogbHVuZGkgMTkgamFudmllciAyMDE1IDEwOjI2DQpUbzogUm9iZXJ0 IENyYWdpZTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KTsgTGF1cmVudCBUb3V0YWluOyBDYXJzdGVuIEJvcm1hbm47IExhdXJlbnQgVG91dGFpbjsg RHIuIENhcnN0ZW4gQm9ybWFubjsgUm9iZXJ0IENyYWdpZQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoLTAyLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRp c3BhdGNoLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwg VGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC10aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJQSBS b3V0aW5nIEhlYWRlciBEaXNwYXRjaCBmb3IgNkxvV1BBTg0KRG9jdW1lbnQgZGF0ZToJMjAxNS0w MS0xOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjENClVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0 LTZsby1yb3V0aW5nLWRpc3BhdGNoLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gv DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVy dC02bG8tcm91dGluZy1kaXNwYXRjaC0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gtMDIN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBuZXcgNkxvV1BB TiBkaXNwYXRjaCB0eXBlIGZvciB1c2UgaW4NCiAgIFJvdXRlLW92ZXIgYW5kIG1peGVkIE1lc2gt dW5kZXIgYW5kIFJvdXRlLW92ZXIgdG9wb2xvZ2llcywgdGhhdA0KICAgcmV1c2VzIHRoZSBlbmNv ZGluZyBvZiB0aGUgbWVzaCB0eXBlIGRlZmluZWQgaW4gUkZDIDQ5NDQgZm9yIHB1cmUNCiAgIE1l c2gtdW5kZXIgdG9wb2xvZ2llcy4gIFRoaXMgc3BlY2lmaWNhdGlvbiBhbHNvIGRlZmluZXMgYSBt ZXRob2QgdG8NCiAgIGNvbXByZXNzIFJQTCBPcHRpb24gKFJGQzY1NTMpIGluZm9ybWF0aW9uIGFu ZCBSb3V0aW5nIEhlYWRlciB0eXBlIDMNCiAgIChSRkM2NTU0KSwgYW4gZWZmaWNpZW50IElQLWlu LUlQIHRlY2huaXF1ZSBhbmQgb3BlbnMgdGhlIHdheSBmb3INCiAgIGZ1cnRoZXIgcm91dGluZyB0 ZWNobmlxdWVzLiAgVGhpcyBleHRlbmRzIDZMb1dQQU4gVHJhbnNtaXNzaW9uIG9mDQogICBJUHY2 IFBhY2tldHMgKFJGQzQ5NDQpLCBhbmQgaXMgYXBwbGljYWJsZSB0byBuZXcgbGluay1sYXllciB0 eXBlcw0KICAgd2hlcmUgNkxvV1BBTiBpcyBiZWluZyBkZWZpbmVkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Jan 19 05:51:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91A1B2A72 for ; Mon, 19 Jan 2015 05:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Q-ROV4a8EkWK for ; Mon, 19 Jan 2015 05:51:12 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5991AD2A9 for ; Mon, 19 Jan 2015 05:51:12 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id m20so15008698qcx.4 for ; Mon, 19 Jan 2015 05:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=EoQwzlmyB79t9pcQOYx3c4j0lSR1nxEOOPHE3a3wvBY=; b=aiYn6XTLu4PCmwIfEKpWdKNAvu5DplpxBw4vjU/34yOJCw6A6QUG4wzdIDJQ5Q64X0 dPhzHClX8c8gDBsC+ZnMAa7HKu/1uMq+twQ7c0OKAgwKygdCD45jNokkl9TLciLQw5xG mamy65dxBXxbVNxZlbIzS4vmy5O4OMQMDGH2JcDHrEw+n0LpeQaW666xsPvAYZVi0zV2 /FtbDtrZQAGAnerABLQ7CePmuU0tSNVvpVj4Lau6BrALpKwCLhkWkavGHKHOJ2l3SGGz qiJOHkV/lmU2VNrOR1C51GL+kOBd3dxGPnau3yb7Vh8W1/zJ+e7821tBFqn/9dZIGTc/ +Ddw== MIME-Version: 1.0 X-Received: by 10.224.66.200 with SMTP id o8mr48110571qai.13.1421675471863; Mon, 19 Jan 2015 05:51:11 -0800 (PST) Sender: badis.djamaa@gmail.com Received: by 10.140.27.145 with HTTP; Mon, 19 Jan 2015 05:51:11 -0800 (PST) Date: Mon, 19 Jan 2015 13:51:11 +0000 X-Google-Sender-Auth: C0fLGwXpNWWyyKWWUl2heaCkWlw Message-ID: From: badis DJAMAA To: roll@ietf.org, gnawali@cs.uh.edu, T.Clausen@computer.org, pal@cs.stanford.edu, jgko@cs.jhu.edu, jeonggil.ko@gmail.com, jonhui@cisco.com, Ines Robles , Michael Richardson Content-Type: multipart/alternative; boundary=001a11c2beb07c83f9050d019df6 Archived-At: Subject: [Roll] Revisiting the Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 13:51:14 -0000 --001a11c2beb07c83f9050d019df6 Content-Type: text/plain; charset=UTF-8 Dear all We have been working with Trickle for more than two years. A 4-page document available here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 shows that by a simple modification to Trickle, a great decrease in the propagation time can be achieved without affecting Trickle's scalability. The results are backed by extensive simulations and large-scale testbed experiments. In-depth explanation along with more extensive results are under analysis to be announced very soon. In a nutshell the modification recommends to change step 2, section 4.2 . of RFC6206 as follows Old: 2. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I), that is, values greater than or equal to I/2 and less than I. The interval ends at I. New: 2. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range: o [0, Imin) if the interval began as result of step 6 (because of an *inconsistency* or external *events*). o [I/2, I), otherwise(the interval began because of step 1 or step 5) The rationale behind this modification is briefly explained here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 any comment is warmly welcomed All the best badis --001a11c2beb07c83f9050d019df6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all

We have been working = with Trickle for more than two years. A 4-page document available here https://dspace.= lib.cranfield.ac.uk/handle/1826/9033=C2=A0 shows that by a simple modif= ication to Trickle, a great decrease in the propagation time can be achieve= d without affecting Trickle's scalability.

The results are back= ed by extensive simulations and large-scale testbed experiments. In-depth e= xplanation along with more extensive results are under analysis to be annou= nced very soon.

In a nutshell the modification recommends to c= hange step 2, section 4.2. of= RFC6206 as follows

Old:<=
/pre>
 2.  When an interval begins, Trickle resets c t=
o 0 and sets t to a
       random point in the interval, taken from the range [I/2, I), that
       is, values greater than or equal to I/2 and less than I.  The
       interval ends at I. 
New:
 2.=C2=A0 When an interval begins, Trickle resets c to 0 and sets t to a
       random point in the interval, taken from the range:
      =
 o=C2=A0=C2=A0 [0, Imin) if the=
 interval began as result of step 6 
         (because of an in=
consistency or external events).

   o=C2=A0=C2=
=A0 [I/2, I), otherwise(the inter=
val began because of step 1 or step 5)
The rationale behind this modification is briefly explained h= ere https:/= /dspace.lib.cranfield.ac.uk/handle/1826/9033

any comment is warm= ly welcomed

All the best
badis
--001a11c2beb07c83f9050d019df6-- From nobody Mon Jan 19 07:10:52 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DD1B2AA2 for ; Mon, 19 Jan 2015 07:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Doqh3edalfXk for ; Mon, 19 Jan 2015 07:10:42 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 204071B2A9A for ; Mon, 19 Jan 2015 07:10:42 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A390A23CA69 for ; Mon, 19 Jan 2015 09:10:40 -0600 (CST) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAFUA90408eU for ; Mon, 19 Jan 2015 09:10:37 -0600 (CST) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id CA01A23CA5A for ; Mon, 19 Jan 2015 09:10:37 -0600 (CST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by it.cs.uh.edu (Postfix) with ESMTP id 15ED42A28075 for ; Mon, 19 Jan 2015 09:20:08 -0600 (CST) Received: by mail-pd0-f173.google.com with SMTP id fp1so12223689pdb.4 for ; Mon, 19 Jan 2015 07:10:36 -0800 (PST) X-Received: by 10.68.208.65 with SMTP id mc1mr45077129pbc.111.1421680236989; Mon, 19 Jan 2015 07:10:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.125.169 with HTTP; Mon, 19 Jan 2015 07:10:16 -0800 (PST) In-Reply-To: References: From: Omprakash Gnawali Date: Mon, 19 Jan 2015 09:10:16 -0600 Message-ID: To: ROLL WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Roll] Fwd: Revisiting the Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 15:10:46 -0000 ---------- Forwarded message ---------- From: Omprakash Gnawali Date: Mon, Jan 19, 2015 at 9:01 AM Subject: Re: Revisiting the Trickle Algorithm To: badis DJAMAA Cc: ROLL WG , "Thomas Heide Clausen (work)" , Philip Levis , JeongGil Ko , JeongGil Ko , Jonathan Hui , Ines Robles , Michael Richardson It is a good idea to explore how to make Trickle work better. Could you discuss the tradeoffs due to the proposed modification? Are there some scenarios that will be worse off due to the changes? Did you consider minor variations to your scheme - e.g., rather than just the first interval starting at 0, how about the first n intervals starting at 0 rather than I/2? It will be useful to poll the community what they use for Imin and do experiments with similar Imin. - om_p On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA wrote: > Dear all > > We have been working with Trickle for more than two years. A 4-page document > available here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 shows > that by a simple modification to Trickle, a great decrease in the > propagation time can be achieved without affecting Trickle's scalability. > > The results are backed by extensive simulations and large-scale testbed > experiments. In-depth explanation along with more extensive results are > under analysis to be announced very soon. > > In a nutshell the modification recommends to change step 2, section 4.2. of > RFC6206 as follows > > Old: > > 2. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I), that > is, values greater than or equal to I/2 and less than I. The > interval ends at I. > > New: > > 2. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range: > > o [0, Imin) if the interval began as result of step 6 > (because of an inconsistency or external events). > > o [I/2, I), otherwise(the interval began because of step 1 or step 5) > > The rationale behind this modification is briefly explained here > https://dspace.lib.cranfield.ac.uk/handle/1826/9033 > > any comment is warmly welcomed > > All the best > badis From nobody Mon Jan 19 07:54:04 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758C31B29B1 for ; Mon, 19 Jan 2015 07:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YwQvpD08YG2A for ; Mon, 19 Jan 2015 07:54:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2941AD10A for ; Mon, 19 Jan 2015 07:54:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40053203B2 for ; Mon, 19 Jan 2015 11:00:05 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 06539637FE; Mon, 19 Jan 2015 10:53:59 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E1977637EC for ; Mon, 19 Jan 2015 10:53:59 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] Telechat update notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 15:54:02 -0000 --=-=-= Content-Type: text/plain After some significant delays, and some minor rework the document is now going to IESG telechat. Ines and I thank the authors and the community for their patience. IETF Secretariat wrote: > Placed on agenda for telechat - 2015-02-05 > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVL0olICLcPvd0N1lAQIf4wgAosRZdS5SDNPn13vfWkUl96jdXj6ZyoAc KxUKzwZZAKhYqyVx8g8z+lgxpsFZ5F3PaxUiZkodFX6oUfSWGV77Pg/pvi0NQ2nm /X5bKOVvynWIgiwYzpcGcRoGXJ3LiYtyvn7/RZCMwjMRxkWTumdBT5OloR01NtXp 3a8hUmtAMO7tYdWqNhkc3X5MlHkovium6MkR2RviOTRdWKyh+W6Bcp7rK3sRTCWV j/25advDVh4LU4Ar1WGjF3Xi7CUx9sNWyjlxfn9K+i7Us55ghUW8ccwwh3neYZFo O/p0DdEJQ8ZnxDn7sWPNpao9afVJfg6YZ9w8E1DnH9GNgYK5GDaEhw== =9SMO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 19 08:25:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CFB1B2AE2 for ; Mon, 19 Jan 2015 08:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_LSBIAN=2.3, SPF_PASS=-0.001] autolearn=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 krn9e5dTizh8 for ; Mon, 19 Jan 2015 08:25:34 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E521B2ADC for ; Mon, 19 Jan 2015 08:25:33 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id dc16so24453343qab.1 for ; Mon, 19 Jan 2015 08:25:33 -0800 (PST) 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 :content-type; bh=B3aVoNW3xl+AZ1znC92cv3DugXyl4x9DAiR0BXZO/K4=; b=0bc4L1PJhWyqBWJcnWVyK+9KHlwkmH+wjWcjoyAxu2I2JTo1wFWCKk2LsWCrMrJDhn zD0rCP2LJqrCLPZnrS5m1Hj0qADvV3HCLsNsaC2ipGRQ/C7nt8SaQOa0J5xyP3dr1OsU /p2z3ckybC5LltUcxA/LhOf/bXPjzTEbsY3CiCMYR1bes/JInNJxj/Jew/HXpqEDIOMt 2Td2J+ki++dQ4OTC12XC0kszlU8wd4ERTQPzrm8qI+X6+aSbYx0fRxXNx12FwAkSkFHY wa5TpvcUL7kKnBCH10273rkdALtsWsEQ6XAJs6jh9MN1RyodE6O4Lnp8lYSzlImmdh/S WWhw== MIME-Version: 1.0 X-Received: by 10.140.97.102 with SMTP id l93mr35980472qge.48.1421684732945; Mon, 19 Jan 2015 08:25:32 -0800 (PST) Received: by 10.140.27.145 with HTTP; Mon, 19 Jan 2015 08:25:32 -0800 (PST) In-Reply-To: <32747.1421682839@sandelman.ca> References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> Date: Mon, 19 Jan 2015 16:25:32 +0000 Message-ID: From: Badis Djamaa To: Routing Over Low power and Lossy networks , Michael Richardson Content-Type: multipart/alternative; boundary=001a113a9e727d7357050d03c555 Archived-At: Subject: Re: [Roll] Telechat update notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 16:25:36 -0000 --001a113a9e727d7357050d03c555 Content-Type: text/plain; charset=UTF-8 Hi Michael, I had some comments about this draft that I sent to the authors. Having not heard from the authors, I though it might be useful to copy them below ------------------------------------- Dear authors, having read and examined the MPL-drafts-07-11 and having worked thoroughly with Trickle for my PhD, I have some comments regarding MPL's Trickle parameters. Draft 11, Section 5.4. MPL Parameters states: MPL-TEXT: DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206 ], for MPL Data Message transmissions. DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN. Starting from the above statement (dubbed MPL-TEXT), I have two main comments 1) terminology related: [RFC6206 ] (4.1 . Parameters and Variables) defines "The maximum Trickle timer interval" as: RFC6206-TEXT1: The maximum interval size, Imax, is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define Imax as 16. If the minimum interval is 100 ms, then the amount of time specified by Imax is 100 ms * 65,536, i.e., 6,553.6 seconds or approximately 109 minutes. MPL-TEXT refers to RFC6206 for the definition of "The maximum Trickle timer interval". However, I think "The maximum Trickle timer interval" usage in MPL-TEXT is different than its definition in RFC6206-TEXT1. Thus, I think it would be better to explicitly specify what is meant by "The maximum Trickle timer interval" to avoid any ambiguity. Note that the same comment is also valid for this MPL text (Draft 11, Section 5.4. MPL Parameters ) CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206 ], for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes. 2) Now arriving to the main concern, suppose that DATA_MESSAGE_IMAX literally means the maximum trickle interval (the time specified by Imax using RFC6206 terminology), then: "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" behavior . This is because RFC6206 's section 4.2 . Algorithm Description, rule 6 states: RFC6206-TEXT2: 6. ...If I is equal to Imin when Trickle hears an "inconsistent" transmission, Trickle does nothing... Recommending "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." makes the trickle timer always fall under RFC6206-TEXT2 and hence the timer will never get reset when hearing "inconsistencies" However, if this default recommendation is deliberately designed considering the above point, then choosing a non-default value of DATA_MESSAGE_IMAX will result in a different behavior (nodes will reset their timers when receiving inconsistencies). This might even propagate faster than the default recommendation. To avoid the aforementioned ambiguities, I can think of recommending either a default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a change to RFC6206-TEXT2 in the MPL draf, if the current default recommendation is not deliberately designed to work as shown above. Otherwise, explicitly state in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX may result in different behavior. 3) By the way, RFC6206 also contains a typo, which might confuse the reader, in the following text (RFC6206 4.2 . Algorithm Description, rule 1): Current: 1. When the algorithm starts execution, it sets I to a value in the range of [Imin, Imax] -- that is, greater than or equal to Imin and less than or equal to Imax. The algorithm then begins the first interval. Following the definition of the maximum interval size (RFC6206-TEXT1, above) this rule should be rewritten Proposed: 1. When the algorithm starts execution, it sets I to a value in the range of [Imin, *Imin x **POW(2, Imax)*] -- that is, greater than or equal to Imin and less than or equal to *the time specified by* Imax. The algorithm then begins the first interval. Note that the rest of the rules are written taking into account RFC6206-TEXT1. all the best badis On 19 January 2015 at 15:53, Michael Richardson wrote: > > After some significant delays, and some minor rework the document is now > going to IESG telechat. > Ines and I thank the authors and the community for their patience. > > IETF Secretariat wrote: > > Placed on agenda for telechat - 2015-02-05 > > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a113a9e727d7357050d03c555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

I had some co= mments about this draft that I sent to the authors. Having not heard from t= he authors, I though it might be useful to copy them below

----= ---------------------------------
Dear authors,
=C2=A0
having read and examined=C2=A0the MPL-drafts-07-11 and having worked= =20 thoroughly with Trickle for my PhD, I have some comments regarding MPL'= s Trickle parameters.
=C2=A0
Draft 11, Section 5.4.=C2=A0 MPL = Parameters states:
=C2=A0
MPL-TEXT: DATA MESSAGE_IMAX  The maximum Trickle timer interval, =
as defined in
      [RFC6206], for MPL Data Message=
 transmissions.  DATA_MESSAGE_IMAX
      has a default value equal to DATA_MESSAGE_IMIN.
Starting from the above statement (dubbed MPL-TEXT), I have two main c= omments

1) terminology related: [RFC6206]=C2=A0 (4.1.=C2=A0 Parameters a= nd Variables) defines "The maximum Trickle timer interval"= as:
RFC6206-TEXT1:  The maximum interval size, Imax, is described =
as a number of
      doublings of the minimum interval size (the base-2 log(max/min)).
      For example, a protocol might define Imax as 16.  If the minimum
      interval is 100 ms, then the amount of time specified by Imax is
      100 ms * 65,536, i.e., 6,553.6 seconds or approximately
      109 minutes.
MPL-TEXT refers to RFC6206 for the definition of "The maximum Trickle timer interval". Howe= ver, I=20 think "The maximum Trickle timer interval" usage in MPL-TEXT is= =20 different than its definition in RFC6206-TEXT1. Thus, I think it would=20 be better to explicitly specify what is meant by "The maximum Trickle= =20 timer interval" to avoid any ambiguity.

Note that the same com= ment is also valid for this MPL text (Draft 1= 1, Section 5.4.=C2=A0 MPL Parameters )
CONTROL_MESSAG=
E_IMAX  The maximum Trickle timer interval, as defined in [RFC6206], 
for MPL Control Message transmissions. =
CONTROL_MESSAGE_IMAX has a default value of 5 minutes.

= 2) Now arriving to the main concern, suppose that=C2=A0 DATA_MESSAGE_IMAX=20 literally means the maximum trickle interval (the time specified by Imax using RF= C6206=C2=A0terminology), then: "DATA_MESSAGE_IMAX=C2=A0has a default value equal to=20 DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted&quo= t; behavior . This is because RFC6206's section 4.2.=C2=A0 Algorithm Description, rule 6 states:
RFC6206-TEXT2: 6.  ...If I is equal to Imin when Tr=
ickle hears an
       "inconsistent" transmission, Trickle does nothing...
=
Recommending "DATA_MESSAGE_IMAX=C2=A0has a default value equal to DATA_MESSAGE_IMI= N."=20 makes the trickle timer always fall under RFC6206-TEXT2 and hence the=20 timer will never get reset when hearing "inconsistencies"
However, if this default recommendation is deliberately designed=C2=A0 considering= =20 the above point, then choosing a non-default value of DATA_MESSAGE_IMAX=20 will result in a different behavior (nodes will reset their timers when=20 receiving inconsistencies). This might even propagate faster than the=20 default recommendation.
=C2=A0
To avoid the aforementioned ambiguities, I can=20 think of recommending either a default DATA_MESSAGE_IMAX equals=20 2*DATA_MESSAGE_IMIN or propose a change to RFC6206-TEXT2 in the MPL=20 draf, if the current default recommendation is not deliberately designed to work as shown above. Otherwise, explicitly state in the MPL text=20 that choosing a non-default value of DATA_MESSAGE_IMAX may result in=20 different behavior.
=C2=A0
3) By the way, RFC6206 also contains a typo, which might confuse the r= eader, in the following text (RFC= 6206 4.2. Algorithm Description, rule 1):

<= div>Current:
1.  When the algorithm starts execution, it sets I to =
a value in the
       range of [Imin, Imax] -- that is, greater than or equal to Imin
       and less than or equal to Imax.  The algorithm then begins the
       first interval.
Following the definition of the maximum interval size (RFC6206-TEXT1, = above) this rule should be rewritten

Proposed:
1.  Wh=
en the algorithm starts execution, it sets I to a value in the 
       r=
ange of [Imin, Imin x POW(2, Imax)] -=
- that is, greater than or equal to Imin 
       and less than or equal =
to the time specified by =
Imax.=C2=A0 The algorithm then begins 
       the first int=
erval.
Note that the rest of the rules are written taking into account= RFC6206-TEXT1.


all the best
badis

On 19 January 20= 15 at 15:53, Michael Richardson <mcr+ietf@sandelman.ca> = wrote:

After some significant delays, and some minor rework the document is now going to IESG telechat.
Ines and I thank the authors and the community for their patience.

IETF Secretariat <iet= f-secretariat-reply@ietf.org> wrote:
=C2=A0 =C2=A0 > Placed on agenda for telechat - 2015-02-05
=C2=A0 =C2=A0 > ID Tracker URL: http://datatracker.iet= f.org/doc/draft-ietf-roll-trickle-mcast/


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/roll/cha= rter/


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


--001a113a9e727d7357050d03c555-- From nobody Mon Jan 19 10:20:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A34A1B2AA5 for ; Mon, 19 Jan 2015 10:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.599 X-Spam-Level: X-Spam-Status: No, score=-99.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LSBIAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=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 CLv9qACBM3WI for ; Mon, 19 Jan 2015 10:20:22 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2431ACDC9 for ; Mon, 19 Jan 2015 10:20:21 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0JIKIKg006490; Mon, 19 Jan 2015 18:20:18 GMT Received: from 950129200 (194-166-226-168.adsl.highway.telekom.at [194.166.226.168]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0JIKG6Q006480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 18:20:17 GMT From: "Adrian Farrel" To: "'Badis Djamaa'" References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> In-Reply-To: Date: Mon, 19 Jan 2015 18:20:16 -0000 Message-ID: <032a01d03414$942753e0$bc75fba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032B_01D03414.94392E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCw53+4e4VHsW0uBojrMI8G7plKKAIWK/tsAexzYaue5kQeoA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21264.001 X-TM-AS-Result: No--36.703-10.0-31-10 X-imss-scan-details: No--36.703-10.0-31-10 X-TMASE-MatchedRID: HQYVVRq48Rw7iuZ/mdYYtoC2JZZqplZZqJlo5lQZWaqCRevBKC63H8+W uBBZb8XUL0W1btd8e55NI82n17+7U0J1RkW+/L6QV8ukjx868O4Pu/0Lj0myKzeN6XEp4FxwYN6 TBpc4S7r3Zb7NlHCdGKwOh3D3JSTGyTFXR0Y1Ln1nLGaEhTh9zXpENQeTdVXWCBu/kovAHgrLnJ 2UnhQqek5w1HfNpbI4pvwZ9GmdwDP4qCLIu0mtILzZNXfJG3+a/YFClZMrgo0Jc82L/U086xuE0 ttyj7pm3p2WLLHw99BoMLOoNHsM9kPeRdiIlVJEMMn1rcqKQajxO6J7oUevkY52xiOhtMCpz/I8 aG2VMKLwqh5qas50dWwbuvhCHs3cTJDl9FKHbrmCsBeCv8CM/R5FuGz2xZhR8WjLShvBXkJgCvt Ai5GTZKpi1mhIp0HhR+GtoiXVeDEmOHJ0aBcO1PdG7cmuMnEoMY+4OQNXcFHLT/U2lBdAEXC306 CXQ8Uh5ftso2zM73vDg+U1NSmcuesrMeqeicvCJLfQYoCQHFbh0m+JrKxx7FfHpvNvgXmDKGUgI kQkCExNC83U+LUUUJN65fjGjYMQ3vw1aViiOSvJ2i9a4v4pV3Tv7ZA0xIMkEVtxaPoSt7C7Zsqv nT9bvjblc6Gei4nld7yMwO18iIghBdUXaqx1XbXcdpVx4xdSIvwdoLo6xB8wehHQpjQxlVWxAz9 Ls6I1tVWReSlqXepdMrg609R9BKO4XjVpMlFdn+lpJmYuEaN7ltqyJvHgp/JOjUaxKXKqGSKDIg jU9nky499dCbQy8IoLoibgjVEX1WPYxCHVrqebKItl61J/yZUdXE/WGn0FSlnU38LCY8usqqtfp bNXHcgzkpaAyM7aF70JBot7Y88AyZjSuX9209K49nBUaX25m1u+rM16bUmO3uRZC95efSihFyXt pTfA Archived-At: Cc: 'Routing Over Low power and Lossy networks' Subject: Re: [Roll] Telechat update notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 19 Jan 2015 18:20:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032B_01D03414.94392E30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Badis, =20 You sent your comments to the authors in private? Hmmm, that's a shame. But thanks for forwarding them to us all now. =20 Since it is now very late in the process for new comments, what I'll do = is discuss your mail with the authors and chairs, and pick up any = important issues as part of my IESG ballot. =20 Thanks, Adrian =20 From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Badis Djamaa Sent: 19 January 2015 16:26 To: Routing Over Low power and Lossy networks; Michael Richardson Subject: Re: [Roll] Telechat update notice: = =20 Hi Michael, I had some comments about this draft that I sent to the authors. Having = not heard from the authors, I though it might be useful to copy them = below ------------------------------------- Dear authors, =20 having read and examined the MPL-drafts-07-11 and having worked = thoroughly with Trickle for my PhD, I have some comments regarding MPL's = Trickle parameters.=20 =20 Draft 11, Section 5.4. MPL Parameters states: =20 MPL-TEXT: DATA MESSAGE_IMAX The maximum Trickle timer interval, as = defined in [RFC6206 ], for MPL Data = Message transmissions. DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN. Starting from the above statement (dubbed MPL-TEXT), I have two main = comments 1) terminology related: [RFC6206 = ] = ( = 4.1. Parameters and Variables) defines "The maximum = Trickle timer interval" as: RFC6206-TEXT1: The maximum interval size, Imax, is described as a = number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define Imax as 16. If the minimum interval is 100 ms, then the amount of time specified by Imax is 100 ms * 65,536, i.e., 6,553.6 seconds or approximately 109 minutes. MPL-TEXT refers to RFC6206 = = for the definition of "The maximum Trickle timer interval". However, I = think "The maximum Trickle timer interval" usage in MPL-TEXT is = different than its definition in RFC6206-TEXT1. Thus, I think it would = be better to explicitly specify what is meant by "The maximum Trickle = timer interval" to avoid any ambiguity.=20 Note that the same comment is also valid for this MPL text (Draft 11, = Section 5.4. MPL Parameters ) CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined in = [RFC6206 ],=20 for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a = default value of 5 minutes. =20 2) Now arriving to the main concern, suppose that DATA_MESSAGE_IMAX = literally means the maximum trickle interval (the time specified by Imax = using RFC6206 = = terminology), then: "DATA_MESSAGE_IMAX has a default value equal to = DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" behavior = . This is because RFC6206 = 's = section = 4.2. Algorithm Description, rule 6 states: RFC6206-TEXT2: 6. ...If I is equal to Imin when Trickle hears an "inconsistent" transmission, Trickle does nothing... Recommending "DATA_MESSAGE_IMAX has a default value equal to = DATA_MESSAGE_IMIN." makes the trickle timer always fall under = RFC6206-TEXT2 and hence the timer will never get reset when hearing = "inconsistencies"=20 However, if this default recommendation is deliberately designed = considering the above point, then choosing a non-default value of = DATA_MESSAGE_IMAX will result in a different behavior (nodes will reset = their timers when receiving inconsistencies). This might even propagate = faster than the default recommendation. =20 To avoid the aforementioned ambiguities, I can think of recommending = either a default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose = a change to RFC6206-TEXT2 in the MPL draf, if the current default = recommendation is not deliberately designed to work as shown above. = Otherwise, explicitly state in the MPL text that choosing a non-default = value of DATA_MESSAGE_IMAX may result in different behavior. =20 3) By the way, RFC6206 also contains a typo, which might confuse the = reader, in the following text ( = RFC6206 4.2. Algorithm = Description, rule 1):=20 Current: 1. When the algorithm starts execution, it sets I to a value in the range of [Imin, Imax] -- that is, greater than or equal to Imin and less than or equal to Imax. The algorithm then begins the first interval. Following the definition of the maximum interval size (RFC6206-TEXT1, = above) this rule should be rewritten=20 Proposed: 1. When the algorithm starts execution, it sets I to a value in the=20 range of [Imin, Imin x POW(2, Imax)] -- that is, greater than or = equal to Imin=20 and less than or equal to the time specified by Imax. The = algorithm then begins=20 the first interval. Note that the rest of the rules are written taking into account = RFC6206-TEXT1. =20 all the best badis =20 On 19 January 2015 at 15:53, Michael Richardson = wrote: After some significant delays, and some minor rework the document is now going to IESG telechat. Ines and I thank the authors and the community for their patience. IETF Secretariat wrote: > Placed on agenda for telechat - 2015-02-05 > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ -- Michael Richardson >, Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------=_NextPart_000_032B_01D03414.94392E30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Badis,

 

You sent your comments to the = authors in private? Hmmm, that's a shame.

But thanks for forwarding them = to us all now.

 

Since it is now very late in = the process for new comments, what I'll do is discuss your mail with the = authors and chairs, and pick up any important issues as part of my IESG = ballot.

 

Thanks,

Adrian

 

From: Roll = [mailto:roll-bounces@ietf.org] On Behalf Of Badis = Djamaa
Sent: 19 January 2015 16:26
To: Routing Over = Low power and Lossy networks; Michael Richardson
Subject: Re: = [Roll] Telechat update notice: = <draft-ietf-roll-trickle-mcast-11.txt>

<= /div>

 

Hi = Michael,

I had some comments about this draft that = I sent to the authors. Having not heard from the authors, I though it = might be useful to copy them below

-------------------------------------
Dear = authors,

 

having read and examined the MPL-drafts-07-11 and = having worked thoroughly with Trickle for my PhD, I have some comments = regarding MPL's Trickle parameters.

 

Draft 11, Section = 5.4.  MPL Parameters states:

 

MPL-TEXT: DATA =
MESSAGE_IMAX=C2=A0 The maximum =
Trickle timer interval, as defined in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC6206], for MPL Data =
Message transmissions.=C2=A0 =
DATA_MESSAGE_IMAX
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has a =
default value equal to DATA_MESSAGE_IMIN.

Starting from the above = statement (dubbed MPL-TEXT), I have two main = comments

1) terminology = related: [RFC6206]  (4.1.  Parameters and Variables) = defines "The maximum Trickle timer interval" = as:

RFC6206-TEXT1:=C2=A0 The maximum interval size, =
Imax, is described as a number of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
doublings of the minimum interval size (the base-2 =
log(max/min)).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For =
example, a protocol might define Imax as 16.=C2=A0 If the =
minimum
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
interval is 100 ms, then the amount of time specified by Imax =
is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100 ms =
* 65,536, i.e., 6,553.6 seconds or =
approximately
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 109 =
minutes.

MPL-TEXT refers = to RFC6206 for the definition of "The maximum = Trickle timer interval". However, I think "The maximum Trickle = timer interval" usage in MPL-TEXT is different than its definition = in RFC6206-TEXT1. Thus, I think it would be better to explicitly specify = what is meant by "The maximum Trickle timer interval" to avoid = any ambiguity.

Note that the same comment is also valid for this = MPL text (Draft 11, Section = 5.4.  MPL Parameters = )

CONTROL_MESSAGE_IMAX=C2=A0 The maximum Trickle timer =
interval, as defined in [RFC6206], 
for MPL Control Message =
transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 =
minutes.

 

2) Now arriving to the main concern, suppose = that  DATA_MESSAGE_IMAX literally means the maximum trickle = interval (the time specified by Imax using RFC6206 terminology), then: = "DATA_MESSAGE_IMAX has a default value equal to = DATA_MESSAGE_IMIN." in MPL-TEXT could result in a = "non-wanted" behavior . This is because RFC6206's section 4.2.&= nbsp; Algorithm Description, rule 6 = states:

Recommending = "DATA_MESSAGE_IMAX has a default value equal to = DATA_MESSAGE_IMIN." makes the trickle timer always fall under = RFC6206-TEXT2 and hence the timer will never get reset when hearing = "inconsistencies"

Current:

1.=C2=A0 When the algorithm starts =
execution, it sets I to a value in the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
range of [Imin, Imax] -- that is, greater than or equal to =
Imin
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
and less than or equal to Imax.=C2=A0 The algorithm then begins =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
first interval.

Following the definition of the maximum = interval size (RFC6206-TEXT1, above) this rule should be rewritten =

Proposed:

1.=C2=A0 When the algorithm starts =
execution, it sets I to a value in the 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0range of [Imin, Imin x POW(2, =
Imax)] -- that is, greater than or equal to Imin 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0and less than or equal to the time =
specified by Imax.  The algorithm then begins 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the first interval.

Note that the rest of the rules are = written taking into account RFC6206-TEXT1.

 

all = the best

badis

 

On 19 = January 2015 at 15:53, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


After some = significant delays, and some minor rework the document is now
going = to IESG telechat.
Ines and I thank the authors and the community for = their patience.

IETF Secretariat <ietf-secretariat-reply@ie= tf.org> wrote:
    > Placed on agenda for = telechat - 2015-02-05
    > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-trickle= -mcast/


--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

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

 

------=_NextPart_000_032B_01D03414.94392E30-- From nobody Mon Jan 19 15:43:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7A1B2D29 for ; Mon, 19 Jan 2015 15:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lyS1A7cEVEjV for ; Mon, 19 Jan 2015 15:43:11 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D581ACE82 for ; Mon, 19 Jan 2015 15:43:10 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id l6so19800855qcy.12 for ; Mon, 19 Jan 2015 15:43:10 -0800 (PST) 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:content-type; bh=M1bIgIHJ4frE0XKteIRTgqnneesuqduU9INNun+IzJk=; b=cQXJ92hYVf42b/5ptC65lReUFUyqpwkO+SOrpYdZq/SZs945Aw7hm1dpUxA29uxaw5 HSytcKES7/NBemBhxvphtxYoXwX0wGr2lOb+gjpfwz/1RwS7oitFtzk+cuAcrRC7UTkM azUHfxOoiKXE+ygWIiiPmgnta646AUDZq6B+uWkaDIHRhZ+jrvjz4pmKIuPAALarO8Ta ifJdDyLw49QZjyt0hO5yC/b1WHsrhD7LbcFZ2kWz1VCI3O1F2Q64V2t5Yvi5eV7rQ8Z8 OCzGCr21AnAPc2uLlcAi6k5IpAquLTadjjDx305YjaKmlxhMw0uFTM4PxtHNXh9sXPHg Ikkg== MIME-Version: 1.0 X-Received: by 10.224.28.198 with SMTP id n6mr52623736qac.15.1421710989946; Mon, 19 Jan 2015 15:43:09 -0800 (PST) Received: by 10.140.27.145 with HTTP; Mon, 19 Jan 2015 15:43:09 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Jan 2015 23:43:09 +0000 Message-ID: From: Badis Djamaa To: Omprakash Gnawali Content-Type: multipart/alternative; boundary=001a11c2cc9a87766a050d09e26e Archived-At: Cc: Jonathan Hui , "Thomas Heide Clausen \(work\)" , ROLL WG , badis DJAMAA , JeongGil Ko Subject: Re: [Roll] Revisiting the Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 23:43:14 -0000 --001a11c2cc9a87766a050d09e26e Content-Type: text/plain; charset=UTF-8 Thank you Gnawali for your comments, >Could you discuss the tradeoffs due to the proposed modification? Are >there some scenarios that will be worse off due to the changes? Figure1, page 2 of the document, shows the scheme in its best-case (lossless networks). From that Figure, we can see a side-effect of the proposed scheme which can add an extra cost in lossy-networks. Figure 4 in page 4, clearly shows this side-effect in lossy networks. But results in Figure 5 ( network with 90% physical loss rate) shows that the extra cost only affects a few following intervals and disappears later. Also Figure 5 shows that this additional cost does not affect trickle scalability. When generating heavy inconsistencies (periodically injecting new packets), testbed results depicted in third row of graphs in Figure 6, page 4, shows a bigger additional cost because of heavy inconsistent traffic being generated. >Did you consider minor variations to your scheme - e.g., rather than >just the first interval starting at 0, how about the first n intervals >starting at 0 rather than I/2? Because of the side-effect depicted in Figure 4, the additional cost increases if we go for n intervals. Generally speaking, Trickle's scalability might remain logarithmic, because the extra cost only depends on losses. However, the extra cost is noticeable under heavy inconsistent traffic and wastes energy. Note however, that we made a small variation to the scheme by letting a node that transmitted in an Imin interval to start listening immediately (put c=0). Preliminary results look promising and show that the side-effect can be addressed. More results are being analysed to see whether other side-effects can emerge. Best, badis On 19 January 2015 at 15:01, Omprakash Gnawali wrote: > It is a good idea to explore how to make Trickle work better. > > Could you discuss the tradeoffs due to the proposed modification? Are > there some scenarios that will be worse off due to the changes? > > Did you consider minor variations to your scheme - e.g., rather than > just the first interval starting at 0, how about the first n intervals > starting at 0 rather than I/2? > > It will be useful to poll the community what they use for Imin and do > experiments with similar Imin. > > - om_p > > > On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA > wrote: > > Dear all > > > > We have been working with Trickle for more than two years. A 4-page > document > > available here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 > shows > > that by a simple modification to Trickle, a great decrease in the > > propagation time can be achieved without affecting Trickle's scalability. > > > > The results are backed by extensive simulations and large-scale testbed > > experiments. In-depth explanation along with more extensive results are > > under analysis to be announced very soon. > > > > In a nutshell the modification recommends to change step 2, section 4.2. > of > > RFC6206 as follows > > > > Old: > > > > 2. When an interval begins, Trickle resets c to 0 and sets t to a > > random point in the interval, taken from the range [I/2, I), that > > is, values greater than or equal to I/2 and less than I. The > > interval ends at I. > > > > New: > > > > 2. When an interval begins, Trickle resets c to 0 and sets t to a > > random point in the interval, taken from the range: > > > > o [0, Imin) if the interval began as result of step 6 > > (because of an inconsistency or external events). > > > > o [I/2, I), otherwise(the interval began because of step 1 or step > 5) > > > > The rationale behind this modification is briefly explained here > > https://dspace.lib.cranfield.ac.uk/handle/1826/9033 > > > > any comment is warmly welcomed > > > > All the best > > badis > --001a11c2cc9a87766a050d09e26e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you Gnawali for your comments,

=C2=A0

>Could you discuss the tradeoffs due to the proposed modification?= Are
>there some scenarios that will be worse off due to the changes?=

=C2=A0

Figure1, page 2 of the document, shows the scheme in its best-case (l= ossless networks). From that Figure, we can see a side-effect of the propos= ed scheme which can add an extra cost in lossy-networks.

=C2=A0

Figure 4 in page 4, clearly shows this side-effect in lossy networks.= But results=C2=A0in Figure 5 ( network with 90% physical loss rate) shows = that the extra cost only affects a few following intervals and disappears l= ater. Also Figure 5 shows that this additional cost does not affect trickle= scalability.

=C2=A0

When generating heavy inconsistencies (periodically injecting new pac= kets), testbed results=C2=A0depicted in=C2=A0third row of graphs in Figure = 6, page 4, shows a bigger additional cost because=C2=A0of heavy inconsisten= t traffic being generated.

=C2=A0

>Did you consider minor variations to your scheme - e.g., rather t= han
>just the first interval starting at 0, how about the first n int= ervals
>starting at 0 rather than I/2?

=C2=A0

Because of the side-effect depicted in Figure 4, the additional cost = increases if we go for n intervals. Generally speaking, Trickle's scala= bility might remain logarithmic, because the extra cost=C2=A0only depends o= n=C2=A0losses. However,=C2=A0the extra cost=C2=A0is noticeable under heavy = inconsistent traffic and wastes energy.

=C2=A0

Note however, that we made a small variation to the scheme by letting= a node that transmitted in an Imin interval to start listening immediately= =C2=A0(put c=3D0). Preliminary results look promising and show that the sid= e-effect can be addressed.

=C2=A0

More results are being analysed to see whether other side-effects can= emerge.

=C2=A0

Best, badis

=C2=A0
On 19 January 2015 at 15:01, Omprakash Gnawali <= span dir=3D"ltr"><gnawali@cs.uh.edu> wrote:
It is a good idea to explore how to m= ake Trickle work better.

Could you discuss the tradeoffs due to the = proposed modification? Are
there some scenarios that will be worse off d= ue to the changes?

Did you consider minor variations to your scheme = - e.g., rather than
just the first interval starting at 0, how about the= first n intervals
starting at 0 rather than I/2?

It will be usef= ul to poll the community what they use for Imin and do
experiments with = similar Imin.

- om_p


On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA <badis.djamaa@ieee.org>= ; wrote:
> Dear all
>
> We have been working with Trickle= for more than two years. A 4-page document
> available here = https://dspace.lib.cranfield.ac.uk/handle/1826/9033=C2=A0 shows
>= that by a simple modification to Trickle, a great decrease in the
> = propagation time can be achieved without affecting Trickle's scalabilit= y.
>
> The results are backed by extensive simulations and larg= e-scale testbed
> experiments. In-depth explanation along with more e= xtensive results are
> under analysis to be announced very soon.
&= gt;
> In a nutshell the modification recommends to change step 2, sec= tion 4.2. of
> RFC6206 as follows
>
> Old:
>
>= ;=C2=A0 2.=C2=A0 When an interval begins, Trickle resets c to 0 and sets t = to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 random point in the interval, taken= from the range [I/2, I), that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is, value= s greater than or equal to I/2 and less than I.=C2=A0 The
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 interval ends at I.
>
> New:
>
>= =C2=A0 2.=C2=A0 When an interval begins, Trickle resets c to 0 and sets t t= o a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 random point in the interval, taken = from the range:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 =C2=A0[0= , Imin) if the interval began as result of step 6
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (because of an inconsistency or external events).
>=
>=C2=A0 =C2=A0 o=C2=A0 =C2=A0[I/2, I), otherwise(the interval began = because of step 1 or step 5)
>
> The rationale behind this modi= fication is briefly explained here
> https://dspace.lib.cranfi= eld.ac.uk/handle/1826/9033
>
> any comment is warmly welcom= ed
>
> All the best
> badis
<= /div>

--001a11c2cc9a87766a050d09e26e-- From nobody Tue Jan 20 07:06:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F71B2DB8 for ; Tue, 20 Jan 2015 07:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 TJdiJzXY4Aqs for ; Tue, 20 Jan 2015 07:06:35 -0800 (PST) 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 4985A1B2DC2 for ; Tue, 20 Jan 2015 07:06:24 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.205]) by smtp-cloud2.xs4all.net with ESMTP id iF6J1p00Q4RV18J01F6JQ6; Tue, 20 Jan 2015 16:06:21 +0100 Received: from AMontpellier-654-1-111-203.w90-0.abo.wanadoo.fr ([90.0.86.203]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 20 Jan 2015 16:06:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 20 Jan 2015 16:06:18 +0100 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 (rhH3DdqOkpOMgmOk0YY5+fhYpiVx2pBJ) User-Agent: XS4ALL Webmail Archived-At: Cc: badis DJAMAA , JeongGil Ko , "Thomas Heide Clausen \(work\)" , Jonathan Hui Subject: Re: [Roll] Revisiting the Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 15:06:45 -0000 Dear all, I like to draw you attention to the following articles. In these articles calculations are done on the optimal MPL interval division with the aid of queuing networks. In the masters thesis "Modeling and Simulating the Trickle algorithm" (http://alexandria.tue.nl/extra1/afstversl/wsk-i/meyfroyt2013.pdf ) by T.M.M. Meyfroyt (August 2013) propagation delay and message overhead for Trickle and "Short-Trickle" are compared by simulations and analysis in single-hop and multi-hop networks. The paper "Data Dissemination Performance in Large-Scale Sensor Networks" (http://dl.acm.org/citation.cfm?id=2591981 ) by T.M.M. Meyfroyt, S.C. Borst, O.J. Boxma, D. Denteneer (June 2014), analyzes the message overhead of the original Trickle algorithm compared to the "Short-Trickle algorithm". An extended journal version of this paper has been submitted to QUESTA (and has been attached in this email). In the paper "A Data Propagation Model for Wireless Gossiping" (http://arxiv.org/abs/1407.6396) by T.M.M. Meyfroyt, S.C. Borst, O.J. Boxma, D. Denteneer (Juli 2014), an extension to the Trickle algorithm is proposed, similar to the "New Trickle algorithm" and its performance is analyzed and compared to that of the original Trickle algorithm. This paper has recently been accepted in Performance Evaluation (http://www.sciencedirect.com/science/article/pii/S0166531615000024). Hope this is useful. Greetings, peter Badis Djamaa schreef op 2015-01-20 00:43: > Thank you Gnawali for your comments, > >> Could you discuss the tradeoffs due to the proposed modification? Are >> there some scenarios that will be worse off due to the changes? > > Figure1, page 2 of the document, shows the scheme in its best-case > (lossless networks). From that Figure, we can see a side-effect of the > proposed scheme which can add an extra cost in lossy-networks. > > Figure 4 in page 4, clearly shows this side-effect in lossy networks. > But results in Figure 5 ( network with 90% physical loss rate) shows > that the extra cost only affects a few following intervals and > disappears later. Also Figure 5 shows that this additional cost does > not affect trickle scalability. > > When generating heavy inconsistencies (periodically injecting new > packets), testbed results depicted in third row of graphs in Figure 6, > page 4, shows a bigger additional cost because of heavy inconsistent > traffic being generated. > >> Did you consider minor variations to your scheme - e.g., rather than >> just the first interval starting at 0, how about the first n > intervals >> starting at 0 rather than I/2? > > Because of the side-effect depicted in Figure 4, the additional cost > increases if we go for n intervals. Generally speaking, Trickle's > scalability might remain logarithmic, because the extra cost only > depends on losses. However, the extra cost is noticeable under heavy > inconsistent traffic and wastes energy. > > Note however, that we made a small variation to the scheme by letting > a node that transmitted in an Imin interval to start listening > immediately (put c=0). Preliminary results look promising and show > that the side-effect can be addressed. > > More results are being analysed to see whether other side-effects can > emerge. > > Best, badis > > On 19 January 2015 at 15:01, Omprakash Gnawali > wrote: > >> It is a good idea to explore how to make Trickle work better. >> >> Could you discuss the tradeoffs due to the proposed modification? >> Are >> there some scenarios that will be worse off due to the changes? >> >> Did you consider minor variations to your scheme - e.g., rather than >> just the first interval starting at 0, how about the first n >> intervals >> starting at 0 rather than I/2? >> >> It will be useful to poll the community what they use for Imin and >> do >> experiments with similar Imin. >> >> - om_p >> >> On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA >> wrote: >>> Dear all >>> >>> We have been working with Trickle for more than two years. A >> 4-page document >>> available here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 >> [1] shows >>> that by a simple modification to Trickle, a great decrease in the >>> propagation time can be achieved without affecting Trickle's >> scalability. >>> >>> The results are backed by extensive simulations and large-scale >> testbed >>> experiments. In-depth explanation along with more extensive >> results are >>> under analysis to be announced very soon. >>> >>> In a nutshell the modification recommends to change step 2, >> section 4.2. of >>> RFC6206 as follows >>> >>> Old: >>> >>> 2. When an interval begins, Trickle resets c to 0 and sets t to >> a >>> random point in the interval, taken from the range [I/2, >> I), that >>> is, values greater than or equal to I/2 and less than I. >> The >>> interval ends at I. >>> >>> New: >>> >>> 2. When an interval begins, Trickle resets c to 0 and sets t to >> a >>> random point in the interval, taken from the range: >>> >>> o [0, Imin) if the interval began as result of step 6 >>> (because of an inconsistency or external events). >>> >>> o [I/2, I), otherwise(the interval began because of step 1 or >> step 5) >>> >>> The rationale behind this modification is briefly explained here >>> https://dspace.lib.cranfield.ac.uk/handle/1826/9033 [1] >>> >>> any comment is warmly welcomed >>> >>> All the best >>> badis > > > > Links: > ------ > [1] https://dspace.lib.cranfield.ac.uk/handle/1826/9033 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jan 20 08:32:23 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3381B2AB3 for ; Tue, 20 Jan 2015 08:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 spl33k9OBL0z for ; Tue, 20 Jan 2015 08:32:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80B61B29DD for ; Tue, 20 Jan 2015 08:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1421771535; x=1422981135; h=from:to:subject:date:message-id:mime-version; bh=u491lCRcJYDaGL0IItzPZe1+rSjBAyHYAjPPQ8VIuJY=; b=ccxvzBK9y2pFL8GmC2tz5j/4/LH1Nq7eU3HLQrwwUlBCekqAFNpjxpjD 8V3gyED5wE32noirDtzcnWRvIrKB1Oeb+ElkUqEX899Ba4BIoEbq2BfYW jFGPYUAgwl81cT0aw66Le7se3VXhIRxbejj6Ds2bUcYJHG0ZMfNzttJty 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAOOBvlStJA2E/2dsb2JhbABbgkNDUlzEDYgWAoEkQwEBAQEBfYQOAQQtXgEMHlYmAQQbiCStHqMrAQEBAQEFAQEBAQEBHI9Ig06BEwWOWZtBIoNugjR+AQEB X-IronPort-AV: E=Sophos;i="5.09,435,1418083200"; d="scan'208,217";a="385585998" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 20 Jan 2015 16:32:14 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0KGWDHC016998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 16:32:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.100]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 10:32:13 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: RPL implementation Thread-Index: AdA0zpRTrxywcNHnQKKo/KHgU7rU9Q== Date: Tue, 20 Jan 2015 16:32:12 +0000 Deferred-Delivery: Tue, 20 Jan 2015 16:32:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.11.115] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848B2BCA4xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [Roll] RPL implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 16:32:16 -0000 --_000_E045AECD98228444A58C61C200AE1BD848B2BCA4xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all : I'm curious about the progress of the protocol inside and outside LLN domai= ns. Do we have a status on current RPL implementations overall? In particular, do we have opensource outside pure LLN devices, e.g. a gener= ic linux implementation to play with? Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD848B2BCA4xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all :<= /p>

 

I’m curious about the progress of the protocol= inside and outside LLN domains.

Do we have a status on current RPL implementations&n= bsp;overall?

In particular, do we have opensource outside pure LL= N devices, e.g. a generic linux implementation to play with?

 

Cheers,

 

Pascal

--_000_E045AECD98228444A58C61C200AE1BD848B2BCA4xmbrcdx01ciscoc_-- From nobody Tue Jan 20 09:53:52 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38AB1B2B16 for ; Tue, 20 Jan 2015 09:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 yIl5A7N6ZgBz for ; Tue, 20 Jan 2015 09:53:47 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEA21B2AE2 for ; Tue, 20 Jan 2015 09:53:47 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id z12so14293571lbi.7 for ; Tue, 20 Jan 2015 09:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=5jlAU5choMZtTp1Hy82wBILrnHXa8NzkUR5KG7G2czE=; b=dp59RPIOEA1TjfDGCBQ1dnQBJtmb5SXGfA7z/Y7EzeC9RazAVM0haT9zopkdAurEDc qmmUfMmPNZN6ZYZaODYpq0JZqAccuClE+y8iYrcToIt22OfPrHTMDJXhGSQfHnXWd7Yt VbJFlZwdfQpgJ/qFK3rHTjgTkblmqaXRJWQh1Hl0y0ysziBgCYNXujAmnRjml89dl+s+ aYpO8xz5DMKhihG4xIjxNkdJaYex1nTpW4rfMGDdCJvwnDfY5q+7j1me5P+BBZmXMYso vYWc45xcEjtevPEmPxvoWZRYqypBSfU5ySUav11QDTrycodkIzY8MV3nunc1sFpBnsoh C/MA== X-Received: by 10.112.235.194 with SMTP id uo2mr5141258lbc.57.1421776425576; Tue, 20 Jan 2015 09:53:45 -0800 (PST) MIME-Version: 1.0 References: From: =?UTF-8?Q?Jo=C3=A3o_Pedro_Taveira?= Date: Tue, 20 Jan 2015 17:53:45 +0000 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c315e8cbf102050d191e30 Archived-At: Subject: Re: [Roll] RPL implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 17:53:49 -0000 --001a11c315e8cbf102050d191e30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dear Pascal, I started a RPL implementation on Linux Kernel ( https://github.com/joaopedrotaveira/linux-rpl) with basic functionalities such as RPL OF0. I test it with several ARM boards (BBW, RPi and olinuxino) but since kernels versions are so different to this boards, it was quite difficult to maintain it working in all this devices at same time with so many kernel netstack changes. Anyway, after a while I got tired to try to support RPL on this older kernels (3.8.y and 3.10.x for BBB and RPi) and moved forward to get MRH OF working with rfc6551 and etx. This changes are not on github yet. Using Contiki with rf23x radios and linux with same transceivers, I started to implement MRH (etx) with rfc6551 but it has been difficult to get transceivers delivery status from radio links. This kind of information is not available yet on linux netstack and, after some emails exchanged with 6lowpan linux group and netdev group, I realised that if I want it done, I should get it working first and then submit it. Unfortunately, I have no available time to work on this, but I want to continue this implementation as soon as possible. BR, Jo=C3=A3o Pedro Taveira On Tue Jan 20 2015 at 16:32:23 Pascal Thubert (pthubert) wrote: > Dear all : > > > > I=E2=80=99m curious about the progress of the protocol inside and outside= LLN > domains. > > Do we have a status on current RPL implementations overall? > > In particular, do we have opensource outside pure LLN devices, e.g. a > generic linux implementation to play with? > > > > Cheers, > > > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11c315e8cbf102050d191e30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dear Pascal,

I started a RPL implementation on Linux Kernel (https://github.com/jo= aopedrotaveira/linux-rpl) with basic functionalities such as RPL OF0. I= test it with several ARM boards (BBW, RPi and olinuxino) but since kernels= versions are so different to this boards, it was quite difficult to mainta= in it working in all this devices at same time with so many kernel netstack= changes.=C2=A0

Anyway, after a while I got tired to try= to support RPL on this older kernels (3.8.y and 3.10.x for BBB and RPi) an= d moved forward to get MRH OF working with rfc6551 and etx. This changes are not on = github yet.

Using Contiki with rf23x radios and= linux with same transceivers, I started to implement MRH (etx) with rfc655= 1 but it has been difficult to get transceivers delivery status from radio = links. This kind of information is not available yet on linux netstack and,= after some emails exchanged with 6lowpan linux group and netdev group, I r= ealised that if I want it done, I should get it working first and then subm= it it.=C2=A0Unfortunately, I have= no available time to work on this, but I want to continue this implementat= ion as soon as possible.

BR,
Jo=C3=A3o Pedro= Taveira


O= n Tue Jan 20 2015 at 16:32:23 Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Dear all=C2=A0:

=C2=A0

I=E2=80=99m curious about the progress of the protoc= ol inside and outside LLN domains.

Do we have a status on current RPL implementations= =C2=A0overall?

In particular, do we have opensource outside pure LL= N devices, e.g. a generic linux implementation to play with?<= /p>

=C2=A0

Cheers,

=C2=A0

Pascal

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
--001a11c315e8cbf102050d191e30-- From nobody Tue Jan 20 10:14:36 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8517F1B2AB5 for ; Tue, 20 Jan 2015 10:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fbzRx3EsgsNZ for ; Tue, 20 Jan 2015 10:14:32 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F5C1B29F5 for ; Tue, 20 Jan 2015 10:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8651; q=dns/txt; s=iport; t=1421777672; x=1422987272; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FcwJPzX8YOaHCPvNHj94u12tnFtPjBx95RHcWAuJ4jY=; b=ZAmZofmZfYKtA6kzJ7xebZcR3mZJBWcv9+tt6C2orLa65Di0xlupAEfd OejDBtzF9QZ1gE55YMiogAURhfen9Q96BgSGIRBNIhleC8VVj62BvbAZ+ H3ZMMrP8fYmhhHfsSRZbFCmbpLnSs18LimLkIcuGZb92f/WIdaQles6L0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAD2avlStJA2H/2dsb2JhbABbgwZSWIMHwQ2CGwEJhXECHIEMQwEBAQEBfYQNAQEEAQEBIEsbAgEGAj8DAgICHwYLFBEBAQQTiBgDEQ2gD5xsj18NhFABAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1PgiYLgmgugRMFjlmDR4QMgUSMOYVxIoFbghNvAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,435,1418083200"; d="scan'208,217";a="115340537" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 20 Jan 2015 18:14:31 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0KIEVek025976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 18:14:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.100]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 12:14:30 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL implementation Thread-Index: AdA0zpRTrxywcNHnQKKo/KHgU7rU9QAC4R+VAAC1kKg= Date: Tue, 20 Jan 2015 18:14:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DAB3656BCCBD403582D6D7E886891739ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 18:14:34 -0000 --_000_DAB3656BCCBD403582D6D7E886891739ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhjZWxsZW50IEpvw6NvICENCg0KSSdtIGFkZGluZyBpdCB0byBteSBsaXN0IPCfmIoNCg0KUGFz Y2FsDQoNCkxlIDIwIGphbnYuIDIwMTUgw6AgMTg6NTQsIEpvw6NvIFBlZHJvIFRhdmVpcmEgPGpv YW8ucC50YXZlaXJhQGdtYWlsLmNvbTxtYWlsdG86am9hby5wLnRhdmVpcmFAZ21haWwuY29tPj4g YSDDqWNyaXQgOg0KDQpIaSBEZWFyIFBhc2NhbCwNCg0KSSBzdGFydGVkIGEgUlBMIGltcGxlbWVu dGF0aW9uIG9uIExpbnV4IEtlcm5lbCAoaHR0cHM6Ly9naXRodWIuY29tL2pvYW9wZWRyb3RhdmVp cmEvbGludXgtcnBsKSB3aXRoIGJhc2ljIGZ1bmN0aW9uYWxpdGllcyBzdWNoIGFzIFJQTCBPRjAu IEkgdGVzdCBpdCB3aXRoIHNldmVyYWwgQVJNIGJvYXJkcyAoQkJXLCBSUGkgYW5kIG9saW51eGlu bykgYnV0IHNpbmNlIGtlcm5lbHMgdmVyc2lvbnMgYXJlIHNvIGRpZmZlcmVudCB0byB0aGlzIGJv YXJkcywgaXQgd2FzIHF1aXRlIGRpZmZpY3VsdCB0byBtYWludGFpbiBpdCB3b3JraW5nIGluIGFs bCB0aGlzIGRldmljZXMgYXQgc2FtZSB0aW1lIHdpdGggc28gbWFueSBrZXJuZWwgbmV0c3RhY2sg Y2hhbmdlcy4NCg0KQW55d2F5LCBhZnRlciBhIHdoaWxlIEkgZ290IHRpcmVkIHRvIHRyeSB0byBz dXBwb3J0IFJQTCBvbiB0aGlzIG9sZGVyIGtlcm5lbHMgKDMuOC55IGFuZCAzLjEwLnggZm9yIEJC QiBhbmQgUlBpKSBhbmQgbW92ZWQgZm9yd2FyZCB0byBnZXQgTVJIIE9GIHdvcmtpbmcgd2l0aCBy ZmM2NTUxIGFuZCBldHguIFRoaXMgY2hhbmdlcyBhcmUgbm90IG9uIGdpdGh1YiB5ZXQuDQoNClVz aW5nIENvbnRpa2kgd2l0aCByZjIzeCByYWRpb3MgYW5kIGxpbnV4IHdpdGggc2FtZSB0cmFuc2Nl aXZlcnMsIEkgc3RhcnRlZCB0byBpbXBsZW1lbnQgTVJIIChldHgpIHdpdGggcmZjNjU1MSBidXQg aXQgaGFzIGJlZW4gZGlmZmljdWx0IHRvIGdldCB0cmFuc2NlaXZlcnMgZGVsaXZlcnkgc3RhdHVz IGZyb20gcmFkaW8gbGlua3MuIFRoaXMga2luZCBvZiBpbmZvcm1hdGlvbiBpcyBub3QgYXZhaWxh YmxlIHlldCBvbiBsaW51eCBuZXRzdGFjayBhbmQsIGFmdGVyIHNvbWUgZW1haWxzIGV4Y2hhbmdl ZCB3aXRoIDZsb3dwYW4gbGludXggZ3JvdXAgYW5kIG5ldGRldiBncm91cCwgSSByZWFsaXNlZCB0 aGF0IGlmIEkgd2FudCBpdCBkb25lLCBJIHNob3VsZCBnZXQgaXQgd29ya2luZyBmaXJzdCBhbmQg dGhlbiBzdWJtaXQgaXQuIFVuZm9ydHVuYXRlbHksIEkgaGF2ZSBubyBhdmFpbGFibGUgdGltZSB0 byB3b3JrIG9uIHRoaXMsIGJ1dCBJIHdhbnQgdG8gY29udGludWUgdGhpcyBpbXBsZW1lbnRhdGlv biBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpCUiwNCkpvw6NvIFBlZHJvIFRhdmVpcmENCg0KDQpP biBUdWUgSmFuIDIwIDIwMTUgYXQgMTY6MzI6MjMgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8 cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+PiB3cm90ZToNCkRl YXIgYWxsIDoNCg0KSeKAmW0gY3VyaW91cyBhYm91dCB0aGUgcHJvZ3Jlc3Mgb2YgdGhlIHByb3Rv Y29sIGluc2lkZSBhbmQgb3V0c2lkZSBMTE4gZG9tYWlucy4NCkRvIHdlIGhhdmUgYSBzdGF0dXMg b24gY3VycmVudCBSUEwgaW1wbGVtZW50YXRpb25zIG92ZXJhbGw/DQpJbiBwYXJ0aWN1bGFyLCBk byB3ZSBoYXZlIG9wZW5zb3VyY2Ugb3V0c2lkZSBwdXJlIExMTiBkZXZpY2VzLCBlLmcuIGEgZ2Vu ZXJpYyBsaW51eCBpbXBsZW1lbnRhdGlvbiB0byBwbGF5IHdpdGg/DQoNCkNoZWVycywNCg0KUGFz Y2FsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9s bCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBp ZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbA0K --_000_DAB3656BCCBD403582D6D7E886891739ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkV4Y2VsbGVudCBKb8OjbyAhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ20g YWRkaW5nIGl0IHRvIG15IGxpc3Qg8J+Yijxicj4NCjxicj4NClBhc2NhbDwvZGl2Pg0KPGRpdj48 YnI+DQpMZSAyMCBqYW52LiAyMDE1IMOgIDE4OjU0LCBKb8OjbyBQZWRybyBUYXZlaXJhICZsdDs8 YSBocmVmPSJtYWlsdG86am9hby5wLnRhdmVpcmFAZ21haWwuY29tIj5qb2FvLnAudGF2ZWlyYUBn bWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5IaSBEZWFyIFBhc2NhbCw8YnI+DQo8YnI+DQpJIHN0 YXJ0ZWQgYSBSUEwgaW1wbGVtZW50YXRpb24gb24gTGludXggS2VybmVsICg8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vam9hb3BlZHJvdGF2ZWlyYS9saW51eC1ycGwiPmh0dHBzOi8vZ2l0aHVi LmNvbS9qb2FvcGVkcm90YXZlaXJhL2xpbnV4LXJwbDwvYT4pIHdpdGggYmFzaWMgZnVuY3Rpb25h bGl0aWVzIHN1Y2ggYXMgUlBMIE9GMC4gSSB0ZXN0IGl0IHdpdGggc2V2ZXJhbCBBUk0gYm9hcmRz IChCQlcsIFJQaSBhbmQgb2xpbnV4aW5vKQ0KIGJ1dCBzaW5jZSBrZXJuZWxzIHZlcnNpb25zIGFy ZSBzbyBkaWZmZXJlbnQgdG8gdGhpcyBib2FyZHMsIGl0IHdhcyBxdWl0ZSBkaWZmaWN1bHQgdG8g bWFpbnRhaW4gaXQgd29ya2luZyBpbiBhbGwgdGhpcyBkZXZpY2VzIGF0IHNhbWUgdGltZSB3aXRo IHNvIG1hbnkga2VybmVsIG5ldHN0YWNrIGNoYW5nZXMuJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5Bbnl3YXksIGFmdGVyIGEgd2hpbGUgSSBnb3QgdGlyZWQgdG8gdHJ5IHRvIHN1cHBv cnQgUlBMIG9uIHRoaXMgb2xkZXIga2VybmVscyAoMy44LnkgYW5kIDMuMTAueCBmb3IgQkJCIGFu ZCBSUGkpIGFuZCBtb3ZlZCBmb3J3YXJkIHRvIGdldCBNUkggT0Ygd29ya2luZyB3aXRoIHJmYzxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxZW07bGluZS1oZWlnaHQ6bm9y bWFsIj42NTUxIGFuZCBldHguIFRoaXMgY2hhbmdlcw0KIGFyZSBub3Qgb24gZ2l0aHViIHlldC48 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6 ZToxZW07bGluZS1oZWlnaHQ6bm9ybWFsIj48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjFlbTtsaW5lLWhlaWdodDpu b3JtYWwiPlVzaW5nIENvbnRpa2kgd2l0aCByZjIzeCByYWRpb3MgYW5kIGxpbnV4IHdpdGggc2Ft ZSB0cmFuc2NlaXZlcnMsIEkgc3RhcnRlZCB0byBpbXBsZW1lbnQgTVJIIChldHgpIHdpdGggcmZj NjU1MSBidXQgaXQgaGFzIGJlZW4gZGlmZmljdWx0IHRvIGdldCB0cmFuc2NlaXZlcnMgZGVsaXZl cnkgc3RhdHVzIGZyb20gcmFkaW8NCiBsaW5rcy4gVGhpcyBraW5kIG9mIGluZm9ybWF0aW9uIGlz IG5vdCBhdmFpbGFibGUgeWV0IG9uIGxpbnV4IG5ldHN0YWNrIGFuZCwgYWZ0ZXIgc29tZSBlbWFp bHMgZXhjaGFuZ2VkIHdpdGggNmxvd3BhbiBsaW51eCBncm91cCBhbmQgbmV0ZGV2IGdyb3VwLCBJ IHJlYWxpc2VkIHRoYXQgaWYgSSB3YW50IGl0IGRvbmUsIEkgc2hvdWxkIGdldCBpdCB3b3JraW5n IGZpcnN0IGFuZCB0aGVuIHN1Ym1pdCBpdC4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUt aGVpZ2h0Om5vcm1hbCI+VW5mb3J0dW5hdGVseSwNCiBJIGhhdmUgbm8gYXZhaWxhYmxlIHRpbWUg dG8gd29yayBvbiB0aGlzLCBidXQgSSB3YW50IHRvIGNvbnRpbnVlIHRoaXMgaW1wbGVtZW50YXRp b24gYXMgc29vbiBhcyBwb3NzaWJsZS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBj b2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PGJyPg0KPC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxl PSJsaW5lLWhlaWdodDpub3JtYWwiPkJSLDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6bm9ybWFsIj5Kb8OjbyBQ ZWRybyBUYXZlaXJhPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlIEphbiAyMCAyMDE1IGF0IDE2OjMyOjIz IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBj aXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPkRlYXIgYWxsJm5ic3A7Ojx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48dT48L3U+Jm5ic3A7PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBjdXJpb3VzIGFib3V0IHRo ZSBwcm9ncmVzcyBvZiB0aGUgcHJvdG9jb2wgaW5zaWRlIGFuZCBvdXRzaWRlIExMTiBkb21haW5z Ljx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2UgaGF2ZSBhIHN0 YXR1cyBvbiBjdXJyZW50IFJQTCBpbXBsZW1lbnRhdGlvbnMmbmJzcDtvdmVyYWxsPzx1PjwvdT48 dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFydGljdWxhciwgZG8gd2UgaGF2 ZSBvcGVuc291cmNlIG91dHNpZGUgcHVyZSBMTE4gZGV2aWNlcywgZS5nLiBhIGdlbmVyaWMgbGlu dXggaW1wbGVtZW50YXRpb24gdG8gcGxheSB3aXRoPzx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaGVlcnMsPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDx1PjwvdT48 dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzx1PjwvdT5fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Sb2xsQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHU+PC91 Pmxpc3RpbmZvL3JvbGw8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bh bj5Sb2xsIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86Um9s bEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DAB3656BCCBD403582D6D7E886891739ciscocom_-- From nobody Tue Jan 20 23:34:14 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D57F1A0389; Tue, 20 Jan 2015 23:34:12 -0800 (PST) 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] autolearn=ham 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 CznNOiwj1vhl; Tue, 20 Jan 2015 23:34:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D91A038E; Tue, 20 Jan 2015 23:34:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121073409.18284.69244.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 23:34:09 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jan 2015 07:34:12 -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 Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-03.txt Pages : 9 Date : 2015-01-20 Abstract: This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-03 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 Jan 21 09:46:18 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8031A1B49 for ; Wed, 21 Jan 2015 09:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DPwxSMeNytax for ; Wed, 21 Jan 2015 09:46:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D131A1B5D for ; Wed, 21 Jan 2015 09:46:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 074FA2009E for ; Wed, 21 Jan 2015 12:52:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 56307637FE; Wed, 21 Jan 2015 12:46:00 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3AC00637F4 for ; Wed, 21 Jan 2015 12:46:00 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] RPL implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jan 2015 17:46:13 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > I'm curious about the progress of the protocol inside and outside LLN domains. > Do we have a status on current RPL implementations overall? > In particular, do we have opensource outside pure LLN devices, e.g. a > generic linux implementation to play with? http://unstrung.sandelman.ca/ is an implementation for openwrt and smartphone class devices running Linux; it doesn't speak 6lowpan specifically; but some people have made it work with an not-yet-released linux device that had 802.15.4. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVL/l1YCLcPvd0N1lAQLDXwf/UWEfj9L/nLHFomuvVKecdhY4g34UkBME sujkB3ovE0+750ljzKdHSfA2q6zKDoQ0AWPdgEYrTPmhmjQ3UiRU9NBAuSJMZ5bD VA7ZYsVYa0hIjR+mE67wdmRzAFMAK4JJqM7k+Oru9gqV+IQ7M8424p0kfgJw33eT nzSkH4L2tBjAIf2Ov9m4AaHdq9vjkxGczv/BWwCtSwfdkXRkYVu4dYWy805LPFCo 3C54DlkIazdLyDSls2fgI03tTiS6HMUhjXICVdCRXrTUNaZYvDLku7V8pbPZf63f YOHZ8NGPpH3/v7qBMuyo3X4tsjEsOH7HAvWE1DSjET0G060EuWJA/Q== =A+zq -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 23 06:10:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D71A1AC6 for ; Fri, 23 Jan 2015 06:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PpT9jmnDMeB2 for ; Fri, 23 Jan 2015 06:10:01 -0800 (PST) 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 003A61A1A76 for ; Fri, 23 Jan 2015 06:10:00 -0800 (PST) Received: from localhost ([::1]:55701 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YEevl-00057k-7C; Fri, 23 Jan 2015 06:09:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 23 Jan 2015 14:09:49 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/137#comment:3 Message-ID: <082.dd82790b2240dab3fa4693bd36814ba6@trac.tools.ietf.org> References: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.com, mcr@sandelman.ca, 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: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #137 (applicability-ami): - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Jan 2015 14:10:02 -0000 #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments Comment (by mcr@sandelman.ca): FCAPS is a set of rather legacy protocols, CMIP and SNMP being the most well known. It has already been established that SNMP barely fits, and in most cases we need something both more secure and simpler. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Sun Jan 25 23:45:10 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8BE1A8712 for ; Sun, 25 Jan 2015 23:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=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 BToXSC_nvu20 for ; Sun, 25 Jan 2015 23:45:06 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE011A7017 for ; Sun, 25 Jan 2015 23:45:05 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t0Q7j3wB016897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jan 2015 16:45:03 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t0Q7j3SZ013863 for ; Mon, 26 Jan 2015 16:45:03 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 349 for ; Mon, 26 Jan 2015 16:45:03 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t0Q7j3NY013860 for ; Mon, 26 Jan 2015 16:45:03 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t0Q7j3Pr003197 for roll@ietf.org; Mon, 26 Jan 2015 16:45:03 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA03162; Mon, 26 Jan 2015 16:45:00 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t0Q7iwVq022320 for ; Mon, 26 Jan 2015 16:44:59 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id t0Q7gv7m007243; Mon, 26 Jan 2015 16:42:57 +0900 (JST) Received: from [133.196.16.128] (ncg-dhcp128.isl.rdc.toshiba.co.jp [133.196.16.128]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 7D0CD97D5C for ; Mon, 26 Jan 2015 16:42:57 +0900 (JST) Message-ID: <54C5F009.6040307@toshiba.co.jp> Date: Mon, 26 Jan 2015 16:43:05 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <20150121073409.18284.69244.idtracker@ietfa.amsl.com> In-Reply-To: <20150121073409.18284.69244.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 07:45:08 -0000 Dear all, Last week I updated the MPL parameter config draft. I found no major discussion point. Is this ready for the next step? Regards, Yusuke On 2015-01-21 16:34, internet-drafts@ietf.org wrote: > > 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 Working Group of the IETF. > > Title : MPL Parameter Configuration Option for DHCPv6 > Authors : Yusuke Doi > Matthew Gillmore > Filename : draft-ietf-roll-mpl-parameter-configuration-03.txt > Pages : 9 > Date : 2015-01-20 > > Abstract: > This draft defines a way to configure a parameter set of MPL > (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 > option. MPL has a set of parameters to control its behavior, and the > parameter set is often configured as a network-wide parameter because > the parameter set should be identical for each MPL forwarder in an > MPL domain. Using the MPL Parameter Configuration Option defined in > this document, a network can be configured with a single set of MPL > parameter easily. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-03 > > > 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/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Mon Jan 26 07:01:28 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1DC1A8F4F for ; Mon, 26 Jan 2015 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KIYeoEQQ6xTz for ; Mon, 26 Jan 2015 07:01:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729E51A900A for ; Mon, 26 Jan 2015 07:01:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2FC81200A1 for ; Mon, 26 Jan 2015 10:07:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6C403637FE; Mon, 26 Jan 2015 10:01:07 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4D6A063745 for ; Mon, 26 Jan 2015 10:01:07 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <54C5F009.6040307@toshiba.co.jp> References: <20150121073409.18284.69244.idtracker@ietfa.amsl.com> <54C5F009.6040307@toshiba.co.jp> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 15:01:26 -0000 --=-=-= Content-Type: text/plain Yusuke DOI wrote: > Last week I updated the MPL parameter config draft. > I found no major discussion point. Is this ready for the next step? Yes, I think it is time to assign a document shepherd (are there any volunteers?), and start a WG LC on the document. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVMZWsICLcPvd0N1lAQKrnggAlNj3hV59rDWabZ2dVkmFN24yt30GrH5p ifRxY1KiBTOQusoLOF25a0n1lHzd/QBiDjsofEvgs+lm1Iy7DQYO0L2/FqSqEbya /wMDbiCWap0OSIG/KItRqfP2s8jepehxTDZhBzToL6LJlY21x4NfQsBJWannkHVL NuPv/XQQ0b5tuFpDAPGhhHXvkov6oGnrcV1pDTFen4wryHfNZ9s8ynb3EoE2raht bLGjsGXOHO4qpgs3PB01/qdcJQnBX5JpDLQlr2glN2lK1EBmYr57y9OHsjhuBQfD BM29pTCeLHTixmMv6LUy3hLmKcd/52+bP1smJAskCUW/lUFqCUa/dA== =8Nca -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 30 13:51:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274141A702D; Fri, 30 Jan 2015 13:51:11 -0800 (PST) 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] autolearn=ham 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 CYxASN8anftG; Fri, 30 Jan 2015 13:51:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E36E1A07BE; Fri, 30 Jan 2015 13:51:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130215109.18539.21253.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 13:51:09 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jan 2015 21:51:11 -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 Working Group of the IETF. Title : Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks Authors : Daniel Popa Matthew Gillmore Laurent Toutain Jonathan Hui Kazuya Monden Nancy Cam-Winget Filename : draft-ietf-roll-applicability-ami-10.txt Pages : 24 Date : 2015-01-30 Abstract: This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-ami-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-ami-10 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 Fri Jan 30 15:33:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44E1A87E1; Fri, 30 Jan 2015 15:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=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 Lkv5L43QbAjE; Fri, 30 Jan 2015 15:33:35 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCF51A8822; Fri, 30 Jan 2015 15:33:31 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so38783562lbj.0; Fri, 30 Jan 2015 15:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wsCnZYD+YMdPr9rFZksBqBR0EH7Xsb30gh2WwIdNNl8=; b=i1Nz2tjmq4L/q6bpxsQ2G10UGAAFTkMzRumWWaFi77vXimcVSkHLsND30v4fsTyO4B cO1+I1I1LlpMTKFFqNJRh9qrGLbC/pKjyO+B76NmwQBjMkUCHArVUwZ7TCV0khzkjtdb lMzCV9osBDpmjqRMhmFHNhAUsiPS+FMSw/yuYV3sI8LJ/1+vpoR3buh5gCnZWvgKyugl oDImFx4xtYrl664NiAxdLnoeypDPyznV7s0mFHZjJ5kaa1YfAYHUIqCszMxVSHigGeom Z5En/scjf4fH6phmIw9xlG+AXLSsZkhuF8Ic6MSEs0ASl80zfAxrk/x6mB4ycWdDTgt6 xZpQ== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr8933498lbb.1.1422660809879; Fri, 30 Jan 2015 15:33:29 -0800 (PST) Received: by 10.25.39.129 with HTTP; Fri, 30 Jan 2015 15:33:29 -0800 (PST) In-Reply-To: <7200.1421359216@sandelman.ca> References: <7200.1421359216@sandelman.ca> Date: Sat, 31 Jan 2015 01:33:29 +0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e0112c86c35752a050de708cf Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man@ietf.org, Brian Haberman , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jan 2015 23:33:37 -0000 --089e0112c86c35752a050de708cf Content-Type: text/plain; charset=UTF-8 Hi, Please find a draft of the slides here http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-0.pdf Any comments are very welcome, Thanks, Michael and Ines 2015-01-16 0:00 GMT+02:00 Michael Richardson : > > In accordance with: > https://www.ietf.org/iesg/statement/interim-meetings.html > the ROLL Working Group Chairs are announcing a virtual interim meeting for > February 10, 2015, from 15:00 UTC to 18:00 UTC. > (please see: http://goo.gl/NVefsy to convert the time) > > The very draft agenda is in development, and can be seen at: > > http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 > > The goal of this interim meeting is to do a deep technical dive into the > different ways of optimizing the byte/power cost of the RFC6553 (RPI) and > RFC6554 (RH3) options. This could involve compression or recoding, or??? > We invite submissions on this. Please post your -00 draft by January 23 if > possible, or point us at your other drafts. > > We will use JITSI for audio, video and slides, with the following URL: > https://jitsi.tools.ietf.org/Roll20150210VirtualInterim > Participants are encouraged to visit this URL in advance to verify that > it works for them. If you need another participant to help verify, > please > email me. > > There will be a PSTN bridge for a backup, should things completely fail. > We will have a dial-in phone number connected to the bridge for those that > are unable to connect with a computer, but it won't be toll-free. > The phone numbers involved will be posted to the agenda as it is finalized, > and we expect to distribute slides by January 27, 2015. > > (BTW: we do not believe that ROLL will meet in Dallas/IETF92) > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0112c86c35752a050de708cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find a draft of the sl= ides here=C2=A0http://www.ietf.org/proceed= ings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-0.pdf

Any comments are very welcome,

<= div>Thanks,

Michael and Ines

2015-01-16 0:00 GMT+02:00 Michael= Richardson <mcr+ietf@sandelman.ca>:

In accordance with: https://www.ietf.org/iesg/statement/interi= m-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for<= br> February 10, 2015, from 15:00 UTC to 18:00 UTC.
=C2=A0 =C2=A0 =C2=A0 (please see: http://goo.gl/NVefsy to convert the time)

The very draft agenda is in development, and can be seen at:
=C2=A0 http://www.ietf.org/pro= ceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1

The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options.=C2=A0 This could involve compression or recoding, or= ???
We invite submissions on this.=C2=A0 Please post your -00 draft by January = 23 if
possible, or point us at your other drafts.

We will use JITSI for audio, video and slides, with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.tools.ietf.org/Roll20150210Vir= tualInterim
=C2=A0 Participants are encouraged to visit this URL in advance to verify t= hat
=C2=A0 it works for them.=C2=A0 If you need another participant to help ver= ify, please
=C2=A0 email me.

There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that<= br> are unable to connect with a computer, but it won't be toll-free.
The phone numbers involved will be posted to the agenda as it is finalized,=
and we expect to distribute slides by January 27, 2015.

(BTW: we do not believe that ROLL will meet in Dallas/IETF92)



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/roll/cha= rter/


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


--089e0112c86c35752a050de708cf-- From nobody Fri Jan 30 15:52:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF11A877A for ; Fri, 30 Jan 2015 15:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rVmY698mEG_6 for ; Fri, 30 Jan 2015 15:52:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9386B1A87DF for ; Fri, 30 Jan 2015 15:52:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4AF0E200A7; Fri, 30 Jan 2015 18:59:10 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 17E61637F6; Fri, 30 Jan 2015 18:52:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0422C637EC; Fri, 30 Jan 2015 18:52:25 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <20150130215109.18539.21253.idtracker@ietfa.amsl.com> References: <20150130215109.18539.21253.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Nancy Cam-Winget Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jan 2015 23:52:28 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > Title : Applicability Statement for the Routing Protocol for > Low Power and Lossy Networks (RPL) in AMI Networks Thanks to Nancy for agreeing to revise this document. I would ask all WG participants to read it anew, and to review the open tickets on it, and see if we are making progress towards getting this into WGLC. Ines & Michael -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVMwZOICLcPvd0N1lAQKsWAf8CLYvlxF6mnE1e4EmEZemEzW/pRylnoRs 6rF91WgiOixpbtGYiBDiPFv2tb9ho4zThJxQ0g5wuQW32Jbri9+neOCZmgp4NiFU VW1WBfTAK44vwGkcZ7qOuxUGQyAwSL294gy4bYqoUVpxOvTZvJUGGPrSogDk5z1R oaMuiCfpRrCwsHpK8397FiVcU/dd3EEyezH0FcpBH8NrJ/6tFWu1m+VSwiZ+tGLD kYrwThorMeYCR9Gw3QqW/lNigW8kjAMSpHu/G63qXd9QCKUVpVgi6OGl1ELgn2Pi J9DOgQnsgLu7bbItIHTe72985csmcVLYleD0VhYIoPiZM2KAjJa6hQ== =nlEe -----END PGP SIGNATURE----- --=-=-=--