From nobody Mon Nov 3 15:42:54 2014 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 851671A1A97; Mon, 3 Nov 2014 15:42: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 RUJb2K3CTZ3o; Mon, 3 Nov 2014 15:42: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 CD7871A1A4A; Mon, 3 Nov 2014 15:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sA3Ngahr004743; Tue, 4 Nov 2014 00:42:36 +0100 (CET) Received: from alma.local.informatik.uni-bremen.de (robin.informatik.uni-bremen.de [134.102.218.1]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3C69495C; Tue, 4 Nov 2014 00:42:36 +0100 (CET) X-Mailer: emacs 25.0.50.1 (via feedmail 11-beta-1 I) From: Carsten Bormann To: bier@ietf.org, 6lo@ietf.org, roll@ietf.org Date: Tue, 04 Nov 2014 00:42:32 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5AukRx0fBpfqhfpgf-p5eDyewrs Cc: Andrzej.Duda@imag.fr Subject: [Roll] Source-Routed Multicast 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, 03 Nov 2014 23:42:42 -0000 In Hawaii, there will be a BOF about a multicast forwarding control scheme where a router on the way prefixes a multicast packet with a special header that tells downtree routers where to forward the multicast =E2=80=94 Bit Index Explicit Replication, or BIER. While BIER appears to be very focused on a carrier or datacenter perspective (see draft-kumar-bier-use-cases and the other draft-*-bier-*), there are applications in constrained node networks that would benefit from source-routed multicast. Several proposals on how to do source-routed multicast in constrained node networks are getting ready for consumption. With its current focus, I don=E2=80=99t think the BIER BOF itself is the ri= ght place to have a technical discussion about this. There is no ROLL meeting in Hawaii. The 6lo agenda is almost full. Should we do this in a side meeting? (If we do this before Tuesday, we can at least report in 6lo =E2=80=94 if we do it on Sunday, we might even h= ave an opinion to air during the BIER BOF.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 3 18:18:21 2014 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 9CF281A1BCE; Mon, 3 Nov 2014 18:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 5B71E_waDL5p; Mon, 3 Nov 2014 18:18:18 -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 2CD291A1BBD; Mon, 3 Nov 2014 18:18:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A95920028; Mon, 3 Nov 2014 21:19:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 12933637F4; Mon, 3 Nov 2014 21:18:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F1BA263740; Mon, 3 Nov 2014 21:18:16 -0500 (EST) From: Michael Richardson To: Carsten Bormann In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hTMsPRCohYSSDzy7sU5h82wOhfw Cc: Andrzej.Duda@imag.fr, roll@ietf.org, bier@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [6lo] Source-Routed Multicast 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, 04 Nov 2014 02:18:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > In Hawaii, there will be a BOF about a multicast forwarding control > scheme where a router on the way prefixes a multicast packet with a > special header that tells downtree routers where to forward the > multicast =E2=80=94 Bit Index Explicit Replication, or BIER. > While BIER appears to be very focused on a carrier or datacenter > perspective (see draft-kumar-bier-use-cases and the other > draft-*-bier-*), there are applications in constrained node networks > that would benefit from source-routed multicast. I take your point. > With its current focus, I don=E2=80=99t think the BIER BOF itself is = the right > place to have a technical discussion about this. On the contrary, I think it is important at a BOF for this topic to be brought up, if ONLY for it to be CLEARLY ruled out of scope. > There is no ROLL meeting in Hawaii. > The 6lo agenda is almost full. ROLL would have to be rechartered to work on it; this is not to say that th= is could not happen, but rather to say that even if we were meeting, discussing it might be out of scope anyway. Having said that, this thread is most welcome. > Should we do this in a side meeting? (If we do this before Tuesday, = we > can at least report in 6lo =E2=80=94 if we do it on Sunday, we might = even have > an opinion to air during the BIER BOF.) I abhor "side meetings" --- either have a proper BOF in a room, or get a bunch of beers is my opinion. =2D- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFg3ZYCLcPvd0N1lAQIMlgf9EKuKoUzuLFaam9hhusy+J7IiNSiMxtnV tCTOl2n/Nd6Ba+lPV7f4U2TzsebUWGBemGkb5//NF4JqfNtVNYJhObtB3MHiNnuE SldbYiCin4dD4eWPdSseCrTVXd36wnGPtwdgrXGuzQKlfgCiDe/kOYCrxzmTkW4K vvQsRwf2pw5rVb2E0elmm0KQ3NyO4nB/vaH/7EZ9tS0tz6TGj9VLvvE/iiVmT+Jx Zbshdb+Csj/jmOqc3EQzAD2wJrmIgXaWI4ML9EblV/LrykXO5CK1Srk82JLsDfE8 gcAj4FzL9cY6beJnBPqaFBw73MPqrWqIAyF7fdns+c5y1qFm8hdErw== =O2d8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 3 18:25:12 2014 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 2D7621A1AB7; Mon, 3 Nov 2014 16:01:38 -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 M53E72a7P2LG; Mon, 3 Nov 2014 16:01:35 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3000D1A1AAB; Mon, 3 Nov 2014 16:01:35 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so13580770wgg.8 for ; Mon, 03 Nov 2014 16:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0XxPHITu3JqqJFxfPoWC28l7RbVABHljGwm1csY3iqs=; b=krA5KbxA5jXcjkc1D+QXwENwHbSp1Qqv+kqkqlf6ApmAp5kvcICtl+EneF3JEEn9dw wiAc5jk1uEuIEEdLnRKmZNv2agkgGpE5HP5s1rM4Ro1ngA1XC3IECzQT7Wy+oNOYLERn WJBKUhYowObTwcWzReI153lzfziCt2gUN9T6P29RachzDX2Pw/R4EZN2E3ijQl6aVFtH 5B2ofTx80yXbL3RJ6Q7XUNYckLVp/eMT//Zsxh7uu88g9eVCtWX973O5GlFScpFb+AAs +g+leNG8po0hEX5BwJvb0BZ54CNKdH6X2iFqpU+uru44DeqlfcrcDICiEIoPr0Wq//29 VRSQ== MIME-Version: 1.0 X-Received: by 10.180.106.104 with SMTP id gt8mr19600982wib.51.1415059293762; Mon, 03 Nov 2014 16:01:33 -0800 (PST) Received: by 10.180.20.79 with HTTP; Mon, 3 Nov 2014 16:01:33 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 16:01:33 -0800 Message-ID: From: Greg Shepherd To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d04428ee28a78bc0506fd2a6b Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qGo7OES1MhLA3N73mxhPi_tcTgA X-Mailman-Approved-At: Mon, 03 Nov 2014 18:25:10 -0800 Cc: Andrzej.Duda@imag.fr, roll@ietf.org, "bier@ietf.org" , 6lo@ietf.org Subject: Re: [Roll] [Bier] Source-Routed Multicast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.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: Tue, 04 Nov 2014 00:01:38 -0000 --f46d04428ee28a78bc0506fd2a6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sunday works for me. Greg On Mon, Nov 3, 2014 at 3:42 PM, Carsten Bormann wrote: > In Hawaii, there will be a BOF about a multicast forwarding control > scheme where a router on the way prefixes a multicast packet with a > special header that tells downtree routers where to forward the > multicast =E2=80=94 Bit Index Explicit Replication, or BIER. > > While BIER appears to be very focused on a carrier or datacenter > perspective (see draft-kumar-bier-use-cases and the other > draft-*-bier-*), there are applications in constrained node networks > that would benefit from source-routed multicast. > > Several proposals on how to do source-routed multicast in constrained > node networks are getting ready for consumption. > > With its current focus, I don=E2=80=99t think the BIER BOF itself is the = right > place to have a technical discussion about this. > There is no ROLL meeting in Hawaii. > The 6lo agenda is almost full. > Should we do this in a side meeting? (If we do this before Tuesday, we > can at least report in 6lo =E2=80=94 if we do it on Sunday, we might even= have > an opinion to air during the BIER BOF.) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --f46d04428ee28a78bc0506fd2a6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sunday works for me.

Greg

On Mon, Nov 3, 2014= at 3:42 PM, Carsten Bormann <cabo@tzi.org> wrote:
In Hawaii, there will be a BOF about a multicast forwar= ding control
scheme where a router on the way prefixes a multicast packet with a
special header that tells downtree routers where to forward the
multicast =E2=80=94 Bit Index Explicit Replication, or BIER.

While BIER appears to be very focused on a carrier or datacenter
perspective (see draft-kumar-bier-use-cases and the other
draft-*-bier-*), there are applications in constrained node networks
that would benefit from source-routed multicast.

Several proposals on how to do source-routed multicast in constrained
node networks are getting ready for consumption.

With its current focus, I don=E2=80=99t think the BIER BOF itself is the ri= ght
place to have a technical discussion about this.
There is no ROLL meeting in Hawaii.
The 6lo agenda is almost full.
Should we do this in a side meeting?=C2=A0 (If we do this before Tuesday, w= e
can at least report in 6lo =E2=80=94 if we do it on Sunday, we might even h= ave
an opinion to air during the BIER BOF.)

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier

--f46d04428ee28a78bc0506fd2a6b-- From nobody Tue Nov 4 01:46:16 2014 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 61F5E1A8935 for ; Tue, 4 Nov 2014 01:46:14 -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 v-86esswq6nJ for ; Tue, 4 Nov 2014 01:46:11 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFD81A8934 for ; Tue, 4 Nov 2014 01:46:11 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.209]) by smtp-cloud3.xs4all.net with ESMTP id BMm91p00B4WfiVN01Mm9vQ; Tue, 04 Nov 2014 10:46:09 +0100 Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 04 Nov 2014 10:46:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 04 Nov 2014 10:46:09 +0100 From: peter van der Stok To: Yvonne-Anne Pignolet Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3dc940374515412880bd6f8123508e7e@DB4PR06MB047.eurprd06.prod.outlook.com> References: <3dc940374515412880bd6f8123508e7e@DB4PR06MB047.eurprd06.prod.outlook.com> Message-ID: X-Sender: stokcons@xs4all.nl (RSJ0w7rr8nakjHF2yWZyilNoqJzEsW5e) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/WvMX0Twk2A3Klpkl5EGLk2F9YSk Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-05.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: Tue, 04 Nov 2014 09:46:14 -0000 HI Yvonne, thank you for your interest and your detailed suggestions. A subset is answered below. Possibly one of my co-authors wants to correct or improve my answers. Peter Yvonne-Anne Pignolet schreef op 2014-10-21 19:23: > Dear Anders, Emmanuel, Robert, Peter > > Thanks for the updated draft. I have a few questions and comments and > would like your feedback as well as opinion from the mailing list. > > 1. In 2.2.7. The authors argue that P2P-RPL is required for P2P and > P2MP traffic in home and building automation LLNs instead of basic > RPL. > > I fully agree that P2P-RPL is used for P2P traffic, but for P2MP > traffic it often makes sense to use basic LLN, also in home and > building automation LLNs. I suggest to include both P2P-RPL and basic > RPL in the recommended protocol portfolio for home and building > automation. I think we did in section 2.2.7 first phrase, where we mention that RPL is useful in the context of the SS paradigm where multiple servers send data to a central client which may be situated on a backbone. We reserve P2P-RPL specifically for P2P and P2MP traffic. > > 2. (related to 1.) In 4.1.3. The authors consider DAO policy to be > out of scope. However, if basic RPL is applicable for home and > building automation scenarios then due to P2MP traffic from roots > DAOs are required. As in the industrial applicability statement I thus > recommend a paragraph such as "Nodes send DAO messages to establish > downward paths from the root to themselves. DAO messages are not > acknowledged in networks composed of battery operated field devices in > order to minimize the power consumption overhead associated with path > discovery. If devices in LLNs participate in multiple RPL instances > and DODAGs, it is highly recommended that both the RPLInstance ID and > the DODAGID be included in the DAO." If the mailing list consensus is > that P2P RPL is to be used only, then this Section should state that > DAO messages are not sent in this case. In addition a comment on > P2P-DRO Acknowledgement (P2P-DRO-ACK) would be helpful Some text to motivate the out of scope of DAO policy can be added. For the multiple RPL instances, I prefer to include a reference to other texts. > > 3. Please correct 4.1.4. OF0 is not a metric. Did you mean ETX or HC? > Or another metric from http://tools.ietf.org/html/rfc6551#section-6.1 > ? Understood, We'll come with a better recommendation > > 4. Please state why a value of DIO max interval of 4.37min (16ms x > 2^14) is appropriate, it seems like a much smaller value would be > suitable for this usecase I don't understand the issue here. When something happens the 16 ms come into play. Assuming a limited number of hops, the change propagates quite timely. When nothing happens, sending a reminder every 4 minutes seems quite reasonable. (we are discussing propagation of network changes, not user commands) > > 5. About Section 6, 2hy would manageability be out of scope for home > network scenarios? And can you give more detail on what central > control based on MIBs entails? I think the whole discussion on how home networks are managed is still on going. And what to manage is also not clear. For example: will the ISP set the RPL parameter values in the nodes in my home and acquire statistics on packet fragmentation? In building automation, setting configuration parameters seems necessary (for example the MPL parameter values). Some people think this should be done via DHCP. So removing the last phrase of section 6 will improve the clarity. Greetings, Peter > > Regards > Yvonne-Anne > > Yvonne-Anne Pignolet > Dr. Sc. ETH Zürich > ABB Corporate Research > Segelhofstrasse 1K > 5400 Baden-Dättwil, Switzerland > Phone: +41 58 586 86 56 > Mobile: +41 79 766 10 54 > email: yvonne-anne.pignolet@ch.abb.com > > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Dienstag, 7. Oktober 2014 00:10 > To: roll@ietf.org > Subject: [Roll] Fwd: I-D Action: > draft-ietf-roll-applicability-home-building-05.txt > > Dear wg, > > We submitted draft nr 5 of the home building applicability draft. > Major changes with respect to draft nr 4 > > o Large editing effort to streamline text > > o Rearranged Normative and Informative references > > o Replaced RFC2119 terminology by non-normative terminology > > o Rearranged section 5 to better separate the subjects > > o Rearranged text of section 7, 7.1, and 7.2 to agree with the > intention of section 7.2 as described in applicability template. > > We consider the draft as done and look forward to the next step: wglc. > > Peter > > -------- Oorspronkelijke bericht -------- > Onderwerp: [Roll] I-D Action: > draft-ietf-roll-applicability-home-building-05.txt > Datum: 2014-10-06 09:43 > Afzender: internet-drafts@ietf.org > Ontvanger: i-d-announce@ietf.org > Kopie: roll@ietf.org > Antwoord-aan: Routing Over Low power and Lossy networks > > 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-05.txt > Pages : 30 > Date : 2014-10-06 > > 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-05 > > > 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 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Nov 4 10:21:35 2014 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 8CD9B1A8A3C; Tue, 4 Nov 2014 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 FrcOBTTNdgM6; Tue, 4 Nov 2014 07:37:07 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CE91A8A3E; Tue, 4 Nov 2014 07:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1796; q=dns/txt; s=iport; t=1415115427; x=1416325027; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wVYMahAxZyiJblGapVR4LjBVTEHGKNv5NnHtgPoVnF0=; b=Hh5FWkH7/nY7T0hTTSHrAjzVfSXaJH19Kuj5AOfs/I2bmBpOwG3BksMZ wGItilhyGbTWdMp7uQ+57txDBedxbABpCjbgcqKq54nkWFvVGO3rNIuPO 1I+ywo0+L2UJHqy9EAhCdS22Ou9L8cDq1WW201O75JRd42iO4n+dYtsZ+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALjxWFStJA2L/2dsb2JhbABcgw5UWATOUwqHTQKBHxYBAQEBAX2EAgEBAQQBAQFkBwsMBAIBCBEDAQIBLiEGCxQJCAIEAQ0FiCwDEg3GaA2GKQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjlaCDysHBoRFAQSSIIlWghGPX4Zwg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="93236152" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 04 Nov 2014 15:37:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sA4Fb5kj021686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 15:37:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 09:37:05 -0600 From: "Rajiv Asati (rajiva)" To: "gjshep@gmail.com" , Carsten Bormann Thread-Topic: [Bier] Source-Routed Multicast Thread-Index: AQHP97/gpz3UHL2ClUOaJ+Zqtf7hK5xP+hGAgACgygA= Date: Tue, 4 Nov 2014 15:37:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.221.67] Content-Type: text/plain; charset="Windows-1252" Content-ID: <476B0C17770E724C974B07F636D81E6F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/MnzVJYeHh_vxQcChTJDnBuGc0rs X-Mailman-Approved-At: Tue, 04 Nov 2014 10:21:29 -0800 Cc: "Andrzej.Duda@imag.fr" , "roll@ietf.org" , "bier@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 04 Nov 2014 15:37:09 -0000 +1 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: "gjshep@gmail.com" Reply-To: "gjshep@gmail.com" Date: Monday, November 3, 2014 at 8:01 PM To: Carsten Bormann Cc: "Andrzej.Duda@imag.fr" , "roll@ietf.org" , "bier@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Bier] Source-Routed Multicast >Sunday works for me. > > >Greg > > >On Mon, Nov 3, 2014 at 3:42 PM, Carsten Bormann > wrote: > >In Hawaii, there will be a BOF about a multicast forwarding control >scheme where a router on the way prefixes a multicast packet with a >special header that tells downtree routers where to forward the >multicast =8B Bit Index Explicit Replication, or BIER. > >While BIER appears to be very focused on a carrier or datacenter >perspective (see draft-kumar-bier-use-cases and the other >draft-*-bier-*), there are applications in constrained node networks >that would benefit from source-routed multicast. > >Several proposals on how to do source-routed multicast in constrained >node networks are getting ready for consumption. > >With its current focus, I don=B9t think the BIER BOF itself is the right >place to have a technical discussion about this. >There is no ROLL meeting in Hawaii. >The 6lo agenda is almost full. >Should we do this in a side meeting? (If we do this before Tuesday, we >can at least report in 6lo =8B if we do it on Sunday, we might even have >an opinion to air during the BIER BOF.) > >Gr=FC=DFe, Carsten > >_______________________________________________ >BIER mailing list >BIER@ietf.org >https://www.ietf.org/mailman/listinfo/bier > > > > > From nobody Tue Nov 4 14:52:09 2014 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 997461A02F1; Tue, 4 Nov 2014 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 PCsCdCXRighI; Tue, 4 Nov 2014 14:52:00 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) (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 233A01A0277; Tue, 4 Nov 2014 14:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sA4MosoV029060; Tue, 4 Nov 2014 23:50:54 +0100 (CET) Received: from [192.168.217.113] (p54892E83.dip0.t-ipconnect.de [84.137.46.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 73A252FE; Tue, 4 Nov 2014 23:50:52 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 4 Nov 2014 23:50:50 +0100 X-Mao-Original-Outgoing-Id: 436834250.592611-9c57e15d318f9248d6425265b403cca7 Content-Transfer-Encoding: quoted-printable Message-Id: <300194F7-D81F-4F2B-923A-BA6EF09DC334@tzi.org> References: To: IJsbrand Wijnands X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/GuizR5HDKCOr4rzR7FtWlKEfrsY Cc: Andrzej.Duda@imag.fr, roll@ietf.org, bier@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 04 Nov 2014 22:52:03 -0000 > Just one clarification, BIER is not Source-Routed multicast. i.e. we = don=92t include a list of hops that the packet needs to follow, we only = include final destination in the form of Bit Positions, and each router = along the path does a lookup on the Bit Position to determine where the = packet is to be sent. Indeed, that=92s why I titled this E-mail =93Source-Routed Multicast=94 = so it is clear it is not the same as BIER. Source-routing is important = for RPL=92s non-storing mode, where intermediate routers just don=92t = know what is below them. (BIER could be applied to RPL=92s storing = mode, but then that already has a multicast approach written up, and = it=92s also not that clear that storing mode actually exists. The next = question would then be whether RPL networks are stable enough to have a = stable egress router numbering applied to them.) It seems several people would be able to make a Sunday hallway chat = about this general approach. Since I=92m officially at a couple of = meetings (in parallel) from 1600, how about 1500? Gr=FC=DFe, Carsten From nobody Tue Nov 4 17:24:16 2014 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 216BA1A0195; Tue, 4 Nov 2014 14:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 CDy_dwAmPZBW; Tue, 4 Nov 2014 14:28:15 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5F81A0151; Tue, 4 Nov 2014 14:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1415140096; x=1416349696; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9pcVRDWwKSx5jvh/X3Zn/4Qxs4+vSAFLwiDAtnTOX6E=; b=FW1xzN8H41ggRY+e9FNfRXfPGx0ZtmQNDC6dhE9G2NToTPsNRuGFcQPq uefJZ4dAg/BZcnOlfztkFE7/lhSOEf2wRtFZG0jsWGQjNy1s20oW70e1o cqt99mBPmUov/csAu08dqOQgY83lKSDjA7QjhIHv31NXVe3MEO42tcFHx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoLAAxSWVStJV2U/2dsb2JhbABbgw5UWbsKBQF0kloKh00CgSMWAQEBAQF9hAMBAQMBAQEBZAcLBQsLDjgnMAYTiDgJDcRJAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGN4omMweDLYEeBYt7khOHdI5ehBkcL4JLAQEB X-IronPort-AV: E=Sophos;i="5.07,315,1413244800"; d="scan'208";a="369307074" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2014 22:28:15 +0000 Received: from [10.154.176.153] ([10.154.176.153]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA4MSDO4023842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Nov 2014 22:28:14 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: IJsbrand Wijnands In-Reply-To: Date: Tue, 4 Nov 2014 14:28:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carsten Bormann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/cpMH_X4mkCbkEXcBLicR63BDCnc X-Mailman-Approved-At: Tue, 04 Nov 2014 17:24:15 -0800 Cc: Andrzej.Duda@imag.fr, roll@ietf.org, bier@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 04 Nov 2014 22:28:18 -0000 Hi Carsten, The ROLL case looks very interesting. Just one clarification, BIER is not Source-Routed multicast. i.e. we = don=92t include a list of hops that the packet needs to follow, we only = include final destination in the form of Bit Positions, and each router = along the path does a lookup on the Bit Position to determine where the = packet is to be sent. Thx, Ice. On 03 Nov 2014, at 15:42, Carsten Bormann wrote: > In Hawaii, there will be a BOF about a multicast forwarding control > scheme where a router on the way prefixes a multicast packet with a > special header that tells downtree routers where to forward the > multicast =97 Bit Index Explicit Replication, or BIER. >=20 > While BIER appears to be very focused on a carrier or datacenter > perspective (see draft-kumar-bier-use-cases and the other > draft-*-bier-*), there are applications in constrained node networks > that would benefit from source-routed multicast. >=20 > Several proposals on how to do source-routed multicast in constrained > node networks are getting ready for consumption. >=20 > With its current focus, I don=92t think the BIER BOF itself is the = right > place to have a technical discussion about this. > There is no ROLL meeting in Hawaii. > The 6lo agenda is almost full. > Should we do this in a side meeting? (If we do this before Tuesday, = we > can at least report in 6lo =97 if we do it on Sunday, we might even = have > an opinion to air during the BIER BOF.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Tue Nov 4 18:10:53 2014 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 157391A1A25; Tue, 4 Nov 2014 18:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 q4LwR_V74l7S; Tue, 4 Nov 2014 18:10:50 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8CC1A8779; Tue, 4 Nov 2014 18:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2898; q=dns/txt; s=iport; t=1415153450; x=1416363050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ESeaVLb5V2p1wYAUTyV5PoiAaAilDeGrMji6dhkUaWE=; b=YfY7kMqIQ9ge8f/ffm2c02HqmrMW5/J1iGrnSLd8xLXPnFxZyXpxzUtb /ZT58DcJbDaMr02N55oZNPvRx8pEAk2q5Qbb3Md1/E9oB3uznHJirFFM2 liwe6p1dDUcncGfKLwubuBdyHCC0RC79XrlPA37/DBLVdY4GBh9ORe0AE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMWGWVStJV2Z/2dsb2JhbABbgw5UWQTOYgqHTQKBGBYBAQEBAX2EAgEBAQQBAQFkBwsMBAIBCBEEAQEBCh0HJwsUCQgCBAENBQiIOQ3GfwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkDgnMQcGgyeBHgWLPYZkoj+DeGyBBkKBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,316,1413244800"; d="scan'208";a="93427750" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 05 Nov 2014 02:10:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA52AnOg031183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Nov 2014 02:10:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 20:10:49 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , Carsten Bormann Thread-Topic: [Roll] [Bier] Source-Routed Multicast Thread-Index: AQHP+Jc6eJPa1iU6+EqbNCABEErj65xRRsVA Date: Wed, 5 Nov 2014 02:10:47 +0000 Deferred-Delivery: Wed, 5 Nov 2014 02:10:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.177.243] 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/wzdHaU_rMRT2A6qbw41yO2vqp9Q Cc: "Andrzej.Duda@imag.fr" , "bier@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 05 Nov 2014 02:10:52 -0000 State in BIER (one bitmap per child) is so limited and controlled that a c= onstrained node that cannot do storing may be able to still do BIER. For su= ch devices, we could propose a new mode of operation for RPL that is BIER o= nly, for both unicast and multicast traffic. If the preferred parent tree is acceptable for downward traffic, the DAOs w= ould percolate up by ORing the bitmaps of the children and passing that to = the preferred parent. Decision to forward down to a child (or of a child to= process an incoming message) would be a simple AND of the bitmap in the pa= cket and that of the child, regardless of unicast or multicast. Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of IJsbrand Wijnands > (iwijnand) > Sent: mardi 4 novembre 2014 14:28 > To: Carsten Bormann > Cc: Andrzej.Duda@imag.fr; roll@ietf.org; bier@ietf.org; 6lo@ietf.org > Subject: Re: [Roll] [Bier] Source-Routed Multicast >=20 > Hi Carsten, >=20 > The ROLL case looks very interesting. >=20 > Just one clarification, BIER is not Source-Routed multicast. i.e. we don'= t include > a list of hops that the packet needs to follow, we only include final des= tination in > the form of Bit Positions, and each router along the path does a lookup o= n the > Bit Position to determine where the packet is to be sent. >=20 > Thx, >=20 > Ice. >=20 > On 03 Nov 2014, at 15:42, Carsten Bormann wrote: >=20 > > In Hawaii, there will be a BOF about a multicast forwarding control > > scheme where a router on the way prefixes a multicast packet with a > > special header that tells downtree routers where to forward the > > multicast - Bit Index Explicit Replication, or BIER. > > > > While BIER appears to be very focused on a carrier or datacenter > > perspective (see draft-kumar-bier-use-cases and the other > > draft-*-bier-*), there are applications in constrained node networks > > that would benefit from source-routed multicast. > > > > Several proposals on how to do source-routed multicast in constrained > > node networks are getting ready for consumption. > > > > With its current focus, I don't think the BIER BOF itself is the right > > place to have a technical discussion about this. > > There is no ROLL meeting in Hawaii. > > The 6lo agenda is almost full. > > Should we do this in a side meeting? (If we do this before Tuesday, > > we can at least report in 6lo - if we do it on Sunday, we might even > > have an opinion to air during the BIER BOF.) > > > > Gr=FC=DFe, Carsten > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Nov 6 00:08:38 2014 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 140981A1A87 for ; Thu, 6 Nov 2014 00:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.594] 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 fGxGhdrJf5oQ for ; Thu, 6 Nov 2014 00:08:29 -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 30B431A06FD for ; Thu, 6 Nov 2014 00:08:29 -0800 (PST) Received: from localhost ([::1]:57709 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XmI7E-0000Rb-VG; Thu, 06 Nov 2014 00:08:24 -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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 06 Nov 2014 08:08:24 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161#comment:5 Message-ID: <073.f367bbd8110f1c2b85a48743a514ad48@trac.tools.ietf.org> References: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/SGj27Js_mR-_EfcDZMF6qBa1RdA Cc: roll@ietf.org Subject: Re: [Roll] [roll] #161 (security-threats): AD review 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: Thu, 06 Nov 2014 08:08:34 -0000 #161: AD review Changes (by mariainesrobles@gmail.com): * status: assigned => closed * resolution: => fixed -- -----------------------------------+------------------------------- Reporter: mcr@sandelman.ca | Owner: mcr@sandelman.ca Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: security-threats | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------- Ticket URL: roll From nobody Sun Nov 9 16:54:14 2014 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 3F29B1A87C3; Sun, 9 Nov 2014 16:54:11 -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 I4rnxM9EhN80; Sun, 9 Nov 2014 16:54:09 -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 5D1DB1A87DB; Sun, 9 Nov 2014 16:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAA0rxXo014262; Mon, 10 Nov 2014 01:53:59 +0100 (CET) Received: from dhcp-a70a.meeting.ietf.org (dhcp-a70a.meeting.ietf.org [31.133.167.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F22FE5A0; Mon, 10 Nov 2014 01:53:57 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <300194F7-D81F-4F2B-923A-BA6EF09DC334@tzi.org> Date: Sun, 9 Nov 2014 14:53:55 -1000 X-Mao-Original-Outgoing-Id: 437273635.15999-27f0abddbb6e36fc2cfe153fa71223e2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <300194F7-D81F-4F2B-923A-BA6EF09DC334@tzi.org> To: IJsbrand Wijnands X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/n6ePSD8vX4woS2sawftxQK8ihrs Cc: Andrzej.Duda@imag.fr, roll@ietf.org, bier@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 10 Nov 2014 00:54:11 -0000 On 04 Nov 2014, at 12:50, Carsten Bormann wrote: >=20 > It seems several people would be able to make a Sunday hallway chat = about this general approach. Since I=92m officially at a couple of = meetings (in parallel) from 1600, how about 1500? I=92ll be near the registration desk around 15:00 (in 5 minutes). Use my photo at http://www.ietf.org/wg/chair-photos.html to find me. Gr=FC=DFe, Carsten From nobody Mon Nov 10 09:47:23 2014 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 ABF901A07BE; Mon, 10 Nov 2014 09:47:12 -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 A6o6uXtflM2R; Mon, 10 Nov 2014 09:47:11 -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 620881A0A6B; Mon, 10 Nov 2014 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAAHfbEY029065; Mon, 10 Nov 2014 18:41:37 +0100 (CET) Received: from [192.168.1.100] (dhcp-939e.meeting.ietf.org [31.133.147.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9ED60DAB; Mon, 10 Nov 2014 18:41:35 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 10 Nov 2014 07:41:32 -1000 X-Mao-Original-Outgoing-Id: 437334092.645113-d9cdd658dbe846e7d45b5a71c526c1e9 Content-Transfer-Encoding: quoted-printable Message-Id: <7D65A17E-75FF-4DD1-BF50-9AC7A7C03953@tzi.org> References: <300194F7-D81F-4F2B-923A-BA6EF09DC334@tzi.org> To: IJsbrand Wijnands X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/cVtPTzGjIKzbYUzpQy3AQ_E0Oqw Cc: Andrzej.Duda@imag.fr, roll@ietf.org, bier@ietf.org, 6lo@ietf.org Subject: Re: [Roll] [Bier] Source-Routed Multicast 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, 10 Nov 2014 17:47:13 -0000 With the I-D embargo lifted, I finally was able to post our I-D. Enjoy at: https://tools.ietf.org/html/draft-bergmann-bier-ccast If anybody wants me to talk about this at BIER, I also have slides. Gr=FC=DFe, Carsten From nobody Mon Nov 10 14:08:42 2014 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 C3D151A6EDC for ; Mon, 10 Nov 2014 14:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 zQyoocO15fEd for ; Mon, 10 Nov 2014 14:08:28 -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 B073B1A6FE8 for ; Mon, 10 Nov 2014 14:08:25 -0800 (PST) Received: from localhost ([::1]:46243 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xnx7r-000873-28; Mon, 10 Nov 2014 14:07:55 -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-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Mon, 10 Nov 2014 22:07:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/162 Message-ID: <071.552483167f70c2f1001ce26c2c4b6172@trac.tools.ietf.org> X-Trac-Ticket-ID: 162 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/WrPefz1CsHDqEiEnYic70d5eWVg Cc: roll@ietf.org Subject: [Roll] [roll] #162 (applicability-home-building): Use of basic RPL vs P2P RPL 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, 10 Nov 2014 22:08:34 -0000 #162: Use of basic RPL vs P2P RPL Yvonne-Anne Pignolet: In 2.2.7. the authors argue that P2P-RPL is required for P2P and P2MP traffic in home and building automation LLNs instead of basic RPL. I fully agree that P2P-RPL is used for P2P traffic, but for P2MP traffic it often makes sense to use basic RPL, also in home and building automation LLNs. I suggest to include both P2P-RPL and basic RPL in the recommended protocol portfolio for home and building automation for P2P and P2MP traffic. 2014-11-04 11:46 GMT+02:00 peter van der Stok: I think we did in section 2.2.7 first phrase, where we mention that RPL is useful in the context of the SS paradigm where multiple servers send data to a central client which may be situated on a backbone. We reserve P2P-RPL specifically for P2P and P2MP traffic. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: minor | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Nov 10 14:09:55 2014 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 5D0991A7032 for ; Mon, 10 Nov 2014 14:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 P8SQIIZRfBaI for ; Mon, 10 Nov 2014 14:09:48 -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 4C69A1A702B for ; Mon, 10 Nov 2014 14:09:48 -0800 (PST) Received: from localhost ([::1]:46280 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xnx9a-0008Kc-HL; Mon, 10 Nov 2014 14:09:42 -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-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Mon, 10 Nov 2014 22:09:42 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/163 Message-ID: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> X-Trac-Ticket-ID: 163 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/GSTWHrnk4UWCRTuFCz_jkmK4aCs Cc: roll@ietf.org Subject: [Roll] [roll] #163 (applicability-home-building): DAO Policy 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, 10 Nov 2014 22:09:52 -0000 #163: DAO Policy Yvonne-Anne Pignolet: In 4.1.3. The authors consider DAO policy to be out of scope. However, if basic RPL is applicable for home and building automation scenarios then due to P2MP traffic from roots DAOs are required. As in the industrial applicability statement I thus recommend a paragraph such as "Nodes send DAO messages to establish downward paths from the root to themselves. DAO messages are not acknowledged in networks composed of battery operated field devices in order to minimize the power consumption overhead associated with path discovery. If devices in LLNs participate in multiple RPL instances and DODAGs, it is highly recommended that both the RPLInstance ID and the DODAGID be included in the DAO." If the mailing list consensus is that P2P RPL is to be used only, then this Section should state that DAO messages are not sent in this case. In addition a comment on P2P-DRO Acknowledgement (P2P-DRO-ACK) would be helpful Peter van der Stok: Some text to motivate the out of scope of DAO policy can be added. For the multiple RPL instances, I prefer to include a reference to other texts. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: minor | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Nov 10 14:10:48 2014 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 7F0641A8033 for ; Mon, 10 Nov 2014 14:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 xaw7EL-RIVZj for ; Mon, 10 Nov 2014 14:10:45 -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 441081A7035 for ; Mon, 10 Nov 2014 14:10:45 -0800 (PST) Received: from localhost ([::1]:46348 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XnxAT-0000Gp-J4; Mon, 10 Nov 2014 14:10:37 -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-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Mon, 10 Nov 2014 22:10:37 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/164 Message-ID: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/MpFt2T5OP06__o9rahdo8wzBoTM Cc: roll@ietf.org Subject: [Roll] [roll] #164 (applicability-home-building): Recommended Metric 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, 10 Nov 2014 22:10:46 -0000 #164: Recommended Metric Please correct 4.1.4. OF0 is not a metric. Did you mean ETX or HC? Or another metric from http://tools.ietf.org/html/rfc6551#section-6.1 ? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: major | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Nov 10 14:12:35 2014 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 3FC251A70E2 for ; Mon, 10 Nov 2014 14:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 CHlwPVetgnf4 for ; Mon, 10 Nov 2014 14:12:31 -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 C89551A6F2E for ; Mon, 10 Nov 2014 14:12:31 -0800 (PST) Received: from localhost ([::1]:46394 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XnxCD-0000Xn-Q0; Mon, 10 Nov 2014 14:12:25 -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-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Mon, 10 Nov 2014 22:12:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/165 Message-ID: <071.ea7747ad3029e024bad1f4db878636b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 165 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZK8ycNylGfoZGfh-xnOj-M2FH8A Cc: roll@ietf.org Subject: [Roll] [roll] #165 (applicability-home-building): DIO max interval 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, 10 Nov 2014 22:12:33 -0000 #165: DIO max interval Yvonne-Anne Pignolet: Please state why a value of DIO max interval of 4.37min (16ms x 2^14) is appropriate, it seems like a much smaller value would be suitable for this usecase Peter van der Stok: I don't understand the issue here. When something happens the 16 ms come into play. Assuming a limited number of hops, the change propagates quite timely. When nothing happens, sending a reminder every 4 minutes seems quite reasonable. (we are discussing propagation of network changes, not user commands) Yvonne-Anne Pignolet: Until it is noticed that some happened a long time may pass because of the low DIO frequencey -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: minor | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Nov 10 14:14:49 2014 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 772CA1A870F for ; Mon, 10 Nov 2014 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 VDcLOoqIH2HE for ; Mon, 10 Nov 2014 14:14:46 -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 33A521A8706 for ; Mon, 10 Nov 2014 14:14:46 -0800 (PST) Received: from localhost ([::1]:46468 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XnxEN-0001zf-ME; Mon, 10 Nov 2014 14:14:39 -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-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Mon, 10 Nov 2014 22:14:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/166 Message-ID: <071.7295354c7dfda72357e3f748cc1630f6@trac.tools.ietf.org> X-Trac-Ticket-ID: 166 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Zna5ZM06sPtsBRPkbGu00_x6zrQ Cc: roll@ietf.org Subject: [Roll] [roll] #166 (applicability-home-building): Manageability 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, 10 Nov 2014 22:14:47 -0000 #166: Manageability Yvonne-Anne Pignolet: About Section 6, why would manageability be out of scope for home network scenarios? And can you give more detail on what central control based on MIBs entails? Peter van der Stok: I think the whole discussion on how home networks are managed is still on going. And what to manage is also not clear. For example: will the ISP set the RPL parameter values in the nodes in my home and acquire statistics on packet fragmentation? In building automation, setting configuration parameters seems necessary (for example the MPL parameter values). Some people think this should be done via DHCP. So removing the last phrase of section 6 will improve the clarity. Yvonne-Anne Pignolet: In this case it would be good to mention that home network management is still under discussion. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: trivial | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Nov 10 14:44:11 2014 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 E885A1ACF19; Mon, 10 Nov 2014 14:44:08 -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 K4K_nANvb8iJ; Mon, 10 Nov 2014 14:44:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF31ACF60; Mon, 10 Nov 2014 14:44:06 -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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110224406.21420.60015.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 14:44:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/vQ5bZkAvmjQ-6i_7T0jj9vqDabo Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-06.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, 10 Nov 2014 22:44:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : ROLL Applicability Statement Template Author : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-06.txt Pages : 9 Date : 2014-11-10 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-template-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-template-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 10 15:36:40 2014 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 E51BA1A8751; Mon, 10 Nov 2014 15:36:35 -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 qYrcKKpleNuZ; Mon, 10 Nov 2014 15:36:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAE01AD025; Mon, 10 Nov 2014 15:36:31 -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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110233631.17640.19258.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 15:36:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/cZM9fBykqbShqxp9HS9-3Nak_Cc Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-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: Mon, 10 Nov 2014 23:36:36 -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 : Multicast Protocol for Low power and Lossy Networks (MPL) Authors : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-10.txt Pages : 25 Date : 2014-11-10 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-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 Thu Nov 13 12:59:08 2014 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 70BD51AD4A7 for ; Thu, 13 Nov 2014 12:59:00 -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 PDR9vA6J7oKb for ; Thu, 13 Nov 2014 12:58:57 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4B91AD4BB for ; Thu, 13 Nov 2014 12:58:57 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.209]) by smtp-cloud2.xs4all.net with ESMTP id F8yu1p00D4WfiVN018yuin; Thu, 13 Nov 2014 21:58:55 +0100 Received: from t2001067c03700160cd4543bfe771a8c0.wireless.v6.meeting.ietf.org ([2001:67c:370:160:cd45:43bf:e771:a8c0]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 13 Nov 2014 21:58:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Nov 2014 21:58:54 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <071.7295354c7dfda72357e3f748cc1630f6@trac.tools.ietf.org> References: <071.7295354c7dfda72357e3f748cc1630f6@trac.tools.ietf.org> Message-ID: <54fb35c457ba6032008e7c13a0b3e2df@xs4all.nl> X-Sender: stokcons@xs4all.nl (k2UtsJ5jFgguVHHQSCrf+JLjTN6SveGI) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YnVV9OGpjLLykPDFqNVI5C1zgbg Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com Subject: Re: [Roll] [roll] #166 (applicability-home-building): Manageability 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: Thu, 13 Nov 2014 20:59:02 -0000 HI Yvonne, we propose the following text for section 6. At this moment it is not clear how homenets will be managed. Consequently it is not clear which tools will be used and which parameters must be exposed for management. In building control, management is mandatory. It is expected that installations will be managed using the set of currently available tools (including IETF tools like MIBS, NETCONF modules, DHCP and others) with large differences between the ways an installation is managed. Greetings, Peter roll issue tracker schreef op 2014-11-10 23:14: > #166: Manageability > > Yvonne-Anne Pignolet: > About Section 6, why would manageability be out of scope for home > network scenarios? And can you give more detail on what central > control based on MIBs entails? > > Peter van der Stok: > I think the whole discussion on how home networks are managed is still > on > going. > And what to manage is also not clear. For example: will the ISP set > the > RPL parameter values in the nodes in my home and acquire statistics on > packet fragmentation? > > In building automation, setting configuration parameters seems > necessary > (for example the MPL parameter values). Some people think this should > be > done via DHCP. So removing the last phrase of section 6 will improve > the > clarity. > > Yvonne-Anne Pignolet: > In this case it would be good to mention that home network management > is > still under discussion. From nobody Thu Nov 13 15:32:22 2014 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 317AB1AE2BE for ; Thu, 13 Nov 2014 15:32:22 -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 9-uYkt1VLlhB for ; Thu, 13 Nov 2014 15:32:20 -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 7D4BA1AE2C0 for ; Thu, 13 Nov 2014 15:32:20 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id FBYJ1p0024K0fSy01BYJX1; Fri, 14 Nov 2014 00:32:18 +0100 Received: from t2001067c037001601499c2af8272b823.wireless.v6.meeting.ietf.org ([2001:67c:370:160:1499:c2af:8272:b823]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Nov 2014 00:32:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Nov 2014 00:32:18 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <071.552483167f70c2f1001ce26c2c4b6172@trac.tools.ietf.org> References: <071.552483167f70c2f1001ce26c2c4b6172@trac.tools.ietf.org> Message-ID: <7ebbf75794b437f21837aac3dceed489@xs4all.nl> X-Sender: stokcons@xs4all.nl (Pbx2aW8a4WMu2juUIjLs1gwSNYBKnC7Z) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xnATq0RCd_fAndvgcegeBP_qApA Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com Subject: Re: [Roll] [roll] #162 (applicability-home-building): Use of basic RPL vs P2P RPL 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: Thu, 13 Nov 2014 23:32:22 -0000 Hi Yvonne, We propose to leave the text unchanged. In section 2.2.7 it is written that RPL is recommended for SS traffic. Peter roll issue tracker schreef op 2014-11-10 23:07: > #162: Use of basic RPL vs P2P RPL > > Yvonne-Anne Pignolet: > In 2.2.7. the authors argue that P2P-RPL is required for P2P and P2MP > traffic in home and building automation LLNs instead of basic RPL. > I fully agree that P2P-RPL is used for P2P traffic, but for P2MP > traffic > it often makes sense to use basic RPL, also in home and building > automation LLNs. I suggest to include both P2P-RPL and basic RPL in > the > recommended protocol portfolio for home and building automation for > P2P > and P2MP traffic. > > 2014-11-04 11:46 GMT+02:00 peter van der Stok: > I think we did in section 2.2.7 first phrase, where we mention that > RPL is > useful in the context of the SS paradigm where multiple servers send > data > to a central client which may be situated on a backbone. > We reserve P2P-RPL specifically for P2P and P2MP traffic. From nobody Thu Nov 13 15:46:01 2014 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 E406D1AE2F6 for ; Thu, 13 Nov 2014 15:45:59 -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 coum4_s1cBeJ for ; Thu, 13 Nov 2014 15:45:58 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20891AE314 for ; Thu, 13 Nov 2014 15:45:57 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id FBlv1p0064K0fSy01BlvEf; Fri, 14 Nov 2014 00:45:55 +0100 Received: from t2001067c037001601499c2af8272b823.wireless.v6.meeting.ietf.org ([2001:67c:370:160:1499:c2af:8272:b823]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Nov 2014 00:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Nov 2014 00:45:55 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> References: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> Message-ID: <447dc404214f4a5dcb730e62f7dab2a2@xs4all.nl> X-Sender: stokcons@xs4all.nl (CMStAzdvBD1YFgGMsKDyKu5GL2gieyaZ) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/8iZcP3CkpiNlfswi8mMmNunlnY8 Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com Subject: Re: [Roll] [roll] #164 (applicability-home-building): Recommended Metric 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: Thu, 13 Nov 2014 23:46:00 -0000 Hi Yvonne, This is a mistake of ours. We will write that ETX is recommended Peter roll issue tracker schreef op 2014-11-10 23:10: > #164: Recommended Metric > > Please correct 4.1.4. OF0 is not a metric. Did you mean ETX or HC? > Or another metric from http://tools.ietf.org/html/rfc6551#section-6.1 > ? From nobody Thu Nov 13 16:01:50 2014 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 980DF1AE37C for ; Thu, 13 Nov 2014 16:01:47 -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 VBnZEMsG7caP for ; Thu, 13 Nov 2014 16:01:45 -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 67B981AE380 for ; Thu, 13 Nov 2014 16:01:39 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id FC1d1p00D4Hiz6i01C1dCe; Fri, 14 Nov 2014 01:01:37 +0100 Received: from t2001067c03700160f829bdf226b269cc.wireless.v6.meeting.ietf.org ([2001:67c:370:160:f829:bdf2:26b2:69cc]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Nov 2014 01:01:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Nov 2014 01:01:37 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <071.ea7747ad3029e024bad1f4db878636b6@trac.tools.ietf.org> References: <071.ea7747ad3029e024bad1f4db878636b6@trac.tools.ietf.org> Message-ID: <79f2fea030c8caebe34829ea68104a37@xs4all.nl> X-Sender: stokcons@xs4all.nl (krs3n0iB2ll3S+DEhAeNojffzHWL2JHw) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fnfmRhbZT-AGHmSEUYZ45sl36po Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com Subject: Re: [Roll] [roll] #165 (applicability-home-building): DIO max interval 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: Fri, 14 Nov 2014 00:01:47 -0000 Hi Yvonne, In RFC 6206 (trickle), the introduction explains: "When a node's data does not agree with its neighbors, that node communicates quickly to resolve the inconsistency (e.g., in milliseconds). When nodes agree, they slow their communication rate exponentially, such that nodes send packets very infrequently (e.g., a few packets per hour)." We propose to add the following text to section 4.3.1. When a node sends a changed DIO, this is an inconsistency and forces the receiving node to respond within Imin. So when something happens which affects the DIO, the change is ideally communicated to a node n hops away within n times Imin. Often, dependent on the node density, packets are lost, or not sent, leading to larger delays. In general we can expect that DIO changes to propagate within 1 to 3 seconds within the envisaged networks. When nothing happens, the DIO sending interval increases to 4.37 minutes, thus drastically reducing the network load. When a node does not receive DIO messages during more than 10 minutes it can safely conclude the connection with other nodes has been lost. Peter roll issue tracker schreef op 2014-11-10 23:12: > #165: DIO max interval > > Yvonne-Anne Pignolet: > Please state why a value of DIO max interval of 4.37min (16ms x > 2^14) is appropriate, it seems like a much smaller value would be > suitable for this usecase > > Peter van der Stok: > I don't understand the issue here. When something happens the 16 ms > come > into play. Assuming a limited number of hops, the change propagates > quite > timely. > When nothing happens, sending a reminder every 4 minutes seems quite > reasonable. (we are discussing propagation of network changes, not > user > commands) > > Yvonne-Anne Pignolet: > Until it is noticed that some happened a long time may pass because of > the > low DIO frequencey From nobody Thu Nov 13 16:19:04 2014 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 B8FD71A0072 for ; Thu, 13 Nov 2014 16:19:01 -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 131vDw10kVsT for ; Thu, 13 Nov 2014 16:19:00 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D161A006F for ; Thu, 13 Nov 2014 16:18:59 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id FCJy1p00L4Hiz6i01CJyBP; Fri, 14 Nov 2014 01:18:58 +0100 Received: from t2001067c03700160f829bdf226b269cc.wireless.v6.meeting.ietf.org ([2001:67c:370:160:f829:bdf2:26b2:69cc]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Nov 2014 01:18:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Nov 2014 01:18:58 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> References: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> Message-ID: <800e9c000d3ee95159be615efb6b4b13@xs4all.nl> X-Sender: stokcons@xs4all.nl (oVATWIulgzoRte3CPCRoQ0QuqpamtKLV) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/52P-ACPtHEndI_4IM1NDT6OPvC8 Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com Subject: Re: [Roll] [roll] #163 (applicability-home-building): DAO Policy 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: Fri, 14 Nov 2014 00:19:01 -0000 HI Yvonne, after some discussions we propose the following text, that you will easily recognize. Nodes send DAO messages to establish downward paths from the root to themselves. DAO messages are not acknowledged in networks composed of battery operated field devices in order to minimize the power consumption overhead associated with path discovery. The DAO messages build up a source route because the nodes are recommended to be in non-storing mode. If devices in LLNs participate in multiple RPL instances and DODAGs, it is highly recommended that both the RPLInstance ID and the DODAGID be included in the DAO. many thanks, Peter roll issue tracker schreef op 2014-11-10 23:09: > #163: DAO Policy > > Yvonne-Anne Pignolet: > In 4.1.3. The authors consider DAO policy to be > out of scope. However, if basic RPL is applicable for home and > building automation scenarios then due to P2MP traffic from roots > DAOs are required. As in the industrial applicability statement I thus > recommend a paragraph such as "Nodes send DAO messages to establish > downward paths from the root to themselves. DAO messages are not > acknowledged in networks composed of battery operated field devices in > order to minimize the power consumption overhead associated with path > discovery. If devices in LLNs participate in multiple RPL instances > and DODAGs, it is highly recommended that both the RPLInstance ID and > the DODAGID be included in the DAO." If the mailing list consensus is > that P2P RPL is to be used only, then this Section should state that > DAO messages are not sent in this case. In addition a comment on > P2P-DRO Acknowledgement (P2P-DRO-ACK) would be helpful > > Peter van der Stok: > Some text to motivate the out of scope of DAO policy can be added. > For the multiple RPL instances, I prefer to include a reference to > other > texts. From nobody Fri Nov 14 07:46:55 2014 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 873B81A1A28; Fri, 14 Nov 2014 07:46:52 -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 i6JQUisgoJtm; Fri, 14 Nov 2014 07:46:49 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (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 079AF1A1A04; Fri, 14 Nov 2014 07:46:49 -0800 (PST) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XpJ5D-0008R5-JH; Fri, 14 Nov 2014 15:46:47 +0000 Received: from lb1.hi.local ([10.0.1.197] 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 1XpJ5A-0007ew-Gk; Fri, 14 Nov 2014 15:46:47 +0000 Received: from host31-51-175-12.range31-51.btcentralplus.com ([31.51.175.12] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XpJ58-0008M9-Iq; Fri, 14 Nov 2014 15:46:43 +0000 Message-ID: <546623D2.4060207@gridmerge.com> Date: Fri, 14 Nov 2014 15:46:26 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090608090201060205060300" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5bIrbAKwvAI4OyTW2yGFzu2xooc Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt 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: Fri, 14 Nov 2014 15:46:52 -0000 This is a cryptographically signed message in MIME format. --------------ms090608090201060205060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pascal, First of all, thanks to all the contributors to this work in producing=20 this draft expediently. My opinions on the approaches: _Greedy_ Unacceptable to grab such a large portion of the NHC space. It sets the=20 wrong precedent and limits future enhancements. _Conservative_ This is the most consistent with RFC6282 and current processing in that=20 it add the occurrence of a single NHC type to indicate the presence of=20 RPI_NHC compressed header. The one downside is that it uses one of the=20 two remaining options in the standard NHC encoding. So whilst this only=20 grabs 1/256 of the space, it only leaves one further possible use.=20 Furthermore, RPI_NHC is not actually an IPv6 Extension Header, it simply = represents an option in a Hop-by-Hop Options header. The compression=20 applied to RPI_NHC highly specific unlike the general compression=20 applied to an IPv6 Extension Header and therefore the RPI_NHC would=20 require a specific case in NHC compression and decompression. One possible alternative to consider might be to allocate a new type of=20 NHC; let's call it Specific LOWPAN_NHC: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 0 | 1 | EID |NH | +---+---+---+---+---+---+---+---+ EID: Specifically compressed header ID: 0: Compressed RPL Option (RPI_NHC) [RFCthis] This could go into RFC6282 as such with the text that the defining RFC=20 MUST explain the compression and decompression mechanism. The obvious disadvantage is that it takes a larger portion of the NHC=20 space (1/32) but it makes actual NHC processing more straightforward. _Efficient_ It is clear that in normal cases, it is as efficient as the greedy=20 approach. Whilst the RPI_NHC option occupies 1/4 of the space of the=20 greedy option (i.e. 1/16, which is still quite a bit), the escape option = occupies another 1/64 of the space. However, occurrence of the escape=20 code complicates processing. Moreover (and I know this has been=20 discussed before), the length of the overall compressed option can=20 change from hop to hop, which it won't do in the case where the normal=20 Hop-by-Hop Options header is used. Question - any reason the value 010001XY was chosen for the escape code? _Conclusion_ Firstly, greedy is out for me - it grabs too much space. If the overriding requirement is to save as many bytes as possible, the=20 efficient approach would be the best choice. It is not clear to me=20 whether the possible length changing has any implications but it could=20 clearly cause fragmentation, which seems undesirable, especially if=20 mechanisms to forward indivdual fragments are being considered. I think the cost of having one byte for the extra NHC is not a huge cost = and provides consistent packet sizing therefore I favour the=20 conservative approach. I would also possibly consider the remarks made=20 regarding the different type of subsequent header. Robert On 25/10/2014 8:35 AM, Pascal Thubert (pthubert) wrote: > Dear all: > > We have converged for most of the design of the 6lo compression for the= RPL packet information and republished. > A major question is left on the table for the working group, and isolat= ed in section 4.3, with 3 approaches proposed. > > 4.3. The RPI_NHC encoding . . . . . . . . . . . . . . . . . . = 5 > 4.3.1. The Greedy Approach . . . . . . . . . . . . . . . . . = 7 > 4.3.2. The Conservative Approach . . . . . . . . . . . . . . = 7 > 4.3.3. The Efficient Approach . . . . . . . . . . . . . . . = 8 > > Your review prior to the IETF meeting will be appreciated more than eve= r. > At the 6lo meeting, we expect to have a slot and obtain a rough consens= us of the room on that particular question. > We will also call for adoption. > > Finally, there seems to be a will to propose a compression for the Rout= ing Header as uses in RPL non-storing mode, and hopefully we will see pro= posals soon. > > Cheers, > > Pascal > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: samedi 25 octobre 2014 09:06 > To: Carsten Bormann; Dr. Carsten Bormann; Pascal Thubert (pthubert); Pa= scal Thubert (pthubert) > Subject: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt > > > A new version of I-D, draft-thubert-6lo-rpl-nhc-02.txt has been success= fully submitted by Pascal Thubert and posted to the IETF repository. > > Name: draft-thubert-6lo-rpl-nhc > Revision: 02 > Title: A compression mechanism for the RPL option > Document date: 2014-10-24 > Group: Individual Submission > Pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-r= pl-nhc-02.txt > Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-rpl-= nhc/ > Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc-02= > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-rp= l-nhc-02 > > Abstract: > This specification defines the RPL Packet Information (RPI) NHC > compression, a method to compress RPL Option (RFC6553) information > within 6LoWPAN-style ("6lo") adaptation layers. This extends 6LoWP= AN > Header Compression (RFC6282), saving up to 48 bits in each frame > compared to the uncompressed form in RFC 6553. > > = =20 > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org= =2E > > The IETF Secretariat > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------ms090608090201060205060300 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 Fw0xNDExMTQxNTQ2MjZaMCMGCSqGSIb3DQEJBDEWBBTIXAjQXr/aEKc5gzG9BTSNNyvukTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBkKXoBYY6Sg23wk68v39WfI3MXRJOiWHfy txlCh64PVykQsxV7qYfkHjOUf5l59Hnd+nugCFlFI6P1qzV29+dT0jIv5WykDIvDvdQ1pmaI +WrSuRvm4bGgFH3NcRtsZdpNuKxJkTQ5UN3b9B5GqHlCUFAk0U5r1kYjasd8xPujUJLSjS29 Y7WUMIe2rzldK8jAqVa7k+4XobuCzceZTa81WF8eDygp5R7MOSMQVCO3HxmX3fwui8S1a6Rz oTMuIm0UIV3JyskQZqebfN4Yz5SP0xDVcAkthp0fSavDa+N5FIlgwsJOeq92LH/dEgf2H3QX uNZqFUM4TgGzrP4c3AQPAAAAAAAA --------------ms090608090201060205060300-- From nobody Fri Nov 14 08:06:05 2014 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 876891A1A88; Fri, 14 Nov 2014 08:05:55 -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 bGsKEGz5GYd9; Fri, 14 Nov 2014 08:05:54 -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 C90A81A1A76; Fri, 14 Nov 2014 08:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAEG5SDX017737; Fri, 14 Nov 2014 17:05:28 +0100 (CET) Received: from dhcp-93f4.meeting.ietf.org (dhcp-93f4.meeting.ietf.org [31.133.147.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0353131D; Fri, 14 Nov 2014 17:05:26 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <546623D2.4060207@gridmerge.com> Date: Fri, 14 Nov 2014 06:05:23 -1000 X-Mao-Original-Outgoing-Id: 437673923.378725-851c10d7f5a88d5417173bfc256e53ff Content-Transfer-Encoding: quoted-printable Message-Id: <26D6758E-C9EA-4DB4-AD80-8B865A7E1962@tzi.org> References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> <546623D2.4060207@gridmerge.com> To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ux51ApCWk1PtLRDO19ISvOjVkmw Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-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: Fri, 14 Nov 2014 16:05:55 -0000 On 14 Nov 2014, at 05:46, Robert Cragie = wrote: >=20 > Question - any reason the value 010001XY was chosen for the escape = code? Note that the escape space is not taken just for RFC 6553 compression; = it can be used for encoding other NHCs as well. The idea was to reserve some space around that so if we want to extend = the escape space for some future NHC, we can do so while keeping it = contiguous. Note also that RFC 6282 already has variable length processing for hop = limit and address compression, so the impact of adding a third instance = is going to be limited. (I need to write that up some more in = draft-*-lwig-6lo.) Since just about every data packet in a RPL network will carry an RPI, = saving a single byte is worth quite some effort. Gr=FC=DFe, Carsten From nobody Fri Nov 14 22:16:55 2014 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 E4DF11A1A55 for ; Fri, 14 Nov 2014 22:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.494 X-Spam-Level: X-Spam-Status: No, score=-14.494 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, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 r7uHzi-6BpOl for ; Fri, 14 Nov 2014 22:16:50 -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 CAC871A1A2C for ; Fri, 14 Nov 2014 22:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8979; q=dns/txt; s=iport; t=1416032209; x=1417241809; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=p+eVB9j9kv10WS7rDTO4CofTIN27t9ILSRRgNDdVO/g=; b=MX3YnU+gKfGiSTMvMrymvWS2WqtVcr2qRD05IVpK28En7ewZ1ELxpNYf N0IklEzY0bK8p080XnfyUezVbfyKVQBSOgK80VuLo7ltbyKpn7UrDP02N uFFLPhfFg+3grzr0KFoyzSax9r241dfpDVoibq6XHOX6P8UxHUu5uhoH6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAC/vZlStJV2U/2dsb2JhbABbgw5VWYI+SMl3AQmHTgIcehYBAQEBAX2EAwEBBAEBAQkXSxsCAQYWKwMCAgIfBgsUBwoCBBOILAMSDZ4bnHGPQA2GWgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjmSCIwoNCgGCdzaBHgWGQIwHiXKCE5AFhnWDfG0BgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208,217";a="369307006" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2014 06:16:49 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAF6GmIG015674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Nov 2014 06:16:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 00:16:48 -0600 From: "Pascal Thubert (pthubert)" To: ROLL WG Thread-Topic: draft-previdi-6man-segment-routing-header Thread-Index: AQHQAFbVfdYglDMLE0GUchpU6eOffZxhScYA///tBo0= Date: Sat, 15 Nov 2014 06:16:48 +0000 Message-ID: References: <54667C2C.6000509@gmail.com>,<5466AB5C.9070806@acm.org> In-Reply-To: <5466AB5C.9070806@acm.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B250E09C99CF45B59997942DD81A7692ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/sAsqBrSiF7g0quAQEFId5ldZ_fc Subject: [Roll] Fwd: draft-previdi-6man-segment-routing-header 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: Sat, 15 Nov 2014 06:16:53 -0000 --_000_B250E09C99CF45B59997942DD81A7692ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBhbHNvIHJlbGF0ZXMgdG8gb3VyIGRpc2N1c3Npb24gb24gd2hldGhlciBhIFJIIG9yIGEg UlBMIG9wdGlvbiBjYW4gYmUgaW5zZXJ0ZWQgb3IgY2F1c2UgYW4gZXh0cmEgIElQaW5JUCBlbmNh cHN1bGF0aW9uLiBDZXJ0YWlubHkgdGhlIHJ1bGUgaXMgdG8gZW5jYXBzdWxhdGUuDQoNClRoaXMg aXMgd2hlcmUgdGhlIEZsb3cgTGFiZWwgdGVjaG5pcXVlIHdhcyBvZiBwYXJ0aWN1bGFyIGludGVy ZXN0Lg0KDQpOb3cgaWYgd2UgY291bGQgZ28gYWxvbmcgdGhlIHBhdGggb2YgYSByb3V0aW5nIGRp c3BhdGNoIHdoZXJlIGFsbCB0aGUgTExOIHJvdXRpbmcgYXJ0aWZhY3RzIGFyZSBzdG9yZWQgcHJp b3IgdG8gdGhlIGNvbXByZXNzZWQgcGFja2V0IHdlIGNvdWxkIHByb2JhYmx5IG1ha2UgdGhpbmdz IGlubm9jdW91cy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRMOpYnV0IGR1IG1lc3NhZ2UgdHJh bnNmw6lyw6kgOg0KDQpFeHDDqWRpdGV1cjogRXJpayBOb3JkbWFyayA8bm9yZG1hcmtAYWNtLm9y ZzxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4+DQpEYXRlOiAxNCBub3ZlbWJyZSAyMDE0IDE1OjI0 OjQ0IFVUQ+KIkjEwDQpEZXN0aW5hdGFpcmU6IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+LCA2 bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj4NCk9iamV0OiBSw6lwIDog ZHJhZnQtcHJldmlkaS02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXINCg0KT24gMTEvMTQvMTQg MTI6MDMgUE0sIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KSGksDQoNCjEuIEkgc2ltcGx5IGRv bid0IHVuZGVyc3RhbmQgb25lIGFzcGVjdCBvZiB0aGlzIHByb3Bvc2FsLiBXaGVuZXZlciBJIGhh dmUNCmxvb2tlZCBmb3IgaXQgaW4gUkZDIDI2NDAsIEkgaGF2ZSBmYWlsZWQgdG8gZmluZCBhbnl0 aGluZyB0aGF0IGFsbG93cw0KZXh0ZW5zaW9uIGhlYWRlcnMgdG8gYmUgaW5zZXJ0ZWQgaW4gcGFj a2V0cyBlbiByb3V0ZS4gQnV0IHRoaXMgZHJhZnQNCnNlZW1zIHRvIHJlcXVpcmUgYW4gaW5ncmVz cyByb3V0ZXIgdG8gaW5zZXJ0IGEgaGVhZGVyIGFuZCBhbiBlZ3Jlc3MNCnJvdXRlciB0byByZW1v dmUgaXQuIElzIHRoYXQgZXZlbiBhbGxvd2VkPyBBbmQgYXJlIHdlIHN1cmUgaXQgaGFzIG5vDQp1 bmludGVuZGVkIHNpZGUgZWZmZWN0cz8NCg0KRG9lc24ndCB3b3JrIC0gYnJlYWtzIFBNVFVEICh0 aGUgb3JpZ2luIHJlY2VpdmVzIGEgUFRCIHdoaWNoIHNheXMgTVRVPVggYnV0IHNlbmRpbmcgcGFj a2V0cyBvZiBsZW5ndGggWCBzdGlsbCBmYWlscyBkdWUgdG8gdGhlIGFkZGVkIGhlYWRlcnMpLiBU aGlzIHNob3VsZCBiZSBpbiB0aGUgIklQIHByb3RvY29sIEZBUSIgLSBJIGNhbid0IHJlbWVtYmVy IGhvdyBtYW55IHRpbWVzIFN0ZXZlIERlZXJpbmcgaGFkIHRvIGNvcnJlY3QgdGhpcy4NCg0KSVB2 NiBleHRlbnNpb24gaGVhZGVycyBjYW4gb25seSBiZSBhZGRlZCB0b2dldGhlciB3aXRoIGFuIG91 dGVyIElQdjYgaGVhZGVyLiBUaGF0IGVuc3VyZSB0aGF0IGFueSBJQ01QIGVycm9ycyBhcmUgc2Vu dCB0byB0aGUgZW5jYXBzdWxhdG9ycywgdGhhdCBjYW4gcmVnZW5lcmF0ZSBhIElDTVAgZXJyb3Ig d2hpY2ggd2lsbCBoYXZlIHRoZSBjb3JyZWN0IE1UVSB2YWx1ZSBmb3IgdGhlIG9yaWdpbmFsIHNl bmRlci4NCg0KICBFcmlrDQoNCg0KMi4gVGhlcmUgaXMgbm8gbWVudGlvbiBvZiBNVFUgc2l6ZSBv ciBmcmFnbWVudGF0aW9uLiBXaGF0IGhhcHBlbnMgaWYNCnRoZSB1c2VyIHBhY2tldCBwbHVzIHRo ZSBhZGRlZCBoZWFkZXIgZXhjZWVkcyB0aGUgbmV0d29yaydzIE1UVT8NCg0KMy4gSSB0aGluayB0 aGlzIG1vZGVsIGlzIGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byB0aGUgcHJvYmxlbSBwcmVzZW50 ZWQNCmJ5IEJlaGNldCBpbiBkcmFmdC1zYXJpa2F5YS02bWFuLXNhZHItb3ZlcnZpZXcuDQoNCiAg ICAgQnJpYW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo= --_000_B250E09C99CF45B59997942DD81A7692ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlRoaXMgYWxzbyByZWxhdGVzIHRvIG91ciBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgYSBSSCBv ciBhIFJQTCBvcHRpb24gY2FuIGJlIGluc2VydGVkIG9yIGNhdXNlIGFuIGV4dHJhICZuYnNwO0lQ aW5JUCBlbmNhcHN1bGF0aW9uLiBDZXJ0YWlubHkgdGhlIHJ1bGUgaXMgdG8gZW5jYXBzdWxhdGUu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIHdoZXJlIHRoZSBGbG93IExh YmVsIHRlY2huaXF1ZSB3YXMgb2YgcGFydGljdWxhciBpbnRlcmVzdC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pk5vdyBpZiB3ZSBjb3VsZCBnbyBhbG9uZyB0aGUgcGF0aCBvZiBhIHJv dXRpbmcgZGlzcGF0Y2ggd2hlcmUgYWxsIHRoZSBMTE4gcm91dGluZyBhcnRpZmFjdHMgYXJlIHN0 b3JlZCBwcmlvciB0byB0aGUgY29tcHJlc3NlZCBwYWNrZXQgd2UgY291bGQgcHJvYmFibHkgbWFr ZSB0aGluZ3MgaW5ub2N1b3VzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJz LDxicj4NCjxicj4NClBhc2NhbDwvZGl2Pg0KPGRpdj48YnI+DQpEw6lidXQgZHUgbWVzc2FnZSB0 cmFuc2bDqXLDqSZuYnNwOzo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdj48Yj5FeHDDqWRpdGV1cjo8L2I+IEVyaWsgTm9yZG1hcmsgJmx0OzxhIGhyZWY9 Im1haWx0bzpub3JkbWFya0BhY20ub3JnIj5ub3JkbWFya0BhY20ub3JnPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOjwvYj4gMTQgbm92ZW1icmUgMjAxNCAxNToyNDo0NCBVVEPiiJIxMDxicj4NCjxiPkRl c3RpbmF0YWlyZTo8L2I+IEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+ Jmd0OywgNm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPk9iamV0OjwvYj4gPGI+UsOpcCZuYnNwOzogZHJhZnQtcHJldmlk aS02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXI8L2I+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+T24gMTEvMTQv MTQgMTI6MDMgUE0sIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOjwvc3Bhbj48YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5IaSw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjEuIEkgc2ltcGx5IGRvbid0IHVuZGVyc3RhbmQg b25lIGFzcGVjdCBvZiB0aGlzIHByb3Bvc2FsLiBXaGVuZXZlciBJIGhhdmU8L3NwYW4+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+bG9va2VkIGZvciBp dCBpbiBSRkMgMjY0MCwgSSBoYXZlIGZhaWxlZCB0byBmaW5kIGFueXRoaW5nIHRoYXQgYWxsb3dz PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu PmV4dGVuc2lvbiBoZWFkZXJzIHRvIGJlIGluc2VydGVkIGluIHBhY2tldHMgZW4gcm91dGUuIEJ1 dCB0aGlzIGRyYWZ0PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPnNlZW1zIHRvIHJlcXVpcmUgYW4gaW5ncmVzcyByb3V0ZXIgdG8gaW5zZXJ0 IGEgaGVhZGVyIGFuZCBhbiBlZ3Jlc3M8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+cm91dGVyIHRvIHJlbW92ZSBpdC4gSXMgdGhhdCBldmVu IGFsbG93ZWQ/IEFuZCBhcmUgd2Ugc3VyZSBpdCBoYXMgbm88L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+dW5pbnRlbmRlZCBzaWRlIGVmZmVj dHM/PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5E b2Vzbid0IHdvcmsgLSBicmVha3MgUE1UVUQgKHRoZSBvcmlnaW4gcmVjZWl2ZXMgYSBQVEIgd2hp Y2ggc2F5cyBNVFU9WCBidXQgc2VuZGluZyBwYWNrZXRzIG9mIGxlbmd0aCBYIHN0aWxsIGZhaWxz IGR1ZSB0byB0aGUgYWRkZWQgaGVhZGVycykuIFRoaXMgc2hvdWxkIGJlIGluIHRoZSAmcXVvdDtJ UCBwcm90b2NvbCBGQVEmcXVvdDsgLSBJIGNhbid0IHJlbWVtYmVyIGhvdyBtYW55IHRpbWVzIFN0 ZXZlIERlZXJpbmcgaGFkIHRvIGNvcnJlY3QgdGhpcy48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFu Pjxicj4NCjxzcGFuPklQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgY2FuIG9ubHkgYmUgYWRkZWQgdG9n ZXRoZXIgd2l0aCBhbiBvdXRlciBJUHY2IGhlYWRlci4gVGhhdCBlbnN1cmUgdGhhdCBhbnkgSUNN UCBlcnJvcnMgYXJlIHNlbnQgdG8gdGhlIGVuY2Fwc3VsYXRvcnMsIHRoYXQgY2FuIHJlZ2VuZXJh dGUgYSBJQ01QIGVycm9yIHdoaWNoIHdpbGwgaGF2ZSB0aGUgY29ycmVjdCBNVFUgdmFsdWUgZm9y IHRoZSBvcmlnaW5hbCBzZW5kZXIuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj4mbmJzcDsmbmJzcDtFcmlrPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Mi4gVGhlcmUgaXMgbm8gbWVudGlvbiBvZiBNVFUgc2l6 ZSBvciBmcmFnbWVudGF0aW9uLiBXaGF0IGhhcHBlbnMgaWY8L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+dGhlIHVzZXIgcGFja2V0IHBsdXMg dGhlIGFkZGVkIGhlYWRlciBleGNlZWRzIHRoZSBuZXR3b3JrJ3MgTVRVPzwvc3Bhbj48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+My4gSSB0aGluayB0 aGlzIG1vZGVsIGlzIGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byB0aGUgcHJvYmxlbSBwcmVzZW50 ZWQ8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+YnkgQmVoY2V0IGluIGRyYWZ0LXNhcmlrYXlhLTZtYW4tc2Fkci1vdmVydmlldy48L3NwYW4+ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFu Pjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JyaWFuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+DQo8c3Bhbj5J RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEg aHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4N CjxzcGFuPkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2PC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48 YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B250E09C99CF45B59997942DD81A7692ciscocom_-- From nobody Sat Nov 15 17:42:35 2014 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 06A621A00FE; Sat, 15 Nov 2014 17:42:29 -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 clmo4GqY8GxE; Sat, 15 Nov 2014 17:42:26 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan1.extendcp.co.uk [79.170.44.231]) (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 CC9721A02F1; Sat, 15 Nov 2014 17:42:25 -0800 (PST) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XporA-0000OX-77; Sun, 16 Nov 2014 01:42:24 +0000 Received: from lb1.hi.local ([10.0.1.197] 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 1Xpor9-0005Zv-Qr; Sun, 16 Nov 2014 01:42:24 +0000 Received: from host31-51-175-12.range31-51.btcentralplus.com ([31.51.175.12] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Xpor7-0005lk-Nz; Sun, 16 Nov 2014 01:42:22 +0000 Message-ID: <546800EC.9090607@gridmerge.com> Date: Sun, 16 Nov 2014 01:42:04 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Carsten Bormann , Routing Over Low power and Lossy networks References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> <546623D2.4060207@gridmerge.com> <26D6758E-C9EA-4DB4-AD80-8B865A7E1962@tzi.org> In-Reply-To: <26D6758E-C9EA-4DB4-AD80-8B865A7E1962@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050400000500050202050806" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/bbQMHXef3ScpJ_QccWmpkdxhDDg Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt 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: Sun, 16 Nov 2014 01:42:29 -0000 This is a cryptographically signed message in MIME format. --------------ms050400000500050202050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Carsten, Comments inline. Robert On 14/11/2014 4:05 PM, Carsten Bormann wrote: > On 14 Nov 2014, at 05:46, Robert Cragie w= rote: >> Question - any reason the value 010001XY was chosen for the escape cod= e? > Note that the escape space is not taken just for RFC 6553 compression; = it can be used for encoding other NHCs as well. Yes, I realise that one escape code can escape 2 bits of=20 information from the succeeding NHC and that text for the NHC itself=20 must describe how the preceding escape code(s) 2 bits are used. I think=20 some extra explanatory text plus some guidance on choosing what data you = might want to escape (i.e. that which is normally steady state and=20 changes exceptionally) might help as it isn't immediately obvious. > > The idea was to reserve some space around that so if we want to extend = the escape space for some future NHC, we can do so while keeping it conti= guous. OK, understood > > Note also that RFC 6282 already has variable length processing for hop = limit and address compression, so the impact of adding a third instance i= s going to be limited. (I need to write that up some more in draft-*-lwi= g-6lo.) I don't see any issue where the IPv6 packet is reassembled every=20 hop. I was wondering if there might be an issue in the case of fragment=20 forwarding although with RPL (i.e. route over), I am not sure if=20 fragment forwarding is actually possible anyway, so it may not be an=20 issue > > Since just about every data packet in a RPL network will carry an RPI, = saving a single byte is worth quite some effort. I don't disagree and if the consensus is that it is worth the extra = processing then I have no objection. I realise "bits in the ether" in=20 constrained networks are costly compared to the still fairly trivial=20 extra processing for the escape. > > Gr=FC=DFe, Carsten > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------ms050400000500050202050806 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 Fw0xNDExMTYwMTQyMDRaMCMGCSqGSIb3DQEJBDEWBBSvzkbnMCRmbHDXnI3c9uYPVD2Z/zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQB03wobKDQNXuqKS7lkQkcS6fm665++KuTt ees0vK1xJPd8t5b1nd9M3LWXiGOTi9a8gIyU07GG1/6dW2HEhpGsqsoLBB5vohhbFfQWVNug y2DNtssLh8onSxMV4y+tv98H9zThS5OM6Ti/kxgYXbQ1tumFkmyzNgd94SybNvUzqAbfs1X8 Yb4oMGrxmLkMD4CN3UI9/mDBRSp8oYWRzKaB3OnatSGD5FflzLXcE9AQIidDp9+7Rkzerx2N kQKjvwbfKqN1cnh671FbSXr0C3KOrS32q0Qzo3BBCCbEN4GayCH4jW0GcGlALOUkq2WJ90lH Y1WKOH4LSUK/s4vsRBJEAAAAAAAA --------------ms050400000500050202050806-- From nobody Sat Nov 15 21:48:31 2014 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 569D31A898C for ; Sat, 15 Nov 2014 21:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 OsYlUTNxs6KW for ; Sat, 15 Nov 2014 21:48:27 -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 955EC1A898A for ; Sat, 15 Nov 2014 21:48:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D71E20012 for ; Sun, 16 Nov 2014 00:50:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 57627637F4; Sun, 16 Nov 2014 00:48:26 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 33A32637EA for ; Sun, 16 Nov 2014 00:48:26 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <54667C2C.6000509@gmail.com>, <5466AB5C.9070806@acm.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/a5fdWbMne6IklHd8OUx-yhXfufc Subject: Re: [Roll] Fwd: draft-previdi-6man-segment-routing-header 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: Sun, 16 Nov 2014 05:48:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > This also relates to our discussion on whether a RH or a RPL option c= an > be inserted or cause an extra IPinIP encapsulation. Certainly the rule > is to encapsulate. > This is where the Flow Label technique was of particular interest. So you are saying that in order for us to add the RFC6553 header (no matter how compressed it is), we have to encapsulate all external traffic. I forgot that part in our excitement to come to consensus. This really sucks for RPL over things that don't need/want 6loHC (802.11* links, ethernet)... it sucks because it means screwing up the end to end MT= U. Are you saying you want to re-open the flow-label discussion? > Now if we could go along the path of a routing dispatch where all the > LLN routing artifacts are stored prior to the compressed packet we > could probably make things innocuous. I don't understand this part. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGg6poCLcPvd0N1lAQK6Pwf+LYvb8cQEYXOSVIhZTSdsTuPE6qx3TSl7 +kqPJoMMbrv3ivvwE40quMc967159xl8M3y7HJo8AcT98LwieNJhk9XoQq5epuHu dtA3az4Z6ThBs2bHVoxzo7gKKVsEDYgD9+3xz0PeG5xbw/9gzDyrojXUGJ1hXgnJ pnujhpsl8Z6ZYdVHnOX01h9liAFFBO1GC76aTU1BgGpSZFuzHkbRYyAVEICuSoWb farES0RBvwvEbNRIanqRMvo036hE9kDyhvzOa+5qvqBl9X7E+jtQ8n8yaPg9z1Uj oPa+VjKq8Wav1N2lBr79d/Yn2yAEZCz0GTgCrkshosT+7EoeFYrlww== =AQ6S -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 15 22:59:26 2014 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 D40421A89A6 for ; Sat, 15 Nov 2014 22:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 Riyy832pShBt for ; Sat, 15 Nov 2014 22:59:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730C71A1B09 for ; Sat, 15 Nov 2014 22:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14639; q=dns/txt; s=iport; t=1416121161; x=1417330761; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ew2IsBRLa/8qNoUAvd+hCzf1s1sfl37vfzI+SE5eukQ=; b=fyPhKiZRtHxrMaam3QXy0nz1ZJWdMQgkE4xun9xh+zJkFJtOGaUUO1yp 1ftvApzNRAy1egGEU7MEHD9HXeZfpX8G3Zu5v5yi6bFrAy0dhuqRSj7Z3 3WkE0B2lib1ama6bdKN7bvAarQ2X6W0CWh6GBJhAO+V0WaHEddOlqJSIi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMtKaFStJV2d/2dsb2JhbABbgkhGVVkE01gCgQkWAQEBAQF9hAMBAQMBLVELAgEIIh0HMhQRAgQTCBOIHQnQMgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQcTiDLYEeBZJHhyaGE44KhzyDfG2BSIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,396,1413244800"; d="scan'208,217"; a="97009084" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 16 Nov 2014 06:59:20 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAG6xKSW017349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 16 Nov 2014 06:59:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 16 Nov 2014 00:59:20 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Fwd: draft-previdi-6man-segment-routing-header Thread-Index: AQHQAFbVfdYglDMLE0GUchpU6eOffZxhScYA///tBo2AAe78AP//rJ8w Date: Sun, 16 Nov 2014 06:59:19 +0000 Deferred-Delivery: Sun, 16 Nov 2014 06:59:00 +0000 Message-ID: References: <54667C2C.6000509@gmail.com>, <5466AB5C.9070806@acm.org> <27581.1416116906@sandelman.ca> In-Reply-To: <27581.1416116906@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.184] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A6282Axmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/drw4iPtcwgc9hN70B_KRJaE_0Y4 Subject: Re: [Roll] Fwd: draft-previdi-6man-segment-routing-header 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: Sun, 16 Nov 2014 06:59:24 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A6282Axmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Michael > > This is where the Flow Label technique was of particular interest. > > So you are saying that in order for us to add the RFC6553 header (no matt= er how > compressed it is), we have to encapsulate all external traffic. > I forgot that part in our excitement to come to consensus. > This really sucks for RPL over things that don't need/want 6loHC (802.11*= links, > ethernet)... it sucks because it means screwing up the end to end MTU. [PT] Yes, I insisted on it again at the 6lo presentation I made on the subj= ect My slide 3 was like: * Flow Label compresses RPI down to 20 bits * Flow label avoids IP-in-IP encapsulation * Flow Label needs 6MAN approval * 6lo/NHC is unambiguous about RPI * 6lo/NHC allows to compress 2-byte rank * 6lo/NHC is a compressed form of RFC 6553 as opposed to a new forma= t I presented at 6MAN, with the following asks 1) the right for a source in the LLN not to set the flow label 2) the right for the LLN border router to reset the LLN for packets coming = in the LLN 3) as an extension of 2) the right for the LLN border router to set the LLN= that it just rest to a new value 4) as an extension to 3) the right for any router in the LLN to update the = flow label Noting that: 4) is what we need to use the flow label for RPL. 3) is what we need to maintain ISA100.11a legit. 1) and 2) are meant to save energy in the LLN. > Are you saying you want to re-open the flow-label discussion? [PT] I suggest we keep exploring 6lo solutions. At the moment we do not hav= e a conclusion there. So it is safe that at the same time try to remove the 6MAN-related argument= s against the flow label approach so we have free hands ultimately. > > > Now if we could go along the path of a routing dispatch where all t= he > > LLN routing artifacts are stored prior to the compressed packet we > > could probably make things innocuous. > > I don't understand this part. > [PT] This is something I hinted at the 6TiSCH call. There is a third way that places all the LLN routing artifacts, including R= H3 and RPI, in a routing dispatch, prior to the compressed packet. A dispatch for the RPI only was overkill, but a routing dispatch can be a g= ood idea that seems to alleviate the need for IP in IP. Let me write that down so everyone can make his own opinion. Cheers, Pascal > > -- > Michael Richardson >,= Sandelman Software Works -=3D > IPv6 IoT consulting =3D- > > --_000_E045AECD98228444A58C61C200AE1BD848A6282Axmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Michael

>     > This is where t= he Flow Label technique was of particular interest.

>

> So you are saying that in order for us to ad= d the RFC6553 header (no matter how

> compressed it is), we have to encapsulate al= l external traffic.

> I forgot that part in our excitement to come= to consensus.

> This really sucks for RPL over things that d= on't need/want 6loHC (802.11* links,

> ethernet)... it sucks because it means screw= ing up the end to end MTU.

 

[PT] Yes, I insisted on it again at the 6lo prese= ntation I made on the subject

 

My slide 3 was like:

 

·        Flow Label compresses RPI down to 20 bits

·        Flow label avoids IP-in-IP encapsulation

·        Flow Label needs 6MAN approval

·        6lo/NHC is unambiguous about RPI<= /p>

·        6lo/NHC allows to compress 2-byte rank<= /o:p>

·        6lo/NHC is a compressed form of RFC 6553 as = opposed to a new format

 

I presented at 6MAN, with the following asks=

 

1) the right for a source in the LLN not to set t= he flow label

2) the right for the LLN border router to reset t= he LLN for packets coming in the LLN

3) as an extension of 2) the right for the LLN bo= rder router to set the LLN that it just rest to a new value

4) as an extension to 3) the right for any router= in the LLN to update the flow label

 

Noting that:

 

4) is what we need to use the flow label for RPL.=

3) is what we need to maintain ISA100.11a legit. =

1) and 2) are meant to save energy in the LLN.

 

> Are you saying you want to re-open the flow-= label discussion?

 

[PT] I suggest we kee= p exploring 6lo solutions. At the moment we do not have a conclusion there.=

So it is safe that at= the same time try to remove the 6MAN-related arguments against the flow la= bel approach so we have free hands ultimately.

 

>

>     > Now if we could= go along the path of a routing dispatch where all the

>     > LLN routing art= ifacts are stored prior to the compressed packet we

>     > could probably = make things innocuous.

>

> I don't understand this part.

>

[PT] This is somethin= g I hinted at the 6TiSCH call.

There is a third way = that places all the LLN routing artifacts, including RH3 and RPI, in a rout= ing dispatch, prior to the compressed packet.

A dispatch for the RP= I only was overkill, but a routing dispatch can be a good idea that seems t= o alleviate the need for IP in IP.

 

Let me write that dow= n so everyone can make his own opinion.

 

Cheers,

 

Pascal

>

> --

> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works = -=3D

> IPv6 IoT consulting =3D-

>

>

 

--_000_E045AECD98228444A58C61C200AE1BD848A6282Axmbrcdx01ciscoc_-- From nobody Wed Nov 19 16:06:52 2014 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 5CBBC1A1B1B for ; Wed, 19 Nov 2014 16:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 A17R_bTIfJhz for ; Wed, 19 Nov 2014 16:06:47 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0670.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::670]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE53C1A1B18 for ; Wed, 19 Nov 2014 16:06:46 -0800 (PST) Received: from DB4PR06MB047.eurprd06.prod.outlook.com (10.242.154.154) by DB4PR06MB046.eurprd06.prod.outlook.com (10.242.154.147) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 19 Nov 2014 23:59:56 +0000 Received: from DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.158]) by DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.158]) with mapi id 15.01.0016.006; Wed, 19 Nov 2014 23:59:56 +0000 From: Yvonne-Anne Pignolet To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] [roll] #163 (applicability-home-building): DAO Policy Thread-Index: AQHP/TMR4R3EnuuX00ycBs/OP1GkkZxfRsQAgAloULA= Date: Wed, 19 Nov 2014 23:59:56 +0000 Message-ID: <7d2f04ccff7e4df8b74f14a8b76acf0c@DB4PR06MB047.eurprd06.prod.outlook.com> References: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> <800e9c000d3ee95159be615efb6b4b13@xs4all.nl> In-Reply-To: <800e9c000d3ee95159be615efb6b4b13@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.238.14.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB046; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB046; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(252514010)(189002)(199003)(377424004)(13464003)(66654002)(2501002)(19580395003)(15975445006)(50986999)(97736003)(31966008)(92566001)(86362001)(19580405001)(64706001)(21056001)(2656002)(20776003)(4396001)(54356999)(66066001)(77096003)(106356001)(122556002)(77156002)(101416001)(62966003)(76576001)(40100003)(46102003)(108616004)(105586002)(230783001)(87936001)(99396003)(120916001)(74316001)(107046002)(95666004)(106116001)(33646002)(76176999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR06MB046; H:DB4PR06MB047.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ch.abb.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/94WcnqIE_WGyVj2NpPvQq6eDVSE Cc: "draft-ietf-roll-applicability-home-building@tools.ietf.org" , "yvonneanne.pignolet@gmail.com" Subject: Re: [Roll] [roll] #163 (applicability-home-building): DAO Policy 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: Thu, 20 Nov 2014 00:06:50 -0000 Dear Peter Thanks for your suggestions on this and the other tickets I opened (#162-16= 6). I agree with your proposed improvements and I am looking forward to the= next version :) Regards Yvonne-Anne Yvonne-Anne Pignolet Dr. Sc. ETH Z=FCrich ABB Corporate Research Segelhofstrasse 1K 5400 Baden-D=E4ttwil, Switzerland Phone: +41 58 586 86 56 Mobile: +41 79 766 10 54 email: yvonne-anne.pignolet@ch.abb.com -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Donnerstag, 13. November 2014 16:19 To: roll@ietf.org Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org; yvonneanne.= pignolet@gmail.com Subject: Re: [Roll] [roll] #163 (applicability-home-building): DAO Policy HI Yvonne, after some discussions we propose the following text, that you will easily = recognize. Nodes send DAO messages to establish downward paths from the root to themselves. DAO messages are not acknowledg= ed in networks composed of battery operated field devices in order to minim= ize the power consumption overhead associated with path discovery. The DAO = messages build up a source route because the nodes are recommended to be in= non-storing mode. If devices in LLNs participate in multiple RPL instances and DODAGs, it is = highly recommended that both the RPLInstance ID and the DODAGID be included= in the DAO. many thanks, Peter roll issue tracker schreef op 2014-11-10 23:09: > #163: DAO Policy >=20 > Yvonne-Anne Pignolet: > In 4.1.3. The authors consider DAO policy to be > out of scope. However, if basic RPL is applicable for home and > building automation scenarios then due to P2MP traffic from roots > DAOs are required. As in the industrial applicability statement I thus > recommend a paragraph such as "Nodes send DAO messages to establish > downward paths from the root to themselves. DAO messages are not > acknowledged in networks composed of battery operated field devices in > order to minimize the power consumption overhead associated with path > discovery. If devices in LLNs participate in multiple RPL instances > and DODAGs, it is highly recommended that both the RPLInstance ID and > the DODAGID be included in the DAO." If the mailing list consensus is > that P2P RPL is to be used only, then this Section should state that > DAO messages are not sent in this case. In addition a comment on > P2P-DRO Acknowledgement (P2P-DRO-ACK) would be helpful >=20 > Peter van der Stok: > Some text to motivate the out of scope of DAO policy can be added. > For the multiple RPL instances, I prefer to include a reference to=20 > other > texts. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Thu Nov 20 02:51:09 2014 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 4C29A1A016C for ; Thu, 20 Nov 2014 02:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 ZrXplJa3mCLj for ; Thu, 20 Nov 2014 02:51:05 -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 2DC1B1A00FA for ; Thu, 20 Nov 2014 02:51:05 -0800 (PST) Received: from localhost ([::1]:52188 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPJt-0007sc-0G; Thu, 20 Nov 2014 02:50:37 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:50:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/164#comment:1 Message-ID: <086.a4836915dcc9ce24d42bb6c2b7e930dc@trac.tools.ietf.org> References: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/9K3X2vSWk2bNgwD4KIzNnaTzOOg Cc: roll@ietf.org Subject: Re: [Roll] [roll] #164 (applicability-home-building): Recommended Metric 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: Thu, 20 Nov 2014 10:51:07 -0000 #164: Recommended Metric Comment (by consultancy@vanderstok.org): This is a mistake of ours. We will write that ETX is recommended -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: major | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 02:53:11 2014 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 420FC1A0174 for ; Thu, 20 Nov 2014 02:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 1Unesb4fCEJH for ; Thu, 20 Nov 2014 02:53: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 7DFCD1A016C for ; Thu, 20 Nov 2014 02:53:08 -0800 (PST) Received: from localhost ([::1]:52314 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPMF-0008UX-NN; Thu, 20 Nov 2014 02:53:03 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:53:03 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/164#comment:2 Message-ID: <086.ff196fcb6b223294c91cda521cdac4a9@trac.tools.ietf.org> References: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <071.32b331884c4eb4e0fdbf759201ca2efc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/PZm4229JjBq6tHK0E7-4swYcIYs Cc: roll@ietf.org Subject: Re: [Roll] [roll] #164 (applicability-home-building): Recommended Metric 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: Thu, 20 Nov 2014 10:53:10 -0000 #164: Recommended Metric Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: major | Status: closed Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 02:55:28 2014 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 814ED1A016C for ; Thu, 20 Nov 2014 02:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 7a-5r63TNb_N for ; Thu, 20 Nov 2014 02:55:25 -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 9D45B1A0197 for ; Thu, 20 Nov 2014 02:55:18 -0800 (PST) Received: from localhost ([::1]:52439 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPOM-0001JJ-9W; Thu, 20 Nov 2014 02:55:14 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:55:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/163#comment:1 Message-ID: <086.abfd3363ebe53b6376f340bd60dccd37@trac.tools.ietf.org> References: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3veE6rcqE2jOaRsDIv1l8Dp052U Cc: roll@ietf.org Subject: Re: [Roll] [roll] #163 (applicability-home-building): DAO Policy 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: Thu, 20 Nov 2014 10:55:27 -0000 #163: DAO Policy Comment (by consultancy@vanderstok.org): Proposed text Nodes send DAO messages to establish downward paths from the root to themselves. DAO messages are not acknowledged in networks composed of battery operated field devices in order to minimize the power consumption overhead associated with path discovery. The DAO messages build up a source route because the nodes are recommended to be in non-storing mode. If devices in LLNs participate in multiple RPL instances and DODAGs, it is highly recommended that both the RPLInstance ID and the DODAGID be included in the DAO. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: minor | Status: new Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 02:55:49 2014 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 504AD1A0179 for ; Thu, 20 Nov 2014 02:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 8Qh3VNe7ezdj for ; Thu, 20 Nov 2014 02:55:44 -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 C2B6F1A0174 for ; Thu, 20 Nov 2014 02:55:44 -0800 (PST) Received: from localhost ([::1]:52489 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPOl-0001WR-US; Thu, 20 Nov 2014 02:55:39 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:55:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/163#comment:2 Message-ID: <086.a41248a60486c9a7df8c010c144a59e9@trac.tools.ietf.org> References: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <071.7c177dda1330be795d5ea4936294a319@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JaFhE3mOouFkUdvwzFLtNePQ8vw Cc: roll@ietf.org Subject: Re: [Roll] [roll] #163 (applicability-home-building): DAO Policy 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: Thu, 20 Nov 2014 10:55:48 -0000 #163: DAO Policy Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: minor | Status: closed Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 02:57:11 2014 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 69BED1A0179 for ; Thu, 20 Nov 2014 02:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 ae5aYk_oktax for ; Thu, 20 Nov 2014 02:57:07 -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 DE4471A016C for ; Thu, 20 Nov 2014 02:57:07 -0800 (PST) Received: from localhost ([::1]:52548 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPQ6-00026S-M8; Thu, 20 Nov 2014 02:57:02 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:57:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/162#comment:1 Message-ID: <086.5475d7253d68c93c48ffd3abe86bede6@trac.tools.ietf.org> References: <071.552483167f70c2f1001ce26c2c4b6172@trac.tools.ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <071.552483167f70c2f1001ce26c2c4b6172@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/nU5I-feNSlhE8UzR5gOpoBL5btI Cc: roll@ietf.org Subject: Re: [Roll] [roll] #162 (applicability-home-building): Use of basic RPL vs P2P RPL 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: Thu, 20 Nov 2014 10:57:09 -0000 #162: Use of basic RPL vs P2P RPL Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: We propose to leave the text unchanged. In section 2.2.7 it is written that RPL is recommended for SS traffic. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: minor | Status: closed Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 02:58:47 2014 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 8D5291A0174 for ; Thu, 20 Nov 2014 02:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 8EkwxXWwskmu for ; Thu, 20 Nov 2014 02:58:44 -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 CFA401A016C for ; Thu, 20 Nov 2014 02:58:44 -0800 (PST) Received: from localhost ([::1]:52610 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPRg-00030x-7k; Thu, 20 Nov 2014 02:58:40 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:58:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/165#comment:1 Message-ID: <086.ec5ba08df1a58c90b0f877d35f7e482c@trac.tools.ietf.org> References: <071.ea7747ad3029e024bad1f4db878636b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 165 In-Reply-To: <071.ea7747ad3029e024bad1f4db878636b6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/vMnRP_wzcVfcUUpgXnbD9gc5wNo Cc: roll@ietf.org Subject: Re: [Roll] [roll] #165 (applicability-home-building): DIO max interval 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: Thu, 20 Nov 2014 10:58:46 -0000 #165: DIO max interval Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: We propose to add the following text to section 4.3.1. When a node sends a changed DIO, this is an inconsistency and forces the receiving node to respond within Imin. So when something happens which affects the DIO, the change is ideally communicated to a node n hops away within n times Imin. Often, dependent on the node density, packets are lost, or not sent, leading to larger delays. In general we can expect that DIO changes to propagate within 1 to 3 seconds within the envisaged networks. When nothing happens, the DIO sending interval increases to 4.37 minutes, thus drastically reducing the network load. When a node does not receive DIO messages during more than 10 minutes it can safely conclude the connection with other nodes has been lost. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: minor | Status: closed Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Nov 20 03:00:24 2014 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 5EFDD1A0174 for ; Thu, 20 Nov 2014 03:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 zgET_HmxMAmB for ; Thu, 20 Nov 2014 03:00: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 A76A11A0196 for ; Thu, 20 Nov 2014 03:00:03 -0800 (PST) Received: from localhost ([::1]:52643 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XrPSu-00037y-NV; Thu, 20 Nov 2014 02:59:56 -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-home-building@tools.ietf.org, consultancy@vanderstok.org X-Trac-Project: roll Date: Thu, 20 Nov 2014 10:59:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/166#comment:1 Message-ID: <086.c9b8041a047cbab4ba984eafc075d7e3@trac.tools.ietf.org> References: <071.7295354c7dfda72357e3f748cc1630f6@trac.tools.ietf.org> X-Trac-Ticket-ID: 166 In-Reply-To: <071.7295354c7dfda72357e3f748cc1630f6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@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: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/EL-lEDqfhk_UscWPTjnIX7oO6mw Cc: roll@ietf.org Subject: Re: [Roll] [roll] #166 (applicability-home-building): Manageability 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: Thu, 20 Nov 2014 11:00:21 -0000 #166: Manageability Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed Comment: we propose the following text for section 6. At this moment it is not clear how homenets will be managed. Consequently it is not clear which tools will be used and which parameters must be exposed for management. In building control, management is mandatory. It is expected that installations will be managed using the set of currently available tools (including IETF tools like MIBS, NETCONF modules, DHCP and others) with large differences between the ways an installation is managed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: enhancement | building@tools.ietf.org Priority: trivial | Status: closed Component: applicability-home- | Milestone: building | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Sun Nov 23 13:16:16 2014 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 A51471A1B0F for ; Sun, 23 Nov 2014 13:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.987 X-Spam-Level: * X-Spam-Status: No, score=1.987 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QKOlVp_dR_VN for ; Sun, 23 Nov 2014 13:16:13 -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 7AF371A1AAA for ; Sun, 23 Nov 2014 13:16:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FBCB20098; Sun, 23 Nov 2014 16:18:58 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5DD2E637F5; Sun, 23 Nov 2014 16:16:12 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 465BA63745; Sun, 23 Nov 2014 16:16:12 -0500 (EST) From: Michael Richardson To: Anders Brandt , consultancy , roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/GzkDk-oqjT4NoR9qQWWENSS9ct0 Subject: [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: Sun, 23 Nov 2014 21:16:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable 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.=20 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 shou= ld remove the reference -- it doesn't help anyone trying to implement an interoperable device. =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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHJOmYCLcPvd0N1lAQK4zgf8CE0AeKd1rQjMyVvASJJubWtzub1zpJoa ClVJpdukNfeYp9c40lbLQbdjgqQ58CaCZPlyiVpVn7KoicPFCGf/qmZpFj3pIH2l un+QQa3mnRXAccWDFmEKvoqs8B/Gcm27i6A/3y+3elGqHkmmX6IiciDDKGoSAZVz 7IxwOcR0gf/e4aiwYQCaoueAkfb8YNqhJq6MixxrvDsB3MOFolLy8iRIu9T2fw/q FSlkrGfnSHSsZeRi6GxSDTD//9vK4dy6YmVf+qJu1GS4ShsRUmI4JI9fWPYRH1zH /eUjIgdTeF9QDxpVcGw4+ulsRVdNILhc70TbdeeEKU3Gf1kWRltHfw== =OCUJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 23 15:45:25 2014 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 7C3B21A1B5B; Sun, 23 Nov 2014 15:45:23 -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 j1uvchtGeQsa; Sun, 23 Nov 2014 15:45:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA51A1B72; Sun, 23 Nov 2014 15:45:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ines Robles" To: afarrel@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141123234507.16974.17396.idtracker@ietfa.amsl.com> Date: Sun, 23 Nov 2014 15:45:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/0tqPA8KuPpBbKPPn2Shgxu7C6Tc Cc: roll@ietf.org, iesg-secretary@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Publication has been requested for draft-ietf-roll-admin-local-policy-01 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: Sun, 23 Nov 2014 23:45:23 -0000 Ines Robles has requested publication of draft-ietf-roll-admin-local-policy-01 as Informational on behalf of the ROLL working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Sun Nov 23 23:17:55 2014 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 96C181A1AB9 for ; Sun, 23 Nov 2014 23:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 xBI2rx7gA6ap for ; Sun, 23 Nov 2014 23:17:50 -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 6CBD21A1A73 for ; Sun, 23 Nov 2014 23:17:50 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud3.xs4all.net with ESMTP id KKHn1p00D4NtgTm01KHnAd; Mon, 24 Nov 2014 08:17:48 +0100 Received: from [2001:983:a264:1:64eb:3bd9:ee99:d867] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 24 Nov 2014 08:17:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 24 Nov 2014 08:17:47 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <30100.1416777372@sandelman.ca> References: <30100.1416777372@sandelman.ca> Message-ID: <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> X-Sender: stokcons@xs4all.nl (tiHEUjjAvgelfiF2xIs4WWI+LDUH3wYT) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-kHuOXudUOfoOnWYNzNYDkWWbjE Cc: roll@ietf.org, mcr@sandelman.ca, Anders Brandt 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, 24 Nov 2014 07:17:52 -0000 HI Michael, 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. From nobody Mon Nov 24 00:10:39 2014 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 EFA081A1BF2; Mon, 24 Nov 2014 00:10:34 -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 wgqMOigfAH4s; Mon, 24 Nov 2014 00:10:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9101A1BFA; Mon, 24 Nov 2014 00:10:32 -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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124081032.1356.57231.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 00:10:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/otDpeKkETt9y6WYWi9beZipHjTk Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-admin-local-policy-02.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, 24 Nov 2014 08:10:35 -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 forwarder policy for multicast with admin-local scope Authors : Peter van der Stok Robert Cragie Filename : draft-ietf-roll-admin-local-policy-02.txt Pages : 12 Date : 2014-11-24 Abstract: The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-admin-local-policy-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-02 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 Nov 24 00:10:41 2014 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 2F06E1A1BF3 for ; Mon, 24 Nov 2014 00:10:36 -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 Et0lZOtQP9nd; Mon, 24 Nov 2014 00:10:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B221A1BFC; Mon, 24 Nov 2014 00:10:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org, adrian@olddog.co.uk X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124081032.1356.81303.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 00:10:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7Wmag5wwzLU7nOYtjO27MWr8l18 Subject: [Roll] New Version Notification - draft-ietf-roll-admin-local-policy-02.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, 24 Nov 2014 08:10:36 -0000 A new version (-02) has been submitted for draft-ietf-roll-admin-local-policy: http://www.ietf.org/internet-drafts/draft-ietf-roll-admin-local-policy-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-02 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. IETF Secretariat. From nobody Mon Nov 24 00:50:32 2014 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 740421A1DFA for ; Mon, 24 Nov 2014 00:50:30 -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 xaQrPbEEu7pj for ; Mon, 24 Nov 2014 00:50:29 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03B61A1DBD for ; Mon, 24 Nov 2014 00:50:28 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud3.xs4all.net with ESMTP id KLqS1p00G4NtgTm01LqSvB; Mon, 24 Nov 2014 09:50:26 +0100 Received: from [2001:983:a264:1:64eb:3bd9:ee99:d867] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 24 Nov 2014 09:50:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 24 Nov 2014 09:50:26 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> Message-ID: <60a7b1e9499ecc8895750534e0cbfd4e@xs4all.nl> X-Sender: stokcons@xs4all.nl (//AcwV7VW9RQH6/kVB35PoIHtbyxcG10) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Z_u0T9PqQQUQnFq5pgztUy4wVUg Cc: roll@ietf.org, mcr@sandelman.ca, Anders Brandt 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, 24 Nov 2014 08:50:30 -0000 Hi Michael, rereading section 7.1, I suggest the following replacement: A new DTLS protocol is proproposed in [dtls-relay] To be replaced with: New approaches to initial security deployment are being developed in [dtls-relay] and [6tisch bootstrap]. 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. peter van der Stok schreef op 2014-11-24 08:17: > HI Michael, > > 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. From nobody Mon Nov 24 12:46:07 2014 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 332D61A9064; Mon, 24 Nov 2014 12:46:03 -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 Tzwz5SGSh1qQ; Mon, 24 Nov 2014 12:46:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 937981A906C; Mon, 24 Nov 2014 12:45:59 -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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124204559.12649.42457.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 12:45:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DED_-lDaGRfWEg2gGSjkavCS4BQ Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-11.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, 24 Nov 2014 20:46:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networks (MPL) Authors : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-11.txt Pages : 25 Date : 2014-11-24 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-11 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 Thu Nov 27 06:03:22 2014 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 848F81A0119; Thu, 27 Nov 2014 06:03: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 pk112fBUnS39; Thu, 27 Nov 2014 06:03: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 743901A008B; Thu, 27 Nov 2014 06:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3666; q=dns/txt; s=iport; t=1417096994; x=1418306594; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2/o5u2xaeuacrGK0pb1ZaF56ZaTY2Zq8D1oiFDrr58Y=; b=V+O5eV4OXTtg0YL9LFPAubB8lComfcMZqdZRfRbmuoOJV2qkvQPAbIty 0kF59kxbAMWNo/oNQHr1j/hkDr4aakxoK9L3Z8ENI3/33Xac89rphUym7 OVrS5nTvl5I8U/ylJsJKhB/anEKNNu2PaAnnkBiH9QUfeEyq9NdWkv4SK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAKYud1StJA2I/2dsb2JhbABbgwZRXMUZgiqGSwIcbRYBAQEBAX2EAgEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYg3DbwOliwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgS6PHDEHBoJyNoEfBZJlhGeIaj+DGpIOg3xvAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="100674078" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 27 Nov 2014 14:03:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sARE3DnL019583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Nov 2014 14:03:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 08:03:13 -0600 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0w Date: Thu, 27 Nov 2014 14:03:12 +0000 Deferred-Delivery: Thu, 27 Nov 2014 14:03:00 +0000 Message-ID: References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> In-Reply-To: <20141127133537.6084.69209.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.49.80.23] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qt1VKDUXNWimwN02nX_06o3kh_8 Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.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: Thu, 27 Nov 2014 14:03:16 -0000 RGVhciBhbGw6DQoNClRoaXMgaXMgYSByZXNwb25zZSB0byB0aGUgcXVlc3Rpb24gYWJvdXQgdGhl IGNvbXByZXNzaW9uIG9mIFJGQyA2NTUzIG9uIHRvcCBvZiBSRkMgNjU1NC4NCkl0IHNlZW1zIGV4 YWdnZXJhdGVkIHRvIGNvbnN1bWUgYSBkaXNwYXRjaCB0eXBlIGZvciB0aGUgUlBMIG9wdGlvbiBv bmx5LiANCkJ1dCBoZXJlLCB3ZSBpbnRyb2R1Y2UgYSByb3V0aW5nIGhlYWRlciB3aGljaCBpcyB0 aGUgZXF1aXZhbGVudCBvZiB0aGUgbWVzaCBoZWFkZXIgaW4gUkZDIDQ5NDQ7IHdlIHByb3Bvc2Ug YSBjb21wcmVzc2VkIFRMViBmb3JtYXQgdGhhdCBjYW4gZW5jb2RlIFJIMywgUlBMIG9wdGlvbiwg SVAtaW4tSVAsIGFuZCBpcyBmdXJ0aGVyIGV4dGVuc2libGUsIGZvciBpbnN0YW5jZSBmb3IgdXBj b21pbmcgIEJJRVIuDQpBcyBpdCBnb2VzLCB0aGUgbWVzaCBoZWFkZXIgY29uc3VtZXMgMS8zIG9m IGFsbCB0aGUgNkxvV1BBTiBhZGRyZXNzYWJsZSBzcGFjZSBmb3IgYXBwbGljYXRpb24gb25seSBp biBNZXNoLXVuZGVyLiANClRoaXMgZHJhZnQgcmV1c2VzIHRoYXQgc3BhY2UgaW4gUm91dGUtb3Zl ciB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgUm91dGUtb3ZlciB3aWxsIG5vdCBjby1leGlzdCBp biBhIHNtYSBlbmV0d29yayB3aXRoIE1lc2gtdW5kZXIgZW5jb2RlZCBpbiB0aGUgUkZDIDQ5NDQg ZmFzaGlvbi4NCklmIHRoZXJlIGlzIGVmZmVjdGl2ZWx5IGEgbmVlZCBmb3IgY28tZXhpc3RlbmNl LCBkZXZpY2VzIGhhdmUgdG8gaW1wbGVtZW50IHRoZSBuZXcgTWVzaC11bmRlciBmb3JtYXQgdGhh dCBpcyBhbHNvIHByb3Bvc2VkIGluIHRoZSBkcmFmdC4NCg0KQ29tbWVudHMgd2VsY29tZSwNClBh c2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogamV1 ZGkgMjcgbm92ZW1icmUgMjAxNCAxNDozNg0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7 IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7IExhdXJlbnQgVG91dGFpbjsgQ2Fyc3RlbiBCb3Jt YW5uOyBMYXVyZW50IFRvdXRhaW47IERyLiBDYXJzdGVuIEJvcm1hbm4NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRj aC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVydC02bG8tcm91 dGluZy1kaXNwYXRjaC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg UGFzY2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaA0KUmV2aXNpb246CTAwDQpUaXRs ZToJCUEgUm91dGluZyBIZWFkZXIgRGlzcGF0Y2ggZm9yIDZMb1dQQU4NCkRvY3VtZW50IGRhdGU6 CTIwMTQtMTEtMjUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE5DQpV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt dGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRp c3BhdGNoLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg c3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIG5ldyA2TG9XUEFOIGRpc3BhdGNoIHR5cGUgZm9yIHVz ZSBpbg0KICAgUm91dGUtb3ZlciBhbmQgbWl4ZWQgTWVzaC11bmRlciBhbmQgUm91dGUtb3ZlciB0 b3BvbG9naWVzLCB0aGF0DQogICByZXVzZXMgdGhlIGVuY29kaW5nIG9mIHRoZSBtZXNoIHR5cGUg ZGVmaW5lZCBpbiBSRkMgNDk0NCBmb3IgcHVyZQ0KICAgTWVzaC11bmRlciB0b3BvbG9naWVzLiAg VGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyBhIG1ldGhvZCB0bw0KICAgY29tcHJlc3Mg UlBMIE9wdGlvbiAoUkZDNjU1MykgaW5mb3JtYXRpb24gYW5kIFJvdXRpbmcgSGVhZGVyIHR5cGUg Mw0KICAgKFJGQzY1NTQpLCBhbiBlZmZpY2llbnQgSVAtaW4tSVAgdGVjaG5pcXVlIGFuZCBvcGVu cyB0aGUgd2F5IGZvcg0KICAgZnVydGhlciByb3V0aW5nIHRlY2huaXF1ZXMuICBUaGlzIGV4dGVu ZHMgNkxvV1BBTiBUcmFuc21pc3Npb24gb2YNCiAgIElQdjYgUGFja2V0cyAoUkZDNDk0NCksIGFu ZCBpcyBhcHBsaWNhYmxlIHRvIG5ldyBsaW5rLWxheWVyIHR5cGVzDQogICB3aGVyZSA2TG9XUEFO IGlzIGJlaW5nIGRlZmluZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sat Nov 29 11:25:25 2014 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 C2B911A1E0C for ; Sat, 29 Nov 2014 11:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 muOrheX_5s3t for ; Sat, 29 Nov 2014 11:24:36 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ADD1A1DFA for ; Sat, 29 Nov 2014 11:24:36 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lj1so8494058pab.19 for ; Sat, 29 Nov 2014 11:24:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2e5qb0j9UlXXAx3yW3qU5xJYTFR88N9MmaXoS0gcofU=; b=UmJcWRsO83M8Iy8CIBWpvHF7kBtL08W/LberwYAKcN9YpGY5xtmHpNACSwT0hGlnNh Sr9DgdiqRj16cOd21FVePlVDONJ64twkWVpb3EEkOcDtxTCeW2LhgsKy0N1mu5Ksl3MB m/eI2Xqp4dDm0cU8b7KOGZ65fpOSJ0G1/8mhAE0dNNLJfwxugXQrpaekoVlETW9irVZN MoLR4W5jGfFwv1q6NUdnfOBHHBqPglJNvDIKMoMq7KhZzQweFnn1tkB+nBhF8SvmEFPL jqJh2OKc2RKCKxCBaqUdEGgdjIVbwkoN7XDzStHFbjbMVcMWkMbuljZRcpOd7pumO5jz yk9w== X-Gm-Message-State: ALoCoQmTa51V218/CJx8YAqyz1kpT5eWNpDfikwVB6NG8rwlWRNuKxJtae1u5E6qVTvcl9sz9uqG X-Received: by 10.68.220.169 with SMTP id px9mr85941639pbc.146.1417289075702; Sat, 29 Nov 2014 11:24:35 -0800 (PST) Received: from [192.168.1.113] (75-149-38-150-SFBA.hfc.comcastbusiness.net. [75.149.38.150]) by mx.google.com with ESMTPSA id gy10sm13203023pbd.67.2014.11.29.11.24.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Nov 2014 11:24:33 -0800 (PST) References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> X-Mailer: iPhone Mail (11D201) From: Martin Turon Date: Sat, 29 Nov 2014 11:24:34 -0800 To: "Pascal Thubert (pthubert)" Archived-At: http://mailarchive.ietf.org/arch/msg/roll/z2l357SMQgYbD6Yj32XA2zqYTAg X-Mailman-Approved-At: Sat, 29 Nov 2014 11:25:24 -0800 Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.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: Sat, 29 Nov 2014 19:24:38 -0000 Hi Pascal, I thought the call where this idea of overloading the mesh header was presen= ted was met with general discontent. =20 Also, the rfc4944 calls it the mesh header, it isn't called the mesh-under h= eader. The mesh header is very much in use today, and not purely for mesh-u= nder conceptual designs. =20 I would be wary of proposals that greatly alter the 6lo header, especially t= he dispatch bits, rather than extend it in very general ways. Martin > On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" wrote: >=20 > Dear all: >=20 > This is a response to the question about the compression of RFC 6553 on to= p of RFC 6554. > It seems exaggerated to consume a dispatch type for the RPL option only.=20= > But here, we introduce a routing header which is the equivalent of the mes= h header in RFC 4944; we propose a compressed TLV format that can encode RH3= , RPL option, IP-in-IP, and is further extensible, for instance for upcoming= BIER. > As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable sp= ace for application only in Mesh-under.=20 > This draft reuses that space in Route-over with the assumption that Route-= over will not co-exist in a sma enetwork with Mesh-under encoded in the RFC 4= 944 fashion. > If there is effectively a need for co-existence, devices have to implement= the new Mesh-under format that is also proposed in the draft. >=20 > Comments welcome, > Pascal >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: jeudi 27 novembre 2014 14:36 > To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutain;= Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann > Subject: New Version Notification for draft-thubert-6lo-routing-dispatch-0= 0.txt >=20 >=20 > A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt > has been successfully submitted by Pascal Thubert and posted to the IETF r= epository. >=20 > Name: draft-thubert-6lo-routing-dispatch > Revision: 00 > Title: A Routing Header Dispatch for 6LoWPAN > Document date: 2014-11-25 > Group: Individual Submission > Pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-rout= ing-dispatch-00.txt > Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-routing= -dispatch/ > Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-dispa= tch-00 >=20 >=20 > Abstract: > This specification provides a new 6LoWPAN dispatch type for use in > Route-over and mixed Mesh-under and Route-over topologies, that > reuses the encoding of the mesh type defined in RFC 4944 for pure > Mesh-under topologies. This specification also defines a method to > compress RPL Option (RFC6553) information and Routing Header type 3 > (RFC6554), an efficient IP-in-IP technique and opens the way for > further routing techniques. This extends 6LoWPAN Transmission of > IPv6 Packets (RFC4944), and is applicable to new link-layer types > where 6LoWPAN is being defined. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Sun Nov 30 01:00:04 2014 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 0C6EB1A1A2E; Sun, 30 Nov 2014 01:00:00 -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 4ip_7SSZf0QR; Sun, 30 Nov 2014 00:59:58 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B5C1A1A29; Sun, 30 Nov 2014 00:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4666; q=dns/txt; s=iport; t=1417337998; x=1418547598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g8sB9JbFiFr0UE8/Ix/SLgeZyW1P4UNsXt4uiqnOtLY=; b=RbApkfrcriEcMCSkRG3gUqtxJf1v7Fcdm9R9btraD+AEei68Oh5Fzua3 eq3S+oQg+/zlOYk/bFQ+CXdSNAJSIIxgOUt28EYCSwkBCXxiaQihrXxzE GaipSOB0jEHLHrX18IRn0lJwSqAO2DYuN4rFPj+debXVJtJgntvHtnvlv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADDbelStJV2U/2dsb2JhbABbgwZRWMRYgh4MhXZWAoEIFgEBAQEBfYQCAQEBAwEBAQFrCQIFBwQCAQgOAwQBAQEnBycLFAgBCAIEDgUJiC4JDdItAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pphTolMwcGgyOBHwWKXoYnhE2GdYEuPIJ/kFqCN4FEbwGBA4FDAQEB X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="101248696" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 30 Nov 2014 08:59:57 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAU8xuob006554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 08:59:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 02:59:56 -0600 From: "Pascal Thubert (pthubert)" To: Martin Turon Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAPpEACAAH86VA== Date: Sun, 30 Nov 2014 08:59:55 +0000 Message-ID: <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> , <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> In-Reply-To: <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> 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/eeUjiwESsYHx1uNrgJdNg300WQQ Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.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: Sun, 30 Nov 2014 09:00:00 -0000 Hi Martin, The discussion already caused a rethinking of the idea. If it is not enough= we can dig further. The idea as presented in the draft now is not to deprecate the mesh header = but to allow in a different network to use the bits differently knowing tha= t devices will have to be homogeneous inside one network. You were the advocate to protect the future by not consuming too many bits = in the NHC proposal. You also realize that the mesh header consumes 1/3 of = the whole dispatch space, without a way to extend what's done inside. This = is not protecting the future. The new proposal allows to encode the existing MH with limited change but n= ow it is extensible. The price to pay is different network. And the questio= n to the group is whether that is acceptable. Even if there are implementations today, RFC 4944 is not an internet std an= d we have just seen the very beginning of the IoT. Better fix things now th= an later... Pascal > Le 29 nov. 2014 =E0 20:24, Martin Turon a =E9crit : >=20 > Hi Pascal, >=20 > I thought the call where this idea of overloading the mesh header was pre= sented was met with general discontent. =20 >=20 > Also, the rfc4944 calls it the mesh header, it isn't called the mesh-unde= r header. The mesh header is very much in use today, and not purely for me= sh-under conceptual designs. =20 >=20 > I would be wary of proposals that greatly alter the 6lo header, especiall= y the dispatch bits, rather than extend it in very general ways. >=20 > Martin >=20 >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" wrote: >>=20 >> Dear all: >>=20 >> This is a response to the question about the compression of RFC 6553 on = top of RFC 6554. >> It seems exaggerated to consume a dispatch type for the RPL option only.= =20 >> But here, we introduce a routing header which is the equivalent of the m= esh header in RFC 4944; we propose a compressed TLV format that can encode = RH3, RPL option, IP-in-IP, and is further extensible, for instance for upco= ming BIER. >> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable = space for application only in Mesh-under.=20 >> This draft reuses that space in Route-over with the assumption that Rout= e-over will not co-exist in a sma enetwork with Mesh-under encoded in the R= FC 4944 fashion. >> If there is effectively a need for co-existence, devices have to impleme= nt the new Mesh-under format that is also proposed in the draft. >>=20 >> Comments welcome, >> Pascal >>=20 >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: jeudi 27 novembre 2014 14:36 >> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutai= n; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann >> Subject: New Version Notification for draft-thubert-6lo-routing-dispatch= -00.txt >>=20 >>=20 >> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt >> has been successfully submitted by Pascal Thubert and posted to the IETF= repository. >>=20 >> Name: draft-thubert-6lo-routing-dispatch >> Revision: 00 >> Title: A Routing Header Dispatch for 6LoWPAN >> Document date: 2014-11-25 >> Group: Individual Submission >> Pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-ro= uting-dispatch-00.txt >> Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-routi= ng-dispatch/ >> Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-routing-dis= patch-00 >>=20 >>=20 >> Abstract: >> This specification provides a new 6LoWPAN dispatch type for use in >> Route-over and mixed Mesh-under and Route-over topologies, that >> reuses the encoding of the mesh type defined in RFC 4944 for pure >> Mesh-under topologies. This specification also defines a method to >> compress RPL Option (RFC6553) information and Routing Header type 3 >> (RFC6554), an efficient IP-in-IP technique and opens the way for >> further routing techniques. This extends 6LoWPAN Transmission of >> IPv6 Packets (RFC4944), and is applicable to new link-layer types >> where 6LoWPAN is being defined. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Sun Nov 30 04:36:07 2014 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 219131A00B5; Sun, 30 Nov 2014 04:36:05 -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 bmOTlrry6lXF; Sun, 30 Nov 2014 04:36:04 -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 394501A00A8; Sun, 30 Nov 2014 04:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAUCZth0026199; Sun, 30 Nov 2014 13:35:55 +0100 (CET) Received: from [192.168.217.117] (p5489155E.dip0.t-ipconnect.de [84.137.21.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43B1F664; Sun, 30 Nov 2014 13:35:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> Date: Sun, 30 Nov 2014 13:35:54 +0100 X-Mao-Original-Outgoing-Id: 439043753.951151-8800fb70a3a58fc9ffc351b3e39ba343 Content-Transfer-Encoding: quoted-printable Message-Id: <239401C5-C9B7-4368-8008-164F902C68AD@tzi.org> References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> To: Martin Turon X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Dxio9zVdpcXj14Wizkk-1Jwb0nA Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.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: Sun, 30 Nov 2014 12:36:05 -0000 On 29 Nov 2014, at 20:24, Martin Turon wrote: >=20 > The mesh header is very much in use today, and not purely for = mesh-under conceptual designs. =20 Hi Martin, I think it would benefit this discussion if we could learn more about = these use cases. In RFC 4944, the =E2=80=9CMesh Header=E2=80=9D definitely was meant for = mesh-under; we even have a section called 11. Frame Delivery in a Link-Layer Mesh*) to discuss the use of the Mesh Header in forwarding adaptation layer = packets between link-layer entities. But that of course doesn=E2=80=99t = mean there aren=E2=80=99t other ways to make good use of the Mesh Header = =E2=80=94 I=E2=80=99d like to learn more about those. Gr=C3=BC=C3=9Fe, Carsten *) The short forms =E2=80=9Cmesh-under=E2=80=9D and =E2=80=9Croute-over=E2= =80=9D weren=E2=80=99t as much in use in 2007, so this is a long form = trying to say =E2=80=9Cmesh-under=E2=80=9D.