From nobody Thu Oct 2 17:55: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 E2A271ACFB7; Thu, 2 Oct 2014 17:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0ikE2PD7vpgT; Thu, 2 Oct 2014 17:55:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8841ACFBD; Thu, 2 Oct 2014 17:55:29 -0700 (PDT) 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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141003005529.1203.68842.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 17:55:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7iTHWbN-vWvrTfvv6_nKZVENbjQ Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-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: Fri, 03 Oct 2014 00:55:37 -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 : A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL) Authors : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Michael Richardson Filename : draft-ietf-roll-security-threats-11.txt Pages : 39 Date : 2014-10-02 Abstract: This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-security-threats-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 Mon Oct 6 00:43: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 056661A1B46; Mon, 6 Oct 2014 00:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 h2fSfwdXRetO; Mon, 6 Oct 2014 00:43:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773A1A1B5E; Mon, 6 Oct 2014 00:43:23 -0700 (PDT) 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.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006074323.1830.15224.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 00:43:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CsDQaTK9Z8-cW3GR8JgnOZ4nAr8 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-05.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, 06 Oct 2014 07:43:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-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/ From nobody Tue Oct 7 00:10:19 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 3E1841A1B4E for ; Tue, 7 Oct 2014 00:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 geLA1L4bDOTC for ; Tue, 7 Oct 2014 00:10:11 -0700 (PDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549151A9142 for ; Tue, 7 Oct 2014 00:10:09 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id s977A6Ol095230 for ; Tue, 7 Oct 2014 09:10:07 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-131-141.w90-0.abo.wanadoo.fr ([90.0.90.141]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 07 Oct 2014 09:10:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 07 Oct 2014 09:10:05 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (JwdkiJ380W3DcjG+3bwIJbiOfREi1fy6) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lV3_Y2H-OvZ95mCCBg-WWqpb4SA Subject: [Roll] Fwd: 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, 07 Oct 2014 07:10:16 -0000 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 From nobody Fri Oct 10 04:23: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 82DCE1A8A71 for ; Fri, 10 Oct 2014 04:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 SiNgN4SvBGeQ for ; Fri, 10 Oct 2014 04:22:59 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E39A1A8A46 for ; Fri, 10 Oct 2014 04:22:57 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so2876250lbv.19 for ; Fri, 10 Oct 2014 04:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZGJsrEHawPQwSZRddh2MmjEYJ+LGkcok94jqz7acgyk=; b=A/pdSytq37bDQmaiP5thhk2CdvYZoSEhQfOAs6JtgtCH0WfN3uFODFGv8fnk4Gf0kd P8aH8tZ3r4IOx4OypOWLaQy93wOtt0ARnwQ0ACee/AYR943XDS27k0R65ebDIKgxjAuj jBxUn2yxiywIwm72p0+QKNjF4CqzUOgOloEM/ZhbGvayo63MJAxI6sc9m/eDmJ9pvJGq S5GW8USAYFlPaegCQc6/XUPqBC9kDuPmDJrtCPp4CWt+6BuhNLb3eTrsBaXgoer5iwT4 2u++H3aaM65g2GHmfX76Nd0ZUPJfeerzhwG28ebunGmLu7fsYGC5NUmxRM7RArlYP2y8 T3uA== MIME-Version: 1.0 X-Received: by 10.112.166.66 with SMTP id ze2mr3972383lbb.68.1412940176195; Fri, 10 Oct 2014 04:22:56 -0700 (PDT) Received: by 10.25.24.159 with HTTP; Fri, 10 Oct 2014 04:22:56 -0700 (PDT) In-Reply-To: References: <1f48bd08112a4ef0a5c9497ea7bb726e@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> Date: Fri, 10 Oct 2014 14:22:56 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c347984a870105050fc504 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xQ4cPzvOMrAbBSvux50z6INDnkM Subject: Re: [Roll] Roll Status Pages 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, 10 Oct 2014 11:23:01 -0000 --001a11c347984a870105050fc504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Randy, Ticket #1496 was created following your suggestion [ https://tools.ietf.org/tools/ietfdb/ticket/1496] Best Regards, 2014-09-12 23:21 GMT+03:00 Turner, Randy : > > One of the features of RPL is that it can detect instabilities quickly > by including rank information with every packet sent =E2=80=93 I thought = 6553 was > how this is done=E2=80=A6seems more of a ROLL thing than a 6MAN thing in = that it=E2=80=99s > intimately tide to RPL =E2=80=94 Anyway, a link to these docs from the RO= LL page is > probably good enough=E2=80=A6 > > Thanks! > R. > > From: Ines Robles > Reply-To: "roll@ietf.org" > Date: Friday, September 12, 2014 at 4:16 PM > To: "roll@ietf.org" > Subject: Re: [Roll] Roll Status Pages > > Hi Randy, > > Thanks for your comments. > > The document was adopted at that time by 6man. [ > http://www.ietf.org/mail-archive/web/ipv6/current/msg11894.html] > > We will investigate if we can link in some way into the ROLL web page > RFCs such as 6553, 6554. > > Cheers, > > Ines > > > 2014-09-12 20:41 GMT+02:00 Turner, Randy : > >> >> >> I noticed that RFC 6553 is not in the list of documents on the Roll >> Status Page (tools.ietf.org/wg/roll/) >> >> >> >> Should this be added? >> >> >> >> Randy >> >> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. >> >> This e-mail (including any attachments) is confidential and may be >> legally privileged. If you are not an intended recipient or an authorize= d >> representative of an intended recipient, you are prohibited from using, >> copying or distributing the information in this e-mail or its attachment= s. >> If you have received this e-mail in error, please notify the sender >> immediately by return e-mail and delete all copies of this message and a= ny >> attachments. Thank you. >> >> _______________________________________________ >> 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 > > --001a11c347984a870105050fc504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Randy,

Ticket #1496 was created foll= owing your suggestion [https://tools.ietf.org/tools/ietfdb/ticket/1496]

=
Best Regards,



2014-09-12 23:21 GMT+03:00 Turne= r, Randy <Randy.Turner@landisgyr.com>:

One of the features of RPL is that it can detect instabilities quickly= by including rank information with every packet sent =E2=80=93 I thought 6= 553 was how this is done=E2=80=A6seems more of a ROLL thing than a 6MAN thi= ng in that it=E2=80=99s intimately tide to RPL =E2=80=94 Anyway, a link to these docs from the ROLL page is probably good enough=E2=80=A6

Thanks!
R.

From: Ines Robles <mariainesrobles@goog= lemail.com>
Reply-To: "roll@ietf.org" <roll@ietf.org>
Date: Friday, September 12, 2014 at= 4:16 PM
To: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] Roll Status Pag= es

Hi Randy,

Thanks for your comments.=C2=A0

The document was adopted at that time by 6man. [htt= p://www.ietf.org/mail-archive/web/ipv6/current/msg11894.html]

We will investigate if we can link in some way into the ROLL web page = RFCs such as 6553, 6554.

Cheers,

Ines


2014-09-12 20:41 GMT+02:00 Turner, Randy <Randy.T= urner@landisgyr.com>:

=C2=A0

I noticed that RFC 6553 is not in the list of docume= nts on the Roll Status Page (tools.ietf.org/wg/roll/)

=C2=A0

Should this be added?

=C2=A0

Randy


P PLEASE C= ONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confi= dential and may be legally privileged. If you are not an intended recipient= or an authorized representative of an intended recipient, you are prohibit= ed from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.


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

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


--001a11c347984a870105050fc504-- From nobody Fri Oct 10 06:43: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 80C0F1A1A0C for ; Fri, 10 Oct 2014 06:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Pvb1PyQA68Oi for ; Fri, 10 Oct 2014 06:43:20 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675961A03A4 for ; Fri, 10 Oct 2014 06:43:20 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so3125457lbg.0 for ; Fri, 10 Oct 2014 06:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oda2+o3B/SQd0FrwEd8lIP2CHcfe5NoA78WfmX2x4SE=; b=iSICWN7/kk3RedjK9uSmf+HwLsy8YUiMTtirdhcB+fEMre+Sw0UiqKZdPsuQf3C9nv s4glwO+mkw9jzWTDOki1ke4YLfDt4SwMo/Y4u3hiFKIvlVQgKdLkI+GGYOXK2etvZrBM g+nr/I4faso45ER6u+rGzi0nPEf0uaGI+7VuXPVXcdH4rIaNTYHkySMna6f9mfmlMqaT Wvcyh3h+AYIHKHNV5hfFdXN72j4PWhMZd66EkJ02c7AIID9Jb6bRtNIf3SJ/RfkxNOIH pZoAk5KwOdHeCsRi2Ri6/roZU/XtXnTbyKwdmZcWS6Cr8xhRJq9TQ4Wosf+RvtKHmPH8 7ybw== MIME-Version: 1.0 X-Received: by 10.112.147.39 with SMTP id th7mr4899228lbb.84.1412948595083; Fri, 10 Oct 2014 06:43:15 -0700 (PDT) Received: by 10.25.24.159 with HTTP; Fri, 10 Oct 2014 06:43:15 -0700 (PDT) Date: Fri, 10 Oct 2014 16:43:15 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=047d7b344202188efe050511bb12 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Wilg6FIbCf0FmZHF8_L3spYk77g Cc: Michael Richardson Subject: [Roll] Status on draft-ietf-roll-trickle-mcast 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, 10 Oct 2014 13:43:21 -0000 --047d7b344202188efe050511bb12 Content-Type: text/plain; charset=UTF-8 Dear all, We would like to let you know about draft-ietf-roll-trickle-mcast, we are working on get this work done. It is still going to take some time. We will keep you posted Best Regards, Michael and Ines --047d7b344202188efe050511bb12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

We would like to let yo= u know about draft-ietf-roll-trickle-mcast, we are working on get this work= done. It is still going to take some time.=C2=A0

= We will keep you posted

Best Regards,

Michael and Ines
--047d7b344202188efe050511bb12-- From nobody Fri Oct 10 12:22: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 0755B1ACE87 for ; Fri, 10 Oct 2014 12:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 D8GabdvAGPUT for ; Fri, 10 Oct 2014 12:22:33 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EDB1ACE53 for ; Fri, 10 Oct 2014 12:22:33 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0429.eurprd01.prod.exchangelabs.com (10.242.221.20) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 19:03:57 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 19:03:57 +0000 From: "Turner, Randy" To: "roll@ietf.org" Thread-Topic: multicast & MLD on LLN Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8A== Date: Fri, 10 Oct 2014 19:03:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [148.80.255.144] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0429; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(41574002)(120916001)(101416001)(16236675004)(229853001)(86362001)(2351001)(107046002)(107886001)(19625215002)(31966008)(54356999)(40100003)(95666004)(92566001)(19300405004)(76482002)(19580395003)(15975445006)(106356001)(50986999)(74316001)(4396001)(2656002)(87936001)(85852003)(99396003)(64706001)(66066001)(85306004)(105586002)(122556002)(110136001)(46102003)(33646002)(2501002)(80022003)(20776003)(21056001)(108616004)(15202345003)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0429; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_aef2e75903e84afe988ff58d04a0fc56DB4PR01MB0431eurprd01pr_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DIzMrcj5iMjdka8XvK0FVCoNnDE Subject: [Roll] multicast & MLD on LLN 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, 10 Oct 2014 19:22:36 -0000 --_000_aef2e75903e84afe988ff58d04a0fc56DB4PR01MB0431eurprd01pr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know there's a section on multicast in RFC 6550, which essentially states= that the equivalent of a multicast "join" would be a DAO packet specifying= multicast, rather than unicast addresses. It says that this method is not = to be relied on in a non-storing network - however, I'm assuming we can sti= ll use this if we implement just a "lightweight storing mode", keeping trac= k of only multicast addresses. In this case a multicast "leave" would be w= hen the DAO entry "times out" - does this behavior obviate the need for ML= D operation on this "quasi" storing mode LLN ? Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_aef2e75903e84afe988ff58d04a0fc56DB4PR01MB0431eurprd01pr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know there’s a section on multicast in RFC 6= 550, which essentially states that the equivalent of a multicast “joi= n” would be a DAO packet specifying multicast, rather than unicast ad= dresses. It says that this method is not to be relied on in a non-storing network – however, I’m assuming we can sti= ll use this if we implement just a “lightweight storing mode”, = keeping track of only multicast addresses.  In this case a multicast &= #8220;leave” would be when the DAO entry “times out” = ; - does this behavior obviate the need for MLD operation on this “quasi” storing mod= e LLN ?

 

Thanks!
Randy


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_aef2e75903e84afe988ff58d04a0fc56DB4PR01MB0431eurprd01pr_-- From nobody Fri Oct 10 14:32:10 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 8D7E61AD418; Fri, 10 Oct 2014 14:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 f5-hJdofgFme; Fri, 10 Oct 2014 14:32:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A29D31AD429; Fri, 10 Oct 2014 14:31:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010213156.17873.50974.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 14:31:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/UOiRsj2D9qPu_DkJFIP-5ZVXy9M Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)' to Informational RFC (draft-ietf-roll-security-threats-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: Fri, 10 Oct 2014 21:32:08 -0000 The IESG has approved the following document: - 'A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)' (draft-ietf-roll-security-threats-11.txt) as Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ Technical Summary This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. Working Group Summary: This document is based upon draft-ietf-roll-security-framework that stumbled during IESG review. It was agreed that the resolution of the IESG issues was to produce a new document in line with the ROLL WG work item: > Sep 2012: Submit first draft of RPL threat analysis to the IESG to be > considered as an Informational RFC The goal of this document is to outline threats with the expectation that applicability statements will have to cover (i.e. mitigate or solve) these threats in some way. Document Quality: The previous document (draft-ietf-roll-security-framework) on which this document is based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and Adrian Farrel, which ultimately contributed to the re-submission of this document. This document has had review from Stephen Kent and Sean Turner. Personnel: The Document Shepherd is Robert Cragie (robert.cragie@gridmerge.com) The responsible Area Director is Adrian Farrel (adrian@olddog.co.uk) From nobody Fri Oct 10 23:22:19 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 5DE861A1B06 for ; Fri, 10 Oct 2014 23:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 kDAkCw5s9lIC for ; Fri, 10 Oct 2014 23:22:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853AA1A1B01 for ; Fri, 10 Oct 2014 23:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7589; q=dns/txt; s=iport; t=1413008531; x=1414218131; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fHTMR68Fx9yHnR9ySkZ9EVx1eb+8c2LotX2+jB/f/EE=; b=A3yO+ZDC6hBRxG4xusLM7ACbLdd/+/RlNyu/m9tOcro34xz1VkksWk2k KwVKuGUWVCtbmqP+H9mJCJPvLsLep9F4OpZXFM6U5W2jJJt4trhuxkQOx iZDcNi7aijawwT1LchgqGbk1abICnG9H3GdzN4lJOJMf1jj+pPNWEB/lq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAGPLOFStJA2E/2dsb2JhbABggkhGU1jLMgEJh00CgQEWAXuEBAEBBAEBASpBCxACAQg/BycLFBECBA4FiD4Nv2cBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI9iEQElByAEBwKDK4EeBY9fghqLUoEug0aRHYN3bIEIBxcGgR4BAQE X-IronPort-AV: E=Sophos;i="5.04,697,1406592000"; d="scan'208,217";a="362416782" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2014 06:22:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9B6MAgW031904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 11 Oct 2014 06:22:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sat, 11 Oct 2014 01:22:10 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SA== Date: Sat, 11 Oct 2014 06:22:09 +0000 Message-ID: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B9D200B58B8423CADEAA6C61F73748Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-TiPZ3TUVWK3Ya_MC_06-WDmVY4 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 11 Oct 2014 06:22:17 -0000 --_000_6B9D200B58B8423CADEAA6C61F73748Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Randy... Great point! I think we need a draft, even if informational, to produce a clear explanat= ion of how that could work, extending the work I started on unicast with 67= 75reqs. The way I see it, MLD would make sense between a host that is not even a RP= L leaf and the 6LR. Arguably, we could probably extend NS ARO to get a simi= lar outcome to reduce the code footprint. Then the 6LR would turn that into= DAO. This is collapsed, as you point out, for RPL leaves and routers. We already= extended DAO to get a similar outcome as a recursive MLD proxy along a tre= e. The goal was to avoid MLD there; but then an I-D reviewed by multicast s= pecialists would validate that we missed no important point. I dug a bit and found some IPR that we need to sort out. Cisco has some tha= t mostly covers the BBR that turns the DAOs into MLD again, and for that mu= ch we can RAND if work starts. Finally I'm looking at BIER see how their ideas could apply to LLNs... Cheers, Pascal Le 10 oct. 2014 =E0 21:22, Turner, Randy > a =E9crit : I know there=92s a section on multicast in RFC 6550, which essentially stat= es that the equivalent of a multicast =93join=94 would be a DAO packet spec= ifying multicast, rather than unicast addresses. It says that this method i= s not to be relied on in a non-storing network =96 however, I=92m assuming = we can still use this if we implement just a =93lightweight storing mode=94= , keeping track of only multicast addresses. In this case a multicast =93l= eave=94 would be when the DAO entry =93times out=94 - does this behavior o= bviate the need for MLD operation on this =93quasi=94 storing mode LLN ? Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_6B9D200B58B8423CADEAA6C61F73748Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Randy...

Great point!

I think we need a draft, even if informational, to produce a clear exp= lanation of how that could work, extending the work I started on unicast wi= th 6775reqs.

The way I see it, MLD would make sense between a host that is not even= a RPL leaf and the 6LR. Arguably, we could probably extend NS ARO to get a= similar outcome to reduce the code footprint. Then the 6LR would turn that= into DAO.

This is collapsed, as you point out, for RPL leaves and routers. We al= ready extended DAO to get a similar outcome as a recursive MLD proxy along = a tree. The goal was to avoid MLD there; but then an I-D reviewed by multic= ast specialists would validate that we missed no important point. 

I dug a bit and found some IPR that we need to sort out. Cisco has som= e that mostly covers the BBR that turns the DAOs into MLD again, and for th= at much we can RAND if work starts.

Finally I'm looking at BIER see how their ideas could apply to LLNs...=

Cheers,

Pascal

Le 10 oct. 2014 =E0 21:22, Turner, Randy <Randy.Turner@landisgyr.com> a =E9crit :

I know there=92s a section on multicast in RFC 6550,= which essentially states that the equivalent of a multicast =93join=94 wou= ld be a DAO packet specifying multicast, rather than unicast addresses. It = says that this method is not to be relied on in a non-storing network =96 however, I=92m assuming we can still use t= his if we implement just a =93lightweight storing mode=94, keeping track of= only multicast addresses.  In this case a multicast =93leave=94 would= be when the DAO entry =93times out=94  - does this behavior obviate the need for MLD operation on this =93quasi=94 storing mode LLN ?<= o:p>

 

Thanks!
Randy


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ie= tf.org/mailman/listinfo/roll
--_000_6B9D200B58B8423CADEAA6C61F73748Bciscocom_-- From nobody Fri Oct 10 23:39: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 9DD4B1A1B1E for ; Fri, 10 Oct 2014 23:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM1r778qwMEI for ; Fri, 10 Oct 2014 23:39:51 -0700 (PDT) Received: from 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 1B42A1A1B1C for ; Fri, 10 Oct 2014 23:39:50 -0700 (PDT) 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 informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9B6didj014956; Sat, 11 Oct 2014 08:39:44 +0200 (CEST) Received: from [192.168.217.145] (p548906FD.dip0.t-ipconnect.de [84.137.6.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 04C76703; Sat, 11 Oct 2014 08:39:43 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> Date: Sat, 11 Oct 2014 08:39:41 +0200 X-Mao-Original-Outgoing-Id: 434702381.091821-ec86ce3461341937c205b2f56d1ff193 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3XZbSAvpfuLByEIyq39WE2pbkR8 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 11 Oct 2014 06:39:52 -0000 Right, MLD is a host-router protocol. Routers among them speak a routing protocol, so they wouldn=92t exchange = MLD. (A RPL =93leaf=94 is a router.) > Finally I'm looking at BIER see how their ideas could apply to LLNs=85 Yep. =20 We (TZI) have done (specified, implemented, analyzed) an efficient = BIER-like multicast forwarding protocol for non-storing mode a while = ago. Need to write that up in an I-D and submit it somewhere. BIER or ROLL or both? Gr=FC=DFe, Carsten From nobody Mon Oct 13 05:11: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 2D97F1A89E7 for ; Mon, 13 Oct 2014 05:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 L0NFJa-fPsZV for ; Mon, 13 Oct 2014 05:11:04 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8FA1A89EF for ; Mon, 13 Oct 2014 05:11:03 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so6273678lbv.38 for ; Mon, 13 Oct 2014 05:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5BAzWVELE9dETK4B+HBHt3YOT5M/QrH6TTmm8jKVA1A=; b=vPmaE887t+qMkzGLsttMNLoTlzaHJBC4GANvt5dqsS8jih9bmuHty6e3pn7cA7FqSf 0QmLWSnXo31yUd5lQvBVntLP2CE3VEFlBYmrZoGVkJFSvfYtJMaynq5Ve3oZIEmeyDNv vzSI35ENTVTsr7mPMpQeUsxFUnVrcqS/KJLqqucJgnBt9/BoZseRiWhqGnTU8qIaSfyY 73gOWUe9rgPxCuzEAvO4/UCWPgOZZcfYSl1cQM2bJrd2Vn/AeOeX2gOdCAKRX0c7VpBw 9wXCCHZREucwwRTkc9r6QuZI9b9EUZSMZEIq4swbjiCZEVm2WGmoCRyHHbgF9/wl1qYM DkLA== MIME-Version: 1.0 X-Received: by 10.152.36.130 with SMTP id q2mr24171306laj.42.1413202262506; Mon, 13 Oct 2014 05:11:02 -0700 (PDT) Received: by 10.25.24.159 with HTTP; Mon, 13 Oct 2014 05:11:02 -0700 (PDT) Date: Mon, 13 Oct 2014 15:11:02 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0158b5d2da427605054ccae6 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/vWBBR2XvWmZD1iuEr0c-hEScaFA Cc: Michael Richardson Subject: [Roll] WGLC for draft-ietf-roll-applicability-home-building 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, 13 Oct 2014 12:11:12 -0000 --089e0158b5d2da427605054ccae6 Content-Type: text/plain; charset=UTF-8 Dear all, To the authors, thanks for this new version of the draft. A Working Group Last call (WGLC) starts today (10/13) until 10/27/2014 for draft-ietf-roll-applicability-home-building. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-05 Please review this draft to see if you think it is ready for publication and send comments to the list stating your view. Thank you very much in advance, Michael and Ines. 2014-10-07 10:10 GMT+03:00 peter van der Stok : > 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 > --089e0158b5d2da427605054ccae6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= span style=3D"font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;wh= ite-space:pre-wrap;background-color:transparent">Dear all,


To the authors, thanks for = this new version of the draft.


A Working Group Last call (WGLC) starts today (10/13) u= ntil 10/27/2014 for draft-ietf-roll-applicability-home-building.

The draft is availab= le here:

https://datatracker.ietf.= org/doc/draft-ietf-roll-applicability-home-building/

http://tools.ietf.org/html/draft-ietf-roll-applicabilit= y-home-building-05


Please review this draft to see if you think it is ready for pu= blication and send comments to the list stating your view.


Thank you very much in adva= nce,


Michae= l and Ines.

2014-10-07 10:10 GMT+03:00 peter van der Stok <stokcons@xs4al= l.nl>:
Dear wg,

We submitted draft nr 5 of the home building applicability draft.
Major changes with respect to draft nr 4

=C2=A0 =C2=A0o=C2=A0 Large editing effort to streamline text

=C2=A0 =C2=A0o=C2=A0 Rearranged Normative and Informative references

=C2=A0 =C2=A0o=C2=A0 Replaced RFC2119 terminology by non-normative terminol= ogy

=C2=A0 =C2=A0o=C2=A0 Rearranged section 5 to better separate the subjects
=C2=A0 =C2=A0o=C2=A0 Rearranged text of section 7, 7.1, and 7.2 to agree wi= th the
=C2=A0 =C2=A0 =C2=A0 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
--089e0158b5d2da427605054ccae6-- From nobody Tue Oct 14 23:32:17 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 01D811A038D; Tue, 14 Oct 2014 23:32:16 -0700 (PDT) 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 TwWOEykfxOgU; Tue, 14 Oct 2014 23:32:14 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99211A0383; Tue, 14 Oct 2014 23:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2080; q=dns/txt; s=iport; t=1413354732; x=1414564332; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=UWg2SwqdGnb4tf0hwsVErBdWIZwVsmIbvRF/7jBwSOs=; b=hHyLf0KY9P5oQ4I4PuOlV85+ekhtUoPiwMULi7Y3vHD5ezWhF32NXEUw NwDSUK4nwiZNEUhKxgdA3YStj7D5fCC4cXlO8ntwHuFsCUj9pTjRiwXQH FvJY44gbDvImawsLghAHtKfhsdlyaoibvs9mqVH9UIbfBTXwlJbviGWcr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAPoTPlStJA2K/2dsb2JhbABBGoMOU1zMBYdLAoEWFgFyC4QEAQQdHT8SASoUQiYBBA4NiDYNN8csAQEBAQEBAQEBAQEBAQEBAQEBARUEjjeBQCYxgzSBHgWRfYREiEGDRogBiSGDd2wBBIECQYECAQEB X-IronPort-AV: E=Sophos;i="5.04,721,1406592000"; d="scan'208";a="87059632" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 15 Oct 2014 06:32:11 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9F6WBNU010768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 06:32:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 01:32:11 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Call to confirm a rough consensus on RPL info Thread-Index: Ac/oQa0i5HZn0oJrT3qpZBX3hHGwVA== Date: Wed, 15 Oct 2014 06:32:10 +0000 Deferred-Delivery: Wed, 15 Oct 2014 06:32:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HibclQmJdNfcLGgjCA4_sjygWsU Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks , "roll-chairs@tools.ietf.org" , "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: [Roll] Call to confirm a rough consensus on RPL info 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, 15 Oct 2014 06:32:16 -0000 Dear all:=20 During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices. We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.=20 Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible.=20 The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ). This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!). If the result is positive: - we plan to call for a 6lo WG doc adoption in Hawaii - we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC 6TiSCH may host the 6lo discussion so as to: - benefit from the early morning schedule - attract more 6TiSCH people to the discussion=20 More the published minutes:=20 - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7= df06694258a3ac65bfc519212f=20 - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex=20 - Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/sli= des_141010_webex.ppt Cheers, Pascal=20 From nobody Tue Oct 14 23:45:58 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 30AB51A038E; Tue, 14 Oct 2014 23:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpOcoYKMoROh; Tue, 14 Oct 2014 23:45:54 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185711A038D; Tue, 14 Oct 2014 23:45:54 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id uq10so19315106igb.4 for ; Tue, 14 Oct 2014 23:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G/sBC0kzsgGAanPBnvcc8rlB+0+AodoB/1ZOk143Gz4=; b=Y1KG8oqK5K6b46jaz43RG8M9hX3NsKimAh/rTIMDFgXDdxYEH+0iTQi7gphgnyf7XI 9ukBKahdrP/aUCjkFWJbmh3XzKLReLhsRcL6ZnlkKdtUr+4qCxbewAX9ZmuJ3RVQLqLI 7p8LfgabMcASf71zXrr4aHifJ8DUjVuB8edws4Xdfxb6RkClD7JWSZEX05wx3CvDEGR4 7ZDfB5js/BHjzbgwG+7BrcDHeHBG76tloQjMhoE/wRPbwUygl79HS2/bK7voTTFeLvv0 dq/GAKBEYsa8dOVrT55Pf2Jpn7xeUH7OGLsvS2ctWh0vM3e+9o/KU2rb3q6ECky5tNAl 15Iw== MIME-Version: 1.0 X-Received: by 10.50.39.80 with SMTP id n16mr11736962igk.49.1413355553433; Tue, 14 Oct 2014 23:45:53 -0700 (PDT) Sender: xvilajosana@gmail.com Received: by 10.64.13.142 with HTTP; Tue, 14 Oct 2014 23:45:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 08:45:53 +0200 X-Google-Sender-Auth: z0iDr1Ia7ifqHTne8WXOEwvfqeQ Message-ID: From: Xavier Vilajosana To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8f83a259b42e6b0505707be5 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pTVxyZ62M2SKfMh-4_5cnD3Ugr4 Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "roll-chairs@tools.ietf.org" Subject: Re: [Roll] Call to confirm a rough consensus on RPL info 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, 15 Oct 2014 06:45:56 -0000 --e89a8f83a259b42e6b0505707be5 Content-Type: text/plain; charset=UTF-8 All, I fully support that approach. Hope to contribute and make it happen as soon as possible. regards, Xavi 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) : > Dear all: > > During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the > minimal I-D (draft-ietf-6tisch-minimal) must indicate the compression > method for the RPL Information (see RFC 6553), so as to ensure > interoperation between 6TiSCH devices. > > We discussed our options, basically either a 6lo approach or a Flow Label > approach. The rough consensus at the call was to try and focus on a 6lo > approach and evaluate where that leads us. > > Because this means that the minimal draft will have a normative reference > on a WIP I-D, we recognized that this approach may delay the publication of > the final RFC. Per IETF procedures, the minimal draft will be stalled in > the RFC editor queue in MISREF state until the 6lo work completes. So the > consensus was also to support the 6lo work so as to expedite it as much as > possible. > > The idea would be to republish a standard track draft-ietf-6lo- ASAP, > based on the existing proposals (which are rapidly converging); then, Xavi > would include a normative reference to that work in the minimal I-D before > its publication to IESG, which is scheduled in November (yes, this is > aggressive). > > This is a call to confirm the rough consensus on the ML, open till the > next interim call on October 24th. Please provide us with any relevant > comment (and participate to the 6lo discussions in the meantime!). > > If the result is positive: > - we plan to call for a 6lo WG doc adoption in Hawaii > - we are looking for an aggressive schedule to limit the impact on the > publication of the minimal RFC > > 6TiSCH may host the 6lo discussion so as to: > - benefit from the early morning schedule > - attract more 6TiSCH people to the discussion > > More the published minutes: > - Webex recording: > https://cisco.webex.com/ciscosales/lsr.php?RCID=36a3b7df06694258a3ac65bfc519212f > - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex > - Slides: > https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010_webex.ppt > > Cheers, > > Pascal > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --e89a8f83a259b42e6b0505707be5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I fully support that approach. Hop= e to contribute and make it happen as soon as possible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) <pth= ubert@cisco.com>:
Dear all= :

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webe= x.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex<= /a>
- Slides: https://bitbucket.org/6t= isch/meetings/src/master/141010_webex/slides_141010_webex.ppt

Cheers,

Pascal

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

--e89a8f83a259b42e6b0505707be5-- From nobody Wed Oct 15 00:52: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 EB5A71A0406; Wed, 15 Oct 2014 00:52:11 -0700 (PDT) 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 FfPvw1EyWJKu; Wed, 15 Oct 2014 00:52:10 -0700 (PDT) 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 1FF611A03E3; Wed, 15 Oct 2014 00:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4815; q=dns/txt; s=iport; t=1413359530; x=1414569130; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=z+adEob4/aLoVd0Gy/EVPJBqH60k2AnDRYcOc/rt4v8=; b=P8AH0kENeEwupIhZuSK1rZPMENVdQqzRIAIdXhW5bD/8BneW+jNEpugY BubgTaT6q4IFPya3SGcRpGEagszHTNa2Gxg878eazk+o0AWO68IY2eYiU gBIqCTrlaN1WJjKAM31Vdroiv9PnPWjSDtWqyVC561EVuM0xmWJV1l/aE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4GADQnPlStJA2K/2dsb2JhbABbgw5TUwnLbQqHTQKBFhYBcguEAgEBAQQBAQEaUQsMBgEZBAEBAQodLgsUCQkBBA4FCAESiCMIBcdpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF40MgmoHAQEeLAUCC4MngR4FiyGGXIREiEE8gwqRIoN3bAGBBQkXIoECAQEB X-IronPort-AV: E=Sophos;i="5.04,722,1406592000"; d="scan'208";a="87090006" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 15 Oct 2014 07:52:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9F7q9q5023357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 07:52:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 02:52:08 -0500 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: Call for advice on the RFC 6553 6lo encoding Thread-Index: Ac/oTMMw7ub/rsbHQfSqGvx7Gr6DYQ== Date: Wed, 15 Oct 2014 07:52:07 +0000 Deferred-Delivery: Wed, 15 Oct 2014 07:52:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.103] 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/fhfrAnMFXprhqUwjWxaEExlyMt4 Cc: Michael Richardson , Routing Over Low power and Lossy networks , "Ralph Droms \(rdroms\)" , Samita Chakrabarti , "6tisch@ietf.org" <6tisch@ietf.org> Subject: [Roll] Call for advice on the RFC 6553 6lo encoding 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, 15 Oct 2014 07:52:12 -0000 Dear all, I'm attaching below a mail from Carsten which summarizes the only point of = contention that we still have in our discussion on how to compress the RPL = Information in 6lo. As Carsten explains below, we need advice from the list= on which approach we should be taking, and we are now calling for advice. There are basically 2 approaches: a) Greedy. RPL would consume a high code in the NHC space, which can be int= erpreted as 1/4 of its addressing capability. This would be leaving more th= an half available for future use. b) Conservative. RPL would only consume a very limited NHC space, at the ex= pense of one extra octet in each packet. We have to choose between protecting resources now (frame size, energy) or = in the future (NHC encodingspace): a) optimizes for today's RPL-routed data packets at a time when frame size = is a major issue, mostly with 802.15.4-2006 and ultra-low-speed networks (P= LC, LPWA). b) optimizes for a future when we deploy new services and routing protocols= in LLNs, which will require new IPv6 options headers, and the space left i= n the NHC encoding becomes an issue. Please help us and post advice, indicating whether you favor a) greedy or b= ) conservative, and for which technical reason. We need to extract an initial consensus and publish a proposed solution I-d= raft by the cut-off on the 27, preferably earlier than that.=20 Thanks a bunch in advance, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: mercredi 15 octobre 2014 09:23 > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; Samita Chakrabarti; Ralph Droms (rdroms); > 6lo@ietf.org > Subject: Re: [6lo] Call for Agenda items (IETF91) >=20 > Hi Pascal, >=20 > as I said previously [1], I wrote my version of the draft both to focus o= n the > solution that we actually need to standardize and to reduce the codepoint > footprint. There certainly is no point in having two drafts here, so I'm= ready > to merge. The "executive summary" of the open technical question is: >=20 > 1) > Are we ready to allocate 1/4 of the NHC code space to RFC 6553 compressio= n > (knowing that RFC 6554 compression is the next thing we probably want to > tackle)? >=20 > 2) > And, if we aren't ready to do this, is the "escape code" approach of my d= raft > [2] the right one to be more skimpy on code point space? >=20 >=20 > Gr=FC=DFe, Carsten >=20 > [1] https://www.ietf.org/mail-archive/web/6lo/current/msg00693.html > [2] http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02 >=20 > On 15 Oct 2014, at 08:41, Pascal Thubert (pthubert) > wrote: >=20 > > Hello Carsten and Laurent: > > > > I'm happy that we are rapidly converging. Certainly, our great progress > helped a lot the call we are making at 6TiSCH to focus on a 6lo-based > approach. > > > > My quick reading is that the differences are now very minor. I think we= are > ready to document them as an executive summary, and ask for a feedback > on the ML. If we do so rapidly, we may be able to publish a common > document that would focus on the solution, so as to call for adoption in > Hawaii. > > > > Does that work? > > > > Pascal > > > > > >> -----Original Message----- > >> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Carsten Bormann > >> Sent: dimanche 12 octobre 2014 15:19 > >> To: Michael Richardson > >> Cc: Samita Chakrabarti; 6lo@ietf.org; Ralph Droms (rdroms) > >> Subject: Re: [6lo] Call for Agenda items (IETF91) > >> > >> On 11 Oct 2014, at 23:23, Michael Richardson > >> wrote: > >> > >>> A compression mechanism for the RPL option > >>> draft-thubert-6lo-rpl-nhc-01 > >> > >> To make this discussion more interesting, I just submitted my version > >> of this draft as > >> > >> draft-bormann-6lo-rpl-mesh-02 > >> > >> Htmlized: http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-= 02 > >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lo-r= pl-mesh- > 02 > >> > >> This is slightly less efficient for common cases than > >> draft-bormann-6lo-rpl- > >> mesh-01 was, but makes use of the NHC idea in draft-thubert-6lo-rpl-nh= c- > 01. > >> The main reason I am submitting this is to avoid the extensive > >> consumption of NHC code points that is proposed by draft-thubert-6lo- > rpl-nhc-01. > >> > >> Gr=FC=DFe, Carsten > >> > >> _______________________________________________ > >> 6lo mailing list > >> 6lo@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lo > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo > > > > From nobody Wed Oct 15 00:59: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 3D94F1A0410; Wed, 15 Oct 2014 00:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89zTj2Zyfc-j; Wed, 15 Oct 2014 00:59:36 -0700 (PDT) Received: from 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 0ECCB1A0406; Wed, 15 Oct 2014 00:59:35 -0700 (PDT) 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 informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9F7xTUs015928; Wed, 15 Oct 2014 09:59:29 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9C7B22EF; Wed, 15 Oct 2014 09:59:28 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Oct 2014 09:59:26 +0200 X-Mao-Original-Outgoing-Id: 435052766.590471-204eef7c324752f9968f79ca199f6e52 Content-Transfer-Encoding: quoted-printable Message-Id: <2463B5D0-C7DB-41DB-8F85-089C1EF08E2F@tzi.org> References: To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rR3EhAmkjGTNh_XOQPK69cE1RHc Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Call for advice on the RFC 6553 6lo encoding 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, 15 Oct 2014 07:59:37 -0000 On 15 Oct 2014, at 09:52, Pascal Thubert (pthubert) = wrote: > b) Conservative. RPL would only consume a very limited NHC space, at = the expense of one extra octet in each packet. No, that=92s not how it [1] works. There is no extra byte except if the R or F flags in the RPL Packet = Information (RPI) are non-zero. It appears to me that those flags are an infrequent occurrence, so the = total expense in bytes sent should be near zero. There *is* expense in = code size (complexity), though. I have not been able to obtain any real world numbers on the frequency = of non-zero R bits in real life RPL traffic. (I have no idea whether non-zero F bits actually exist in real life at = all.) Those would be questions that people with more RPL experience than I = have can answer. Gr=FC=DFe, Carsten [1] http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02 From nobody Wed Oct 15 01:40:51 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 E05E21A19E7; Wed, 15 Oct 2014 01:40:49 -0700 (PDT) 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 QYkuZ2xZxYJ0; Wed, 15 Oct 2014 01:40:48 -0700 (PDT) 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 61D0B1A19ED; Wed, 15 Oct 2014 01:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1974; q=dns/txt; s=iport; t=1413362448; x=1414572048; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Smi0vjiMvZO8OUq7sE3IB2fkSqCe4HHLVC9mUUOH4yE=; b=UDXaF9NJXXU/xZovmiSKX3yIuFiK2uOl+EgDSn+E/W9yTxmPUhtDvTH2 cAbLR3GSvGUPlV8NKFl2ysb1WQPmhVwdCbs9hB6goDC1FhpLQJ9qpB/hP rQwTUhGG32/HMB4KFfj9fFhXQ7C9IQsmm/0HynHgZciFMrVGccX6GkHCH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHMyPlStJV2T/2dsb2JhbABbgw5TXMt4h00CgRYWAX2EAgEBAQQOD0gUDAQCAQgOAwQBAQEKHQcyFAkIAgQOBQgRAogjDcd1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF40MgmoKHTEHBoMngR4FiyGGXIREiEE8kC6DfoF+IIFZbIEGQoECAQEB X-IronPort-AV: E=Sophos;i="5.04,722,1406592000"; d="scan'208";a="87051391" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 15 Oct 2014 08:40:44 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9F8eiMB013517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 08:40:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 03:40:44 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [6lo] Call for advice on the RFC 6553 6lo encoding Thread-Index: AQHP6E32JyW5QHhusk2y3j3oyyqBgpww0yNw Date: Wed, 15 Oct 2014 08:40:43 +0000 Deferred-Delivery: Wed, 15 Oct 2014 08:40:00 +0000 Message-ID: References: <2463B5D0-C7DB-41DB-8F85-089C1EF08E2F@tzi.org> In-Reply-To: <2463B5D0-C7DB-41DB-8F85-089C1EF08E2F@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.103] 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/YoXCmke5xm0lvLr2LFSe4fTBeoo Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Call for advice on the RFC 6553 6lo encoding 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, 15 Oct 2014 08:40:50 -0000 Hello Carsten: At this moment, we can guarantee that a) and b) as presented are generally = doable. This is why I called on that. People might think that b) is accepta= ble as presented anyway. You are suggesting here that the extra byte in b) may apply only to some pa= ckets, but we do not have a consensus that your specific solution is accept= able and I have my own string doubts because of the way RPL uses those bits= . We can discuss this on another thread, but I'd wish to keep this call very = abstract on 2 general approaches as opposed to draft-pascal vs. draft-carst= en to get the rough balance of people's minds, greedy, or conservative. Cheers, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: mercredi 15 octobre 2014 09:59 > To: Pascal Thubert (pthubert) > Cc: 6lo@ietf.org; Routing Over Low power and Lossy networks; > 6tisch@ietf.org > Subject: Re: [6lo] Call for advice on the RFC 6553 6lo encoding >=20 > On 15 Oct 2014, at 09:52, Pascal Thubert (pthubert) > wrote: >=20 > > b) Conservative. RPL would only consume a very limited NHC space, at th= e > expense of one extra octet in each packet. >=20 > No, that's not how it [1] works. >=20 > There is no extra byte except if the R or F flags in the RPL Packet Infor= mation > (RPI) are non-zero. >=20 > It appears to me that those flags are an infrequent occurrence, so the to= tal > expense in bytes sent should be near zero. There *is* expense in code si= ze > (complexity), though. >=20 > I have not been able to obtain any real world numbers on the frequency of > non-zero R bits in real life RPL traffic. > (I have no idea whether non-zero F bits actually exist in real life at al= l.) Those > would be questions that people with more RPL experience than I have can > answer. >=20 > Gr=FC=DFe, Carsten >=20 > [1] http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02 From nobody Wed Oct 15 02:55:17 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 495441A017A; Wed, 15 Oct 2014 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtJs2dx3pvxn; Wed, 15 Oct 2014 02:55:04 -0700 (PDT) Received: from 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 B6AB61A1A04; Wed, 15 Oct 2014 02:55:03 -0700 (PDT) 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 informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9F9sx3M012228; Wed, 15 Oct 2014 11:54:59 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C8546455; Wed, 15 Oct 2014 11:54:58 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Oct 2014 11:54:58 +0200 X-Mao-Original-Outgoing-Id: 435059698.336467-94642d3bde4d95641af253639987e760 Content-Transfer-Encoding: quoted-printable Message-Id: <7E87BDDD-A8FC-45A3-A0F5-57066CF48821@tzi.org> References: <2463B5D0-C7DB-41DB-8F85-089C1EF08E2F@tzi.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AK1djKdFEqZzlBy22raoRrHbL3o Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] [6lo] Call for advice on the RFC 6553 6lo encoding 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, 15 Oct 2014 09:55:05 -0000 On 15 Oct 2014, at 10:40, Pascal Thubert (pthubert) = wrote: > You are suggesting here that the extra byte in b) may apply only to = some packets, That=92s not a suggestion but simply how I designed it, in order to free = up the bits without increasing the packet sizes. > but we do not have a consensus that your specific solution is = acceptable We need to have this discussion now then. My proposal is sensible only = if that is the case. > and I have my own string doubts because of the way RPL uses those = bits. Please put those on the table=85 Gr=FC=DFe, Carsten From nobody Wed Oct 15 07:54: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 252251A1B20 for ; Wed, 15 Oct 2014 07:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml9qGkrGAyOZ for ; Wed, 15 Oct 2014 07:54:27 -0700 (PDT) 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 15FF41A872F for ; Wed, 15 Oct 2014 07:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13481; q=dns/txt; s=iport; t=1413384867; x=1414594467; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ruvQMt8/BpFhWAcQ6ypIzAB2OOkQ0o7sOdXgaUdsZ4o=; b=XZnEtJHWWvb8eQGMnUQMPFz+azIUW+F1OoQxzpizKfSV4LxRTGhk6oCn 1qso287icbm9oVXd9POL3H9GZHtBpiUcSIUre8HLrKhW8tRDZNYHyPkIG xIQ8ccXffejZuj4xIvsHTSSqiFcRdG8bsPNrvhrXPZrd2XABp7rdmgnjz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKOJPlStJA2N/2dsb2JhbABbgkhGU1gEy3UBCYdNAoEUFgF9hAIBAQEEAQEBKkELEAIBCBEEAQELHQcnCxQJCAIEDgUIiDYNyDoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpPhR0RAQIdBgcgBAYBAgSDJ4EeBYsjhECCHI0Fg0aRJIN3bIEIBxcGHIECAQEB X-IronPort-AV: E=Sophos; i="5.04,724,1406592000"; d="scan'208,217"; a="87200426" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 15 Oct 2014 14:54:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9FEsPoL030412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 14:54:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 09:54:25 -0500 From: "Pascal Thubert (pthubert)" To: "Turner, Randy (Randy.Turner@landisgyr.com)" Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxmTnQ Date: Wed, 15 Oct 2014 14:54:25 +0000 Deferred-Delivery: Wed, 15 Oct 2014 14:54:00 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> In-Reply-To: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.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.52] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842E1C040xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Hpb9bxeqItyN7KNCA7I7wdAwRmI Cc: "Greg Shepherd \(shep\)" , Routing Over Low power and Lossy networks , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 14:54:34 -0000 --_000_E045AECD98228444A58C61C200AE1BD842E1C040xmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello again Randy: We had a talk with Greg and Ice, and it seems to me that the BIER approach = could be perfectly applicable to a RPL LLN, mostly for small multicast pack= ets or on a PHY that is not too sensitive to the encapsulation such as 15.4= G. Basically for us, the method would leverage the backbone router to assign a= bitmap that represents the listeners in a DODAG. If we encode the BIER bit= map in an IPv6 address, that would mean at most about 100 listeners per DOD= AG. And then we can build multiple RPL instances if we need more than that. Do you have a use case that would require multicast? If so, would you care = to tell us a bit more, or, better, contribute some text to the use case doc= ument? If you are in Hawaii, BIER will be on the first PM slot on Monday, right be= fore DETNET. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: samedi 11 octobre 2014 08:22 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN Hello Randy... Great point! I think we need a draft, even if informational, to produce a clear explanat= ion of how that could work, extending the work I started on unicast with 67= 75reqs. The way I see it, MLD would make sense between a host that is not even a RP= L leaf and the 6LR. Arguably, we could probably extend NS ARO to get a simi= lar outcome to reduce the code footprint. Then the 6LR would turn that into= DAO. This is collapsed, as you point out, for RPL leaves and routers. We already= extended DAO to get a similar outcome as a recursive MLD proxy along a tre= e. The goal was to avoid MLD there; but then an I-D reviewed by multicast s= pecialists would validate that we missed no important point. I dug a bit and found some IPR that we need to sort out. Cisco has some tha= t mostly covers the BBR that turns the DAOs into MLD again, and for that mu= ch we can RAND if work starts. Finally I'm looking at BIER see how their ideas could apply to LLNs... Cheers, Pascal Le 10 oct. 2014 =E0 21:22, Turner, Randy > a =E9crit : I know there's a section on multicast in RFC 6550, which essentially states= that the equivalent of a multicast "join" would be a DAO packet specifying= multicast, rather than unicast addresses. It says that this method is not = to be relied on in a non-storing network - however, I'm assuming we can sti= ll use this if we implement just a "lightweight storing mode", keeping trac= k of only multicast addresses. In this case a multicast "leave" would be w= hen the DAO entry "times out" - does this behavior obviate the need for ML= D operation on this "quasi" storing mode LLN ? Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD842E1C040xmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello again Randy:

 

We had a talk with Gre= g and Ice, and it seems to me that the BIER approach could be perfectly app= licable to a RPL LLN, mostly for small multicast packets or on a PHY that i= s not too sensitive to the encapsulation such as 15.4G.

 

Basically for us, the = method would leverage the backbone router to assign a bitmap that represent= s the listeners in a DODAG. If we encode the BIER bitmap in an IPv6 address= , that would mean at most about 100 listeners per DODAG. And then we can build multiple RPL instances if we ne= ed more than that.

 

Do you have a use case= that would require multicast? If so, would you care to tell us a bit more,= or, better, contribute some text to the use case document?

 

If you are in Hawaii, = BIER will be on the first PM slot on Monday, right before DETNET.

Cheers,

 = ;

Pascal

 

From: Roll [ma= ilto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: samedi 11 octobre 2014 08:22
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

 

Hello Randy...

 

Great point!

 

I think we need a draft, even if informational, to p= roduce a clear explanation of how that could work, extending the work I sta= rted on unicast with 6775reqs.

 

The way I see it, MLD would make sense between a hos= t that is not even a RPL leaf and the 6LR. Arguably, we could probably exte= nd NS ARO to get a similar outcome to reduce the code footprint. Then the 6= LR would turn that into DAO.

 

This is collapsed, as you point out, for RPL leaves = and routers. We already extended DAO to get a similar outcome as a recursiv= e MLD proxy along a tree. The goal was to avoid MLD there; but then an I-D = reviewed by multicast specialists would validate that we missed no important point. 

 

I dug a bit and found some IPR that we need to sort = out. Cisco has some that mostly covers the BBR that turns the DAOs into MLD= again, and for that much we can RAND if work starts.

 

Finally I'm looking at BIER see how their ideas coul= d apply to LLNs...

 

Cheers,

Pascal


Le 10 oct. 2014 =E0 21:22, Turner, Randy <Randy.Turner@landisgyr.com> a =E9crit :

I know there’s a section on multicast in RFC 6= 550, which essentially states that the equivalent of a multicast “joi= n” would be a DAO packet specifying multicast, rather than unicast ad= dresses. It says that this method is not to be relied on in a non-storing network – however, I’m assuming we can sti= ll use this if we implement just a “lightweight storing mode”, = keeping track of only multicast addresses.  In this case a multicast &= #8220;leave” would be when the DAO entry “times out” = ; - does this behavior obviate the need for MLD operation on this “quasi” storing mod= e LLN ?

 

Thanks!
Randy

 

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) = is confidential and may be legally privileged. If you are not an intended r= ecipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you.

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

--_000_E045AECD98228444A58C61C200AE1BD842E1C040xmbrcdx01ciscoc_-- From nobody Wed Oct 15 08:14:44 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 213591A86F4 for ; Wed, 15 Oct 2014 08:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 u0XaEpC0MmHP for ; Wed, 15 Oct 2014 08:14:29 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::705]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93911A86FA for ; Wed, 15 Oct 2014 08:14:27 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 15:01:51 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 15:01:51 +0000 From: "Turner, Randy" To: "Pascal Thubert (pthubert)" Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8AAX0deAANsOb4AAAEKRIw== Date: Wed, 15 Oct 2014 15:01:51 +0000 Message-ID: <9F844C43-F0EA-4B8F-8E63-2506BE341C3D@landisgyr.com> References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [70.192.133.237] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(24454002)(41574002)(31966008)(36756003)(97736003)(19580395003)(19580405001)(82746002)(15975445006)(21056001)(80022003)(83716003)(20776003)(64706001)(87936001)(85306004)(66066001)(2656002)(19625215002)(105586002)(106356001)(76176999)(50986999)(54356999)(40100003)(110136001)(107046002)(122556002)(92726001)(86362001)(101416001)(85852003)(92566001)(33656002)(4396001)(120916001)(95666004)(46102003)(16236675004)(19617315012)(76482002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9F844C43F0EA4B8F8E632506BE341C3Dlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/osmbNDaujUyakzUOXpQpI3BTUl8 Cc: "Greg Shepherd \(shep\)" , Routing Over Low power and Lossy networks , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 15:14:35 -0000 --_000_9F844C43F0EA4B8F8E632506BE341C3Dlandisgyrcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will be in Hawaii Thanks Pascal!! Randy Sent from my iPhone On Oct 15, 2014, at 4:55 PM, Pascal Thubert (pthubert) > wrote: Hello again Randy: We had a talk with Greg and Ice, and it seems to me that the BIER approach = could be perfectly applicable to a RPL LLN, mostly for small multicast pack= ets or on a PHY that is not too sensitive to the encapsulation such as 15.4= G. Basically for us, the method would leverage the backbone router to assign a= bitmap that represents the listeners in a DODAG. If we encode the BIER bit= map in an IPv6 address, that would mean at most about 100 listeners per DOD= AG. And then we can build multiple RPL instances if we need more than that. Do you have a use case that would require multicast? If so, would you care = to tell us a bit more, or, better, contribute some text to the use case doc= ument? If you are in Hawaii, BIER will be on the first PM slot on Monday, right be= fore DETNET. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: samedi 11 octobre 2014 08:22 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN Hello Randy... Great point! I think we need a draft, even if informational, to produce a clear explanat= ion of how that could work, extending the work I started on unicast with 67= 75reqs. The way I see it, MLD would make sense between a host that is not even a RP= L leaf and the 6LR. Arguably, we could probably extend NS ARO to get a simi= lar outcome to reduce the code footprint. Then the 6LR would turn that into= DAO. This is collapsed, as you point out, for RPL leaves and routers. We already= extended DAO to get a similar outcome as a recursive MLD proxy along a tre= e. The goal was to avoid MLD there; but then an I-D reviewed by multicast s= pecialists would validate that we missed no important point. I dug a bit and found some IPR that we need to sort out. Cisco has some tha= t mostly covers the BBR that turns the DAOs into MLD again, and for that mu= ch we can RAND if work starts. Finally I'm looking at BIER see how their ideas could apply to LLNs... Cheers, Pascal Le 10 oct. 2014 ? 21:22, Turner, Randy > a ?crit : I know there's a section on multicast in RFC 6550, which essentially states= that the equivalent of a multicast "join" would be a DAO packet specifying= multicast, rather than unicast addresses. It says that this method is not = to be relied on in a non-storing network - however, I'm assuming we can sti= ll use this if we implement just a "lightweight storing mode", keeping trac= k of only multicast addresses. In this case a multicast "leave" would be w= hen the DAO entry "times out" - does this behavior obviate the need for ML= D operation on this "quasi" storing mode LLN ? Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_9F844C43F0EA4B8F8E632506BE341C3Dlandisgyrcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will be in Hawaii

Thanks Pascal!!

Randy

Sent from my iPhone

On Oct 15, 2014, at 4:55 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Hello again Randy:

 

We had a talk with Gre= g and Ice, and it seems to me that the BIER approach could be perfectly app= licable to a RPL LLN, mostly for small multicast packets or on a PHY that i= s not too sensitive to the encapsulation such as 15.4G.

 

Basically for us, the = method would leverage the backbone router to assign a bitmap that represent= s the listeners in a DODAG. If we encode the BIER bitmap in an IPv6 address= , that would mean at most about 100 listeners per DODAG. And then we can build multiple RPL instances if we ne= ed more than that.

 

Do you have a use case= that would require multicast? If so, would you care to tell us a bit more,= or, better, contribute some text to the use case document?

 

If you are in Hawaii, = BIER will be on the first PM slot on Monday, right before DETNET.

Cheers,

 = ;

Pascal

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: samedi 11 octobre 2014 08:22
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

 

Hello Randy...

 

Great point!

 

I think we need a draft, even if informational, to p= roduce a clear explanation of how that could work, extending the work I sta= rted on unicast with 6775reqs.

 

The way I see it, MLD would make sense between a hos= t that is not even a RPL leaf and the 6LR. Arguably, we could probably exte= nd NS ARO to get a similar outcome to reduce the code footprint. Then the 6= LR would turn that into DAO.

 

This is collapsed, as you point out, for RPL leaves = and routers. We already extended DAO to get a similar outcome as a recursiv= e MLD proxy along a tree. The goal was to avoid MLD there; but then an I-D = reviewed by multicast specialists would validate that we missed no important point. 

 

I dug a bit and found some IPR that we need to sort = out. Cisco has some that mostly covers the BBR that turns the DAOs into MLD= again, and for that much we can RAND if work starts.

 

Finally I'm looking at BIER see how their ideas coul= d apply to LLNs...

 

Cheers,

Pascal


Le 10 oct. 2014 à 21:22, Turner, Randy <Randy.Turner@landisgyr.com> a écrit = ;:

I know there’s a section on multicast in RFC 6= 550, which essentially states that the equivalent of a multicast “joi= n” would be a DAO packet specifying multicast, rather than unicast ad= dresses. It says that this method is not to be relied on in a non-storing network – however, I’m assuming we can sti= ll use this if we implement just a “lightweight storing mode”, = keeping track of only multicast addresses.  In this case a multicast &= #8220;leave” would be when the DAO entry “times out” = ; - does this behavior obviate the need for MLD operation on this “quasi” storing mod= e LLN ?

 

Thanks!
Randy

 

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) = is confidential and may be legally privileged. If you are not an intended r= ecipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you.

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

--_000_9F844C43F0EA4B8F8E632506BE341C3Dlandisgyrcom_-- From nobody Wed Oct 15 08:51: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 055F71A888D for ; Wed, 15 Oct 2014 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 438VtnnsrUUi for ; Wed, 15 Oct 2014 08:51:34 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78501A887E for ; Wed, 15 Oct 2014 08:51:33 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id vb8so1263881obc.31 for ; Wed, 15 Oct 2014 08:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zwAghdG9mbIyjBIjBQF0/OuCjgSJ5LM4wxYDFy42RlQ=; b=Vr2zmASYNO5HpxOQ+UzV/80SsWklQtSo+7mk2tlI1YS0JPtotuM4hiQ2Epb6vc4qos 8f+oJaqdzpvMNLC5AtA7V2Bgcrx+yttrGLUGMx2xDRlsF9Y4jZmNn3pDG/ofnK6UJ65H Fn55HmOJGKLVosxU1+Rdnk1UauK1dsz5r7Ub0GHq6FKs601c3tJYOiAtIBfbxSJVMJbm gTCW4/5TYNjtIHYR7/iNwM4po33jGEcxUjZlX6KM6GlUImyPCoVlrDMNTbCb05jhlrhp 7S7XNZUv20oS+48M3oiha7532OBABTME4eGh/+4pPgDNyFhTuiVl6gDWAoFqblWxZbmh slJw== MIME-Version: 1.0 X-Received: by 10.182.163.33 with SMTP id yf1mr11778589obb.0.1413388293223; Wed, 15 Oct 2014 08:51:33 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.15.129 with HTTP; Wed, 15 Oct 2014 08:51:33 -0700 (PDT) In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> Date: Wed, 15 Oct 2014 11:51:33 -0400 X-Google-Sender-Auth: Md4_7TOXUDCmoWx1-zz6Nt4JB70 Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8f64272825b9760505781b05 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/w4XSrHjywHk1SGZxyk3dvVtQi2o Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 15:51:35 -0000 --e89a8f64272825b9760505781b05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pascal, Carsten, et al. On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann wrote: > Right, MLD is a host-router protocol. > Routers among them speak a routing protocol, so they wouldn=E2=80=99t exc= hange MLD. > (A RPL =E2=80=9Cleaf=E2=80=9D is a router.) > > > Finally I'm looking at BIER see how their ideas could apply to LLNs=E2= =80=A6 > > Yep. > We (TZI) have done (specified, implemented, analyzed) an efficient > BIER-like multicast forwarding protocol for non-storing mode a while ago. > I admit to some confusion here. Is (topology-free) MPL no longer the default multicast forwarding protocol for LLN? > Need to write that up in an I-D and submit it somewhere. > BIER or ROLL or both? > > I thought the goal was to shut down (or is it re-charter) ROLL? If we're considering new approaches to multicast forwarding, that may be reason enough to re-charter ROLL. -K- > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --e89a8f64272825b9760505781b05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pascal, Carsten, et al.

On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann <cabo@t= zi.org> wrote:
Right, MLD i= s a host-router protocol.
Routers among them speak a routing protocol, so they wouldn=E2=80=99t excha= nge MLD.
(A RPL =E2=80=9Cleaf=E2=80=9D is a router.)

> Finally I'm looking at BIER see how their ideas could apply to LLN= s=E2=80=A6

Yep.
We (TZI) have done (specified, implemented, analyzed) an efficient BIER-lik= e multicast forwarding protocol for non-storing mode a while ago.

I admit to some confusion here.=C2=A0 Is (topolo= gy-free) MPL no longer the default
multicast forwarding protocol = for LLN?
=C2=A0
Need to write that up in an I-D and submit it somewhere.
BIER or ROLL or both?

I thought the goal was to shut down (or is it re-char= ter) ROLL?=C2=A0 If we're considering
new approaches to multi= cast forwarding, that may be reason enough to re-charter
ROLL.

-K-
=C2=A0
Gr=C3=BC=C3=9Fe, Carsten

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

--e89a8f64272825b9760505781b05-- From nobody Wed Oct 15 09:00: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 1C4191A885F for ; Wed, 15 Oct 2014 09:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhkLhjqjww4a for ; Wed, 15 Oct 2014 09:00:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE07D1A889F for ; Wed, 15 Oct 2014 09:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12198; q=dns/txt; s=iport; t=1413388845; x=1414598445; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JFA0VcjM8C+O2AZfCGf/z4qTa8PgLgrWVLd7YY9sY+M=; b=kvT9Pb1KnqkGziKpEoFeio0NkLy97YCmvKb/h803DAnrMgHHcpGXiesr lEEfIGA0ta4oIIdtgEAZd1B9mqB3PdmwHEru3jJXnDUAKB0c5UtzUW5aB eqWUY1Zaxp/OR8XG5+1i2PXYSQ0VW/yiUn22EtJVRNN14RKo5OzkeOGnV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFABuZPlStJA2N/2dsb2JhbABbgkhGU1gEgwLIcwEJh00CG3kWAX2EAgEBAQMBAQEBIApBCwULAgEGAhEEAQELHQMCAgIlCxQJCAIEDgUIiC4IDZZSnE2VJwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkAAdLQQGAYJ3NoEeBY9jghyhb4N3bIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,725,1406592000"; d="scan'208,217";a="363582030" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2014 16:00:44 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9FG0hME010567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Oct 2014 16:00:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 11:00:43 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxVZ7NgAABfnA= Date: Wed, 15 Oct 2014 16:00:42 +0000 Deferred-Delivery: Wed, 15 Oct 2014 16:00:00 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> 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.49.80.52] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842E1C49Axmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Ssjc0L6clXRbiSGCkE1UTIxSEh8 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 16:00:47 -0000 --_000_E045AECD98228444A58C61C200AE1BD842E1C49Axmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3IgZm9ybSBhIG5ldyBncm91cCDimLoNCg0KV2hhdCBhYm91dCBSb3V0aW5nIE92ZXIgQ29tcGxl dGUgS2Fvcz8NCg0KTW9yZSBzZXJpb3VzbHksIGl04oCZcyBwcm9iYWJseSBhIGdvb2QgaWRlYSB0 byBnb3RvIHRocm91Z2ggdGhlIEJvRiBzZXF1ZW5jZSBhZ2FpbiB0byBhbmFseXplIHdoYXTigJlz IGxlZnQgdG8gYmUgZG9uZS4NCkkgY2FuIGNlcnRhaW5seSBzZWUgYW4gYW5hbG9nIG9mIHdoYXQg dGhlIDZsbyBpcyB0byA2TG9XUEFOLCBidXQgZm9yIFJPTEwuDQoNCkNoZWVycywNCg0KUGFzY2Fs DQoNCkZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBLZXJyeSBMeW5uDQpTZW50OiBtZXJjcmVkaSAxNSBvY3RvYnJlIDIwMTQgMTc6NTINClRvOiBS b3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jrcw0KQ2M6IElKc2JyYW5kIFdp am5hbmRzIChpd2lqbmFuZCkNClN1YmplY3Q6IFJlOiBbUm9sbF0gbXVsdGljYXN0ICYgTUxEIG9u IExMTg0KDQpQYXNjYWwsIENhcnN0ZW4sIGV0IGFsLg0KDQpPbiBTYXQsIE9jdCAxMSwgMjAxNCBh dCAyOjM5IEFNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emku b3JnPj4gd3JvdGU6DQpSaWdodCwgTUxEIGlzIGEgaG9zdC1yb3V0ZXIgcHJvdG9jb2wuDQpSb3V0 ZXJzIGFtb25nIHRoZW0gc3BlYWsgYSByb3V0aW5nIHByb3RvY29sLCBzbyB0aGV5IHdvdWxkbuKA mXQgZXhjaGFuZ2UgTUxELg0KKEEgUlBMIOKAnGxlYWbigJ0gaXMgYSByb3V0ZXIuKQ0KDQo+IEZp bmFsbHkgSSdtIGxvb2tpbmcgYXQgQklFUiBzZWUgaG93IHRoZWlyIGlkZWFzIGNvdWxkIGFwcGx5 IHRvIExMTnPigKYNCg0KWWVwLg0KV2UgKFRaSSkgaGF2ZSBkb25lIChzcGVjaWZpZWQsIGltcGxl bWVudGVkLCBhbmFseXplZCkgYW4gZWZmaWNpZW50IEJJRVItbGlrZSBtdWx0aWNhc3QgZm9yd2Fy ZGluZyBwcm90b2NvbCBmb3Igbm9uLXN0b3JpbmcgbW9kZSBhIHdoaWxlIGFnby4NCg0KSSBhZG1p dCB0byBzb21lIGNvbmZ1c2lvbiBoZXJlLiAgSXMgKHRvcG9sb2d5LWZyZWUpIE1QTCBubyBsb25n ZXIgdGhlIGRlZmF1bHQNCm11bHRpY2FzdCBmb3J3YXJkaW5nIHByb3RvY29sIGZvciBMTE4/DQoN Ck5lZWQgdG8gd3JpdGUgdGhhdCB1cCBpbiBhbiBJLUQgYW5kIHN1Ym1pdCBpdCBzb21ld2hlcmUu DQpCSUVSIG9yIFJPTEwgb3IgYm90aD8NCkkgdGhvdWdodCB0aGUgZ29hbCB3YXMgdG8gc2h1dCBk b3duIChvciBpcyBpdCByZS1jaGFydGVyKSBST0xMPyAgSWYgd2UncmUgY29uc2lkZXJpbmcNCm5l dyBhcHByb2FjaGVzIHRvIG11bHRpY2FzdCBmb3J3YXJkaW5nLCB0aGF0IG1heSBiZSByZWFzb24g ZW5vdWdoIHRvIHJlLWNoYXJ0ZXINClJPTEwuDQoNCi1LLQ0KDQpHcsO8w59lLCBDYXJzdGVuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1h aWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KDQo= --_000_E045AECD98228444A58C61C200AE1BD842E1C49Axmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3IgZm9ybSBhIG5ldyBncm91cA0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldoYXQgYWJvdXQgUm91dGluZyBPdmVyIENvbXBsZXRlIEthb3M/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Nb3JlIHNlcmlvdXNseSwgaXTigJlzIHByb2JhYmx5IGEgZ29vZCBpZGVhIHRvIGdvdG8gdGhy b3VnaCB0aGUgQm9GIHNlcXVlbmNlIGFnYWluIHRvIGFuYWx5emUgd2hhdOKAmXMgbGVmdCB0byBi ZSBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbiBjZXJ0YWlubHkgc2Vl IGFuIGFuYWxvZyBvZiB3aGF0IHRoZSA2bG8gaXMgdG8gNkxvV1BBTiwgYnV0IGZvciBST0xMLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJvbGwg W21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlcnJ5 IEx5bm48YnI+DQo8Yj5TZW50OjwvYj4gbWVyY3JlZGkgMTUgb2N0b2JyZSAyMDE0IDE3OjUyPGJy Pg0KPGI+VG86PC9iPiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jrczxi cj4NCjxiPkNjOjwvYj4gSUpzYnJhbmQgV2lqbmFuZHMgKGl3aWpuYW5kKTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1JvbGxdIG11bHRpY2FzdCAmYW1wOyBNTEQgb24gTExOPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbCwgQ2Fyc3Rl biwgZXQgYWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBP Y3QgMTEsIDIwMTQgYXQgMjozOSBBTSwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWls dG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodCwgTUxEIGlzIGEg aG9zdC1yb3V0ZXIgcHJvdG9jb2wuPGJyPg0KUm91dGVycyBhbW9uZyB0aGVtIHNwZWFrIGEgcm91 dGluZyBwcm90b2NvbCwgc28gdGhleSB3b3VsZG7igJl0IGV4Y2hhbmdlIE1MRC48YnI+DQooQSBS UEwg4oCcbGVhZuKAnSBpcyBhIHJvdXRlci4pPGJyPg0KPGJyPg0KJmd0OyBGaW5hbGx5IEknbSBs b29raW5nIGF0IEJJRVIgc2VlIGhvdyB0aGVpciBpZGVhcyBjb3VsZCBhcHBseSB0byBMTE5z4oCm PGJyPg0KPGJyPg0KWWVwLjxicj4NCldlIChUWkkpIGhhdmUgZG9uZSAoc3BlY2lmaWVkLCBpbXBs ZW1lbnRlZCwgYW5hbHl6ZWQpIGFuIGVmZmljaWVudCBCSUVSLWxpa2UgbXVsdGljYXN0IGZvcndh cmRpbmcgcHJvdG9jb2wgZm9yIG5vbi1zdG9yaW5nIG1vZGUgYSB3aGlsZSBhZ28uPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFkbWl0IHRvIHNvbWUgY29u ZnVzaW9uIGhlcmUuJm5ic3A7IElzICh0b3BvbG9neS1mcmVlKSBNUEwgbm8gbG9uZ2VyIHRoZSBk ZWZhdWx0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5tdWx0aWNhc3QgZm9yd2FyZGluZyBwcm90b2NvbCBmb3IgTExOPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPk5lZWQgdG8gd3JpdGUgdGhhdCB1cCBpbiBhbiBJLUQgYW5kIHN1Ym1p dCBpdCBzb21ld2hlcmUuPGJyPg0KQklFUiBvciBST0xMIG9yIGJvdGg/PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IHRo ZSBnb2FsIHdhcyB0byBzaHV0IGRvd24gKG9yIGlzIGl0IHJlLWNoYXJ0ZXIpIFJPTEw/Jm5ic3A7 IElmIHdlJ3JlIGNvbnNpZGVyaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5uZXcgYXBwcm9hY2hlcyB0byBtdWx0aWNhc3QgZm9yd2FyZGluZywg dGhhdCBtYXkgYmUgcmVhc29uIGVub3VnaCB0byByZS1jaGFydGVyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ST0xMLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tSy08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3LDvMOfZSwgQ2Fy c3RlbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N ClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJv bGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_E045AECD98228444A58C61C200AE1BD842E1C49Axmbrcdx01ciscoc_-- From nobody Wed Oct 15 09:24:46 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 C8E5A1A88E9 for ; Wed, 15 Oct 2014 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7tprKXlQOVx for ; Wed, 15 Oct 2014 09:24:36 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818EA1A88CC for ; Wed, 15 Oct 2014 09:24:36 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id a141so1230551oig.29 for ; Wed, 15 Oct 2014 09:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VkEAwLTy4khE8/d7PMfd9NO8gB4y1o+MZzOxYGqNbuU=; b=xqcHQXOO9AHlmnfKKz6ucKyahwNJt4IpyaGGOUAp2ErbwqqZy473N4sTh/RY6WFpAv ZDwvuCoB8JPPtIwPZBGtsskVlgks7OR8KjIfSef6iBLu+74BAxROGEcHxT5Ojo7RLDTu CN/7iR0LY9h20pg5Ui2jpx8BGehVkfOHtO+TKrbi8CADBPmVqiK9JqoO0j4Eeq7prRx1 Kfej6FOV4cTTkuqU6h1fcQJnXdTLtpRKGmJ5z7p2kEjPE5/gPajGPqTRpPQw6fa4md38 Vb+lNazsmEdl/wWKeiFX9HXb0TDsKXOp7wTTvit7qMnxUgcHow7zZm7Gh4SI5AFJceBV CEnQ== MIME-Version: 1.0 X-Received: by 10.182.163.33 with SMTP id yf1mr12003019obb.0.1413390275926; Wed, 15 Oct 2014 09:24:35 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.15.129 with HTTP; Wed, 15 Oct 2014 09:24:35 -0700 (PDT) In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> Date: Wed, 15 Oct 2014 12:24:35 -0400 X-Google-Sender-Auth: pJZiDvUBvqltf8elIyeDdN3TJdg Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8f642728535fc805057891d8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Eamw5tkypxKQLSrs8jhgAjWvJnE Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 16:24:38 -0000 --e89a8f642728535fc805057891d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Or form a new group J > > > > What about Routing Over Complete Kaos? > > > > More seriously, it=E2=80=99s probably a good idea to goto through the BoF= sequence > again to analyze what=E2=80=99s left to be done. > > I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL= . > > > For me the first question is whether multicast in the LLN would be RPL- dependent, or have RPL-like features (e.g. dependence on a DODAG). That could argue for doing the work in ROLL or a follow on group (ROLLMAN?) At least some of the 6lo proposals (MS/TP comes to mind) are not mesh networks, but still constrained from a host and bandwidth perspective. I like the topology-independence of MPL, but I think work still needs to be done to see how far it is from optimal (in terms of energy and bandwidth usage) under different operating conditions and parameter settings. -K- > Cheers, > > > > Pascal > > > --e89a8f642728535fc805057891d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) &= lt;pthubert@cisco.c= om> wrote:

Or form a new group J

=C2=A0

What about Routing Over C= omplete Kaos?

=C2=A0

More seriously, it=E2=80= =99s probably a good idea to goto through the BoF sequence again to analyze= what=E2=80=99s left to be done.

I can certainly see an an= alog of what the 6lo is to 6LoWPAN, but for ROLL.

=C2=A0

<= /div>
For me the first question is whether multicast= in the LLN would be RPL-
dependent, or have RPL-like features (e= .g. dependence on a DODAG).
That could argue for doing the work i= n ROLL or a follow on group
(ROLLMAN?)

A= t least some of the 6lo proposals (MS/TP comes to mind) are not mesh
<= div>networks, but still constrained from a host and bandwidth perspective.<= /div>

I like the topology-independence of MPL, but I thi= nk work still needs to be
done to see how far it is from optimal = (in terms of energy and bandwidth
usage) under different operatin= g conditions and parameter settings.

-K-
=C2=A0

=

Cheers,

=C2=A0=

Pascal=

=C2=A0

<= /div>
--e89a8f642728535fc805057891d8-- From nobody Wed Oct 15 09:39:03 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 3F74E1A892C for ; Wed, 15 Oct 2014 09:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vck_yZM4Vqos for ; Wed, 15 Oct 2014 09:38:59 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA5A1A895E for ; Wed, 15 Oct 2014 09:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19362; q=dns/txt; s=iport; t=1413391129; x=1414600729; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oNcRTOILqSrwBx+h2yGlxuc51yOMhKu2+ftqx/ChcZ4=; b=fx847SfMOl9WfQqJbAuu05tK9ntrRFRccn0NV13LxjAF4o3KFEHrCun9 Lj40k7te5b8Jpl2CVoWy5EPvrWIOSoYZCkFwShN14E2i6pIQM7aqZ1H+i B44LUCYOhGN9MGOVZPewJQa4E4ZjwCnZm0k4K+08RUJtZXWZozHeGqEoQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFANChPlStJA2H/2dsb2JhbABbgkhGU1gEgwLQSgIbeRYBfYQCAQEBBCMKTBACAQgRBAEBCx0DAgICMBQJCAIEDgUIiDazN5UmAQEBAQEBAQEBAQEBAQEBAQEBAQEBF492Ch0xBgGCdzaBHgWRf6Fvg3dsgQZCgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,725,1406592000"; d="scan'208,217"; a="87232153" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 15 Oct 2014 16:38:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9FGcm4V017231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Oct 2014 16:38:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 11:38:48 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxXtilgAAApEA= Date: Wed, 15 Oct 2014 16:38:47 +0000 Deferred-Delivery: Wed, 15 Oct 2014 16:38:00 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> 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.49.80.52] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842E1C6B0xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5TJRyPGtq7WQis5c_o9cjA5r6l0 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 16:39:01 -0000 --_000_E045AECD98228444A58C61C200AE1BD842E1C6B0xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gS2Vycnk6DQoNCk9yIFJvbGwgTXVsdGljYXN0IE9wZXJhdGlvbnMgKCA6IFJPTExNT3Bz PyA6ICkNCg0KQmFzaWNhbGx5LCBCSUVSIG5lZWRzIGEgcHJlZXhpc3RpbmcgdHJlZSBzdHJ1Y3R1 cmUgYW5kIFJQTCBpcyBkZXNpZ25lZCB0byBidWlsZCBhbmQgbWFpbnRhaW4gb25lLiBUaGV5IG5l ZWQgYSByb290IG5vZGUgYW5kIHdlIGhhdmUgb25lLg0KT24gcGFwZXIgaXQgaXMgYSBwZXJmZWN0 IG1hdGNoLiBOb3cgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlcmUgaXMgZW5vdWdoIG5lZWQg Zm9yIHRoYXQgd29yaywgYW5kIHRoZW4gd2XigJlsbCBmaW5kIGEgcGxhY2UgdG8gbWFrZSBpdCBo YXBwZW4uDQoNClRvIHN0YXJ0IHdpdGgsIHdvdWxkIHlvdSBoYXZlIGEgc3BlY2lmaWMgdXNlIGNh c2Ugb2YgbXVsdGljYXN0IGluIExMTnMgd2hlcmUgTVBMIGlzIGxlc3MgYXBwbGljYWJsZSB0aGFu IHRoZSBjbGFzc2ljYWwgdHJlZS1iYXNlZCBmb3J3YXJkaW5nPw0KDQpXaXRoIHRoYXQsIHdlIGNv dWxkIGNvbm5lY3QgaW50byB0aGUgQklFUiBlZmZvcnQuDQoNClN0cm9uZyBwb2ludHM6DQotIHZl cnkgbGltaXRlZCBzdGF0ZSBpbiB0aGUgbm9kZXMsIGNvdWxkIGV2ZW4gYmUgdXNlZCBmb3IgdW5p Y2FzdCwgaW5kZXBlbmRlbnQgb24gdGhlIG51bWJlciBvZiBncm91cHMgYW5kIHRoZSBzaXplIG9m IHRoZSBuZXR3b3JrDQotIGJpdCBhZ2dyZWdhdGlvbiBlYXN5IHRvIGFkdmVydGlzZSBpbiBleGlz dGluZyBEQU9zLCBsb3cgY29zdCB0aGVyZSB0b28NCi0gdHJhbnNwYXJlbnQgc3VwcG9ydCBmb3Ig djQgYW5kIHY2IChzaW5jZSBpdCBpcyBhbiBvdmVybGF5KQ0KDQpXZWFrIHBvaW50czoNCi0gZXh0 cmEgZW5jYXBzdWxhdGlvbiAoc2luY2UgaXQgaXMgYW4gb3ZlcmxheSkNCi0gbmV3IHJvdXRpbmcg YW5kIGZvcndhcmRpbmcgb3BlcmF0aW9uIHRvIGltcGxlbWVudCBpbiB0aGUgbm9kZXMgKGJpdHdp c2UpDQotIGxpbWl0ZWQgbnVtYmVyIG9mIG5vZGVzIHBlciBET0RBRyAocm91Z2hseSAxMDApLg0K DQpDaGVlcnMsDQoNClBhc2NhbA0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgS2VycnkgTHlubg0KU2VudDogbWVyY3JlZGkgMTUgb2N0b2Jy ZSAyMDE0IDE4OjI1DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29y a3MNCkNjOiBJSnNicmFuZCBXaWpuYW5kcyAoaXdpam5hbmQpDQpTdWJqZWN0OiBSZTogW1JvbGxd IG11bHRpY2FzdCAmIE1MRCBvbiBMTE4NCg0KT24gV2VkLCBPY3QgMTUsIDIwMTQgYXQgMTI6MDAg UE0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tPj4gd3JvdGU6DQpPciBmb3JtIGEgbmV3IGdyb3VwIOKYug0KDQpX aGF0IGFib3V0IFJvdXRpbmcgT3ZlciBDb21wbGV0ZSBLYW9zPw0KDQpNb3JlIHNlcmlvdXNseSwg aXTigJlzIHByb2JhYmx5IGEgZ29vZCBpZGVhIHRvIGdvdG8gdGhyb3VnaCB0aGUgQm9GIHNlcXVl bmNlIGFnYWluIHRvIGFuYWx5emUgd2hhdOKAmXMgbGVmdCB0byBiZSBkb25lLg0KSSBjYW4gY2Vy dGFpbmx5IHNlZSBhbiBhbmFsb2cgb2Ygd2hhdCB0aGUgNmxvIGlzIHRvIDZMb1dQQU4sIGJ1dCBm b3IgUk9MTC4NCg0KRm9yIG1lIHRoZSBmaXJzdCBxdWVzdGlvbiBpcyB3aGV0aGVyIG11bHRpY2Fz dCBpbiB0aGUgTExOIHdvdWxkIGJlIFJQTC0NCmRlcGVuZGVudCwgb3IgaGF2ZSBSUEwtbGlrZSBm ZWF0dXJlcyAoZS5nLiBkZXBlbmRlbmNlIG9uIGEgRE9EQUcpLg0KVGhhdCBjb3VsZCBhcmd1ZSBm b3IgZG9pbmcgdGhlIHdvcmsgaW4gUk9MTCBvciBhIGZvbGxvdyBvbiBncm91cA0KKFJPTExNQU4/ KQ0KDQpBdCBsZWFzdCBzb21lIG9mIHRoZSA2bG8gcHJvcG9zYWxzIChNUy9UUCBjb21lcyB0byBt aW5kKSBhcmUgbm90IG1lc2gNCm5ldHdvcmtzLCBidXQgc3RpbGwgY29uc3RyYWluZWQgZnJvbSBh IGhvc3QgYW5kIGJhbmR3aWR0aCBwZXJzcGVjdGl2ZS4NCg0KSSBsaWtlIHRoZSB0b3BvbG9neS1p bmRlcGVuZGVuY2Ugb2YgTVBMLCBidXQgSSB0aGluayB3b3JrIHN0aWxsIG5lZWRzIHRvIGJlDQpk b25lIHRvIHNlZSBob3cgZmFyIGl0IGlzIGZyb20gb3B0aW1hbCAoaW4gdGVybXMgb2YgZW5lcmd5 IGFuZCBiYW5kd2lkdGgNCnVzYWdlKSB1bmRlciBkaWZmZXJlbnQgb3BlcmF0aW5nIGNvbmRpdGlv bnMgYW5kIHBhcmFtZXRlciBzZXR0aW5ncy4NCg0KLUstDQoNCkNoZWVycywNCg0KUGFzY2FsDQoN Cg== --_000_E045AECD98228444A58C61C200AE1BD842E1C6B0xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gS2Vycnk6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PciBSb2xsIE11 bHRpY2FzdCBPcGVyYXRpb25zICggOiBST0xMTU9wcz8gOiApPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CYXNpY2FsbHks IEJJRVIgbmVlZHMgYSBwcmVleGlzdGluZyB0cmVlIHN0cnVjdHVyZSBhbmQgUlBMIGlzIGRlc2ln bmVkIHRvIGJ1aWxkIGFuZCBtYWludGFpbiBvbmUuIFRoZXkgbmVlZCBhIHJvb3Qgbm9kZSBhbmQg d2UgaGF2ZSBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uIHBhcGVyIGl0IGlz IGEgcGVyZmVjdCBtYXRjaC4gTm93IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJlIGlzIGVu b3VnaCBuZWVkIGZvciB0aGF0IHdvcmssIGFuZCB0aGVuIHdl4oCZbGwgZmluZCBhIHBsYWNlIHRv IG1ha2UgaXQgaGFwcGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gc3RhcnQgd2l0aCwgd291bGQgeW91IGhhdmUg YSBzcGVjaWZpYyB1c2UgY2FzZSBvZiBtdWx0aWNhc3QgaW4gTExOcyB3aGVyZSBNUEwgaXMgbGVz cyBhcHBsaWNhYmxlIHRoYW4gdGhlIGNsYXNzaWNhbCB0cmVlLWJhc2VkIGZvcndhcmRpbmc/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XaXRoIHRoYXQsIHdlIGNvdWxkIGNvbm5lY3QgaW50byB0aGUgQklFUiBlZmZvcnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TdHJvbmcgcG9pbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t IHZlcnkgbGltaXRlZCBzdGF0ZSBpbiB0aGUgbm9kZXMsIGNvdWxkIGV2ZW4gYmUgdXNlZCBmb3Ig dW5pY2FzdCwgaW5kZXBlbmRlbnQgb24gdGhlIG51bWJlciBvZiBncm91cHMgYW5kIHRoZSBzaXpl IG9mIHRoZSBuZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gYml0IGFnZ3Jl Z2F0aW9uIGVhc3kgdG8gYWR2ZXJ0aXNlIGluIGV4aXN0aW5nIERBT3MsIGxvdyBjb3N0IHRoZXJl IHRvbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIHRyYW5zcGFyZW50IHN1cHBvcnQg Zm9yIHY0IGFuZCB2NiAoc2luY2UgaXQgaXMgYW4gb3ZlcmxheSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlYWsgcG9p bnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIGV4dHJhIGVuY2Fwc3VsYXRpb24g KHNpbmNlIGl0IGlzIGFuIG92ZXJsYXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0g bmV3IHJvdXRpbmcgYW5kIGZvcndhcmRpbmcgb3BlcmF0aW9uIHRvIGltcGxlbWVudCBpbiB0aGUg bm9kZXMgKGJpdHdpc2UpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBsaW1pdGVk IG51bWJlciBvZiBub2RlcyBwZXIgRE9EQUcgKHJvdWdobHkgMTAwKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5LZXJyeSBMeW5uPGJyPg0KPGI+U2VudDo8L2I+IG1lcmNyZWRpIDE1IG9jdG9icmUg MjAxNCAxODoyNTxicj4NCjxiPlRvOjwvYj4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3M8YnI+DQo8Yj5DYzo8L2I+IElKc2JyYW5kIFdpam5hbmRzIChpd2lqbmFuZCk8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSb2xsXSBtdWx0aWNhc3QgJmFtcDsgTUxEIG9uIExM TjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE1LCAyMDE0IGF0IDEyOjAwIFBNLCBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yIGZvcm0gYSBuZXcgZ3JvdXANCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgYWJvdXQgUm91dGluZyBPdmVyIENvbXBs ZXRlIEthb3M/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9yZSBzZXJpb3VzbHksIGl04oCZcyBwcm9iYWJseSBh IGdvb2QgaWRlYSB0byBnb3RvIHRocm91Z2ggdGhlIEJvRiBzZXF1ZW5jZSBhZ2FpbiB0byBhbmFs eXplIHdoYXTigJlzDQogbGVmdCB0byBiZSBkb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgY2FuIGNlcnRhaW5seSBzZWUgYW4gYW5hbG9nIG9mIHdoYXQgdGhlIDZsbyBpcyB0 byA2TG9XUEFOLCBidXQgZm9yIFJPTEwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgbWUgdGhlIGZpcnN0IHF1ZXN0aW9uIGlzIHdoZXRoZXIgbXVs dGljYXN0IGluIHRoZSBMTE4gd291bGQgYmUgUlBMLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVwZW5kZW50LCBvciBoYXZlIFJQTC1saWtlIGZl YXR1cmVzIChlLmcuIGRlcGVuZGVuY2Ugb24gYSBET0RBRykuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGNvdWxkIGFyZ3VlIGZvciBkb2lu ZyB0aGUgd29yayBpbiBST0xMIG9yIGEgZm9sbG93IG9uIGdyb3VwPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oUk9MTE1BTj8pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IGxlYXN0IHNvbWUg b2YgdGhlIDZsbyBwcm9wb3NhbHMgKE1TL1RQIGNvbWVzIHRvIG1pbmQpIGFyZSBub3QgbWVzaDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmV0d29y a3MsIGJ1dCBzdGlsbCBjb25zdHJhaW5lZCBmcm9tIGEgaG9zdCBhbmQgYmFuZHdpZHRoIHBlcnNw ZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGxpa2UgdGhlIHRvcG9sb2d5LWluZGVwZW5kZW5jZSBvZiBNUEwsIGJ1dCBJIHRoaW5r IHdvcmsgc3RpbGwgbmVlZHMgdG8gYmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmRvbmUgdG8gc2VlIGhvdyBmYXIgaXQgaXMgZnJvbSBvcHRpbWFs IChpbiB0ZXJtcyBvZiBlbmVyZ3kgYW5kIGJhbmR3aWR0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXNhZ2UpIHVuZGVyIGRpZmZlcmVudCBvcGVy YXRpbmcgY29uZGl0aW9ucyBhbmQgcGFyYW1ldGVyIHNldHRpbmdzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tSy08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E045AECD98228444A58C61C200AE1BD842E1C6B0xmbrcdx01ciscoc_-- From nobody Wed Oct 15 09:40: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 11E4B1A8970 for ; Wed, 15 Oct 2014 09:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 GVFjnG4x_D50 for ; Wed, 15 Oct 2014 09:40:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::742]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891411A88B0 for ; Wed, 15 Oct 2014 09:40:08 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0430.eurprd01.prod.exchangelabs.com (10.242.221.21) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 16:39:45 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 16:39:45 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8AAX0deAAACcwoAA3HB9gAAAUc4AAAFdIxg= Date: Wed, 15 Oct 2014 16:39:45 +0000 Message-ID: <23BA6593-C10E-4E30-8769-77C37A5480CB@landisgyr.com> References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [81.125.247.229] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0430; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(189002)(41574002)(377454003)(107046002)(97736003)(83716003)(101416001)(82746002)(64706001)(16236675004)(50986999)(76176999)(92566001)(54356999)(40100003)(31966008)(36756003)(92726001)(86362001)(4396001)(105586002)(99396003)(19580405001)(21056001)(19580395003)(120916001)(122556002)(80022003)(33656002)(85852003)(110136001)(66066001)(15975445006)(19617315012)(95666004)(93886004)(19625215002)(76482002)(46102003)(85306004)(106356001)(2656002)(20776003)(87936001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0430; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_23BA6593C10E4E30876977C37A5480CBlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6oYe-7FSx3I0pgjDv5z6eO3HLA0 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 16:40:14 -0000 --_000_23BA6593C10E4E30876977C37A5480CBlandisgyrcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been a lot of experience and learning around 6lowpans and mesh/LL= N scenarios, and it's spread around a bunch of documents across multiple wo= rking groups, not all of these groups being active anymore. A portion of th= ese documents contain multiple solutions for multiple overlapping problem s= paces, with no "roadmap" to show to navigate through the LLN solution domai= n. It might be nice to have a document that "rolls up" the best ideas from the= se documents into a guide for developers. For instance, "cherry picking" me= chanisms across RFCs 6775, 6550, etc to produce a definitive way to deliver= a solution that can scale to thousands of nodes, or gracefully backdown it= s capabilities to address smaller home environments There are great ideas in these documents, I would just like to see this inf= ormation coalesced, or at a minimum a roadmap to know how to navigate throu= gh it all Thanks! Randy On Oct 15, 2014, at 6:00 PM, Pascal Thubert (pthubert) > wrote: Or form a new group :) What about Routing Over Complete Kaos? More seriously, it's probably a good idea to goto through the BoF sequence = again to analyze what's left to be done. I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Kerry Lynn Sent: mercredi 15 octobre 2014 17:52 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN Pascal, Carsten, et al. On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann > wrote: Right, MLD is a host-router protocol. Routers among them speak a routing protocol, so they wouldn't exchange MLD. (A RPL "leaf" is a router.) > Finally I'm looking at BIER see how their ideas could apply to LLNs... Yep. We (TZI) have done (specified, implemented, analyzed) an efficient BIER-lik= e multicast forwarding protocol for non-storing mode a while ago. I admit to some confusion here. Is (topology-free) MPL no longer the defau= lt multicast forwarding protocol for LLN? Need to write that up in an I-D and submit it somewhere. BIER or ROLL or both? I thought the goal was to shut down (or is it re-charter) ROLL? If we're c= onsidering new approaches to multicast forwarding, that may be reason enough to re-cha= rter ROLL. -K- Gr??e, Carsten _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_23BA6593C10E4E30876977C37A5480CBlandisgyrcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There has been a lot of experience and learning around 6lowpans and me= sh/LLN scenarios, and it's spread around a bunch of documents across multip= le working groups, not all of these groups being active anymore. A portion = of these documents contain multiple solutions for multiple overlapping problem spaces, with no "roadmap&q= uot; to show to navigate through the LLN solution domain.

It might be nice to have a document that "rolls up" the best= ideas from these documents into a guide for developers. For instance, &quo= t;cherry picking" mechanisms across RFCs 6775, 6550, etc to produce a = definitive way to deliver a solution that can scale to thousands of nodes, or gracefully backdown its capabilities to address = smaller home environments

There are great ideas in these documents, I would just like to see thi= s information coalesced, or at a minimum a roadmap to know how to navigate = through it all

Thanks!
Randy

On Oct 15, 2014, at 6:00 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Or form a new group J

 <= /p>

What about Routing Over C= omplete Kaos?

 <= /p>

More seriously, it’= s probably a good idea to goto through the BoF sequence again to analyze wh= at’s left to be done.

I can certainly see an an= alog of what the 6lo is to 6LoWPAN, but for ROLL.

 <= /p>

Cheers,<= /o:p>

 

Pascal

 <= /p>

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Kerry Lynn
Sent: mercredi 15 octobre 2014 17:52
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

 

Pascal, Carsten, et al.

 

On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann <= ;cabo@tzi.org> wro= te:

Right, MLD is a host-router protocol.
Routers among them speak a routing protocol, so they wouldn’t exchang= e MLD.
(A RPL “leaf” is a router.)

> Finally I'm looking at BIER see how their ideas could apply to LLNs= 230;

Yep.
We (TZI) have done (specified, implemented, analyzed) an efficient BIER-lik= e multicast forwarding protocol for non-storing mode a while ago.

 

I admit to some confusion here.  Is (topology-f= ree) MPL no longer the default

multicast forwarding protocol for LLN?

 

Need to write that up= in an I-D and submit it somewhere.
BIER or ROLL or both?

I thought the goal was to shut down (or is it re-cha= rter) ROLL?  If we're considering

new approaches to multicast forwarding, that may be = reason enough to re-charter

ROLL.

 

-K-

 

Grüße, Carsten


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

 

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

P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_23BA6593C10E4E30876977C37A5480CBlandisgyrcom_-- From nobody Wed Oct 15 09:58:19 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 AE5671A702E for ; Wed, 15 Oct 2014 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.514 X-Spam-Level: X-Spam-Status: No, score=0.514 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, MALFORMED_FREEMAIL=2.511, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcqg-7yTLiY9 for ; Wed, 15 Oct 2014 09:58:14 -0700 (PDT) Received: from nm4-vm2.access.bullet.mail.gq1.yahoo.com (nm4-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.32]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4691A87A3 for ; Wed, 15 Oct 2014 09:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413392294; bh=I70gppnd0buedzejXeqeE8/cZOFDtyq8nja7qWsCLsE=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=hwUzugzU7rcUP3Z78hOp3V090qpzM7+ypDYMQMWImqDeHiZM2KJN2T5aMSLoqnL7uIMNexf4KCwsaIYckwAkUC0DVBPvkwqzi/PR+X5jL7yx0w1J93bLy6iiHGgmSQ60Tsv7ZZNAjxKJiuEPtacO5pUFav5k3QE0NROsMf9II7Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=Revg/pGrwfK3lQmPghfT+Kz3JSKUo8yVWEMSrRL1bcQDS+d0WnJAE40oiKJa+sIhOdiM/9LQ/ZzSWf+Dg2wk6jqmDNn5yEyU3fXGOl0oRyIKue/oIfw9t4nxDOS9VfTYfO+vMDbgnzWviJgUHopOS30RFHPh0QHVAxJU1pvhGWo=; Received: from [216.39.60.171] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2014 16:58:14 -0000 Received: from [98.138.226.244] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2014 16:58:13 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 15 Oct 2014 16:58:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413392293; bh=I70gppnd0buedzejXeqeE8/cZOFDtyq8nja7qWsCLsE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=GiYM8RolfmKw7L/0soceDJ8/UQfbvN6OdQnfXXOHyuiElfhQ6kssjioHyzfNk9xRF9Gpz9h6dzpN/Lk1kQZ7fK5gECxjc3OCbGXDibvcInST9B040J7PE7SW4vAgIGkzSxNdxdjBDAoATj6BSw4Ca1vOux9swymI7fISDDET2+0= X-Yahoo-Newman-Id: 837346.29162.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JXBabaEVM1k7BrJgehaLJMShJJv3poQZxbWAaLrmVhZs.o3 97qUJa8nKQ4SciZc_Dhjbi1x.b1xQRdbnkFfsth8SD0hYFtAp.lo7p3Y._Kd UrkFWuUC4iRwRLVkkL25O4WbtqZYKdH4Iph77uZp6c_xdY4PqQBY7dgjMtgU YcvW7BhXuzUmIXnbSJG.emWPC.XJETX0Jk1vhN3bv88lvJg0c2iMrioD0QcV YqnuOX0PLGtgjLuXFQ565cCBTjZLxdaps6NdGyAuI4jyDWElstRQefF63gV7 tp4OaKRxo_MoFWJkyF.9R.jEwAoYoJ5ATlpkX6EddXP5nzcyNAKoaZ3jQWSs HKEqZ0tZsxREdIOKEbQxSLOxhIfLweiu7lUUebZOOvnli01b4nDHMouQgJ9d V4JlEpLKkdc5iaAwdi1acS_vJm427fO7VmXcmsupUby7bON_cBFDVbUdH_oC pm0FEEtzdSYOPEGC7BTTuWMSp2YBb9E9lQm34._i2NTlaogdeRg1r5z7h4rV 9QYYxFWAg9tDO9.g9F8.VnooUbHx8rQ9zZSfEiw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 09:58:07 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] multicast & MLD on LLN References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3496211891_1001210" Archived-At: http://mailarchive.ietf.org/arch/msg/roll/_Fxz--Ya9hDULkcjveOcsieoOzc Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 16:58:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3496211891_1001210 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Pascal, Let me try to provide a use case. The network is a Neighborhood Area Network. The application can be something like street lights or a smart metering AMI (really any collection of devices that are networked centrally with a non-trivial number of device= s in the network) Here are some details: 1) Around 5000 devices in the network total. There can be as many as 15 hops from the DODAG to the furthest leaf node in the network. 2) One border router that supports ROLL RPL. All devices in the network are ROLL RPL aware (some as routers, some end devices). What would be really nice is if we could have non-RPL aware end devices also in the network but I think that is another topic :-) 3) We support all of the mandatory multicast groups (eg all routers) in ou= r networked devices 4) From an application point of view, we want to use special application-defined multicast groups for things like: A. Control a geographic collection of street lights (like all the ones in an area where there is to be a festival this evening) B. Control a geographically diverse collection of devices that are not the entire population (for example, I want a message sent to all of my pre-pay customers which are mainly focused in some neighborhoods, less i= n others) 5) I don't want to incur the MPL overhead of all multicast traffic floodin= g all 5000 devices/forwarded up to 15 hops in my network when I send these special multicast group messages. What would be great in the above scenario is if the multicast traffic only traversed the portions of the network where members of the multicast group exist (eg, don't forward down portions of the tree where there are no multicast members). MPL as a flooding mechanism fails this goal (which is fine with relatively few devices but not so when talking about 5000 devices/24 hops! Is the above good enough to start a discussion on how to solve the problem? Don From: "Pascal Thubert (pthubert)" Reply-To: Routing Over Low power and Lossy networks Date: Wednesday, October 15, 2014 9:38 AM To: Routing Over Low power and Lossy networks Cc: "IJsbrand Wijnands (iwijnand)" Subject: Re: [Roll] multicast & MLD on LLN Hello Kerry: =20 Or Roll Multicast Operations ( : ROLLMOps? : ) =20 Basically, BIER needs a preexisting tree structure and RPL is designed to build and maintain one. They need a root node and we have one. On paper it is a perfect match. Now the question is whether there is enough need for that work, and then we=B9ll find a place to make it happen. =20 To start with, would you have a specific use case of multicast in LLNs wher= e MPL is less applicable than the classical tree-based forwarding? =20 With that, we could connect into the BIER effort. =20 Strong points: - very limited state in the nodes, could even be used for unicast, independent on the number of groups and the size of the network - bit aggregation easy to advertise in existing DAOs, low cost there too - transparent support for v4 and v6 (since it is an overlay) =20 Weak points: - extra encapsulation (since it is an overlay) - new routing and forwarding operation to implement in the nodes (bitwise) - limited number of nodes per DODAG (roughly 100). =20 Cheers, =20 Pascal =20 From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Kerry Lynn Sent: mercredi 15 octobre 2014 18:25 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN =20 On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) wrote: Or form a new group J =20 What about Routing Over Complete Kaos? =20 More seriously, it=B9s probably a good idea to goto through the BoF sequence again to analyze what=B9s left to be done. I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL. =20 For me the first question is whether multicast in the LLN would be RPL- dependent, or have RPL-like features (e.g. dependence on a DODAG). That could argue for doing the work in ROLL or a follow on group (ROLLMAN?) =20 At least some of the 6lo proposals (MS/TP comes to mind) are not mesh networks, but still constrained from a host and bandwidth perspective. =20 I like the topology-independence of MPL, but I think work still needs to be done to see how far it is from optimal (in terms of energy and bandwidth usage) under different operating conditions and parameter settings. =20 -K- =20 >=20 > Cheers, > =20 > Pascal > =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3496211891_1001210 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Pascal,

<= /div>
Let me try to provide a use case.

The net= work is a Neighborhood Area Network.  The application can be something = like street lights or a smart metering AMI (really any collection of devices= that are networked centrally with a non-trivial number of devices in the ne= twork)

Here are some details:
1)   A= round 5000 devices in the network total.  There can be as many as 15 ho= ps from the DODAG to the furthest leaf node in the network.
2) &nb= sp;One border router that supports ROLL RPL.  All devices in the networ= k are ROLL RPL aware (some as routers, some end devices).  What would b= e really nice is if we could have non-RPL aware end devices also in the netw= ork but I think that is another topic :-)
3)  We support all = of the mandatory multicast groups (eg all routers) in our networked devices<= /div>
4)  From an application point of view, we want to use special= application-defined multicast groups for things like:
  &nbs= p;    A.    Control a geographic collection of street li= ghts (like all the ones in an area where there is to be a festival this even= ing)
       B.    Control a geograph= ically  diverse collection of devices that are not the entire populatio= n (for example, I want a message sent to all of my pre-pay customers which a= re mainly focused in some neighborhoods, less in others)
5)  = I don't want to incur the MPL overhead of all multicast traffic flooding all= 5000 devices/forwarded up to 15 hops in my network when I send these specia= l multicast group messages.

What would be great in = the above scenario is if the multicast traffic only traversed the portions o= f the network where members of the multicast group exist (eg, don't forward = down portions of the tree where there are no multicast members).  MPL a= s a flooding mechanism fails this goal (which is fine with relatively few de= vices but not so when talking about 5000 devices/24 hops!

Is the above good enough to start a discussion on how to solve the pr= oblem?

Don


From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Reply-To: Routing Over Low power and Lossy networks &l= t;roll@ietf.org>
Date: Wednesday, October 15, 2014 9:38 AM
To: Routing Over Low power and Lossy networks &= lt;roll@ietf.org>
Cc: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
Subj= ect: Re: [Roll] multicast & MLD on LLN

<= div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-microsoft-c= om:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xmlns:m=3D"h= ttp://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR= /REC-html40">

Hello Kerr= y:

 

Or Roll Multicast Operations= ( : ROLLMOps? : )

=  

Basically, B= IER needs a preexisting tree structure and RPL is designed to build and main= tain one. They need a root node and we have one.

On paper it is a perfect match. Now the questi= on is whether there is enough need for that work, and then we’ll find = a place to make it happen.

 

To s= tart with, would you have a specific use case of multicast in LLNs where MPL= is less applicable than the classical tree-based forwarding?

 

With that, we could connect into the BIER eff= ort.

 

Strong points:<= /span>

- very limited state in the no= des, could even be used for unicast, independent on the number of groups and= the size of the network

- bit aggregation easy to advertise in existing DAOs, low cost there t= oo

- transparent su= pport for v4 and v6 (since it is an overlay)

 

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, = sans-serif; ">Weak points:

- extra encapsulation (since it is an overlay)

=

- new routing and forwarding operation t= o implement in the nodes (bitwise)

- limited number = of nodes per DODAG (roughly 100).

=  

&nb= sp;

Pascal

 

=

From: Roll [m= ailto:roll-bounces@ietf.org] On Behalf Of Kerry Lynn
Sent: mercredi 15 octobre 2014 18:= 25
To: Routing Over Low power and Lossy networks
Cc: IJs= brand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD = on LLN

 

On Wed, Oct 15, 2014 at 12:00 PM, = Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Or form a new group J=

 

What about Routing Over Complete Kaos?

=  

More seriously= , it’s probably a good idea to goto through the BoF sequence again to = analyze what’s left to be done.

I can certainly s= ee an analog of what the 6lo is to 6LoWPAN, but for ROLL.<= /p>

 

For me the first question is whether multicast in the LLN would = be RPL-

dependent, or have RPL= -like features (e.g. dependence on a DODAG).

That could argue for doing the work in ROLL or a follow on gr= oup

(ROLLMAN?)

<= /div>

 

At least some of the 6lo proposals (MS/TP comes to mind) are not mes= h

networks, but still constrai= ned from a host and bandwidth perspective.

 

I like the= topology-independence of MPL, but I think work still needs to be=

done to see how far it is from optimal (= in terms of energy and bandwidth

usage) under different operating conditions and parameter settings.<= /o:p>

 

-K-

 

Cheers,

 

Pascal=

 

<= /div>
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3496211891_1001210-- From nobody Wed Oct 15 10:12: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 AC70B1A8AA1 for ; Wed, 15 Oct 2014 10:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgP-RuVuQ1rK for ; Wed, 15 Oct 2014 10:11:52 -0700 (PDT) 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 2F1B71A8A98 for ; Wed, 15 Oct 2014 10:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29509; q=dns/txt; s=iport; t=1413393074; x=1414602674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GxBBLMm5flOYevTm+lcoGJDa2XdAkb5HsJModaRVyK4=; b=G3s7WTz6lB12DfRPrH6H/YC3c+5v/Nlhcp1VnLaB6tXcE+Z6wwJVwDjO SfsKz6Sasax7GCsXHpE4ju5atYMJ6ZeQTmpEdhBhu4BZQGFWY/9A7nG5T M0IizKLfO7+cjk/j3nv89VM1CMgyKm8bplX5OoYfHrKyNdTMhs2ud0O2T 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIGpPlStJV2P/2dsb2JhbABbgkhGU1gEy3UBCYdNAoEWFgF9hAIBAQEEAQEBKkELEAIBCBEDAQEBCxYBBgcnCxQJCAIEDgUIiDYNyF8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpPhScKHSANBAYBBoMngR4FkX+hb4N3bIEGQoECAQEB X-IronPort-AV: E=Sophos; i="5.04,725,1406592000"; d="scan'208,217"; a="87239347" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 15 Oct 2014 17:11:12 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9FHBCXm025954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Oct 2014 17:11:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 12:11:12 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxaFmpgAADOoA= Date: Wed, 15 Oct 2014 17:11:11 +0000 Deferred-Delivery: Wed, 15 Oct 2014 17:11:00 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> 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.49.80.52] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842E1C822xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hEAk79Rg5BlKOAVhoIpzSFwyZ6Q Cc: "Greg Shepherd \(shep\)" , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 17:11:57 -0000 --_000_E045AECD98228444A58C61C200AE1BD842E1C822xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a bunch, Don! Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: mercredi 15 octobre 2014 18:58 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN Hi Pascal, Let me try to provide a use case. The network is a Neighborhood Area Network. The application can be somethi= ng like street lights or a smart metering AMI (really any collection of dev= ices that are networked centrally with a non-trivial number of devices in t= he network) Here are some details: 1) Around 5000 devices in the network total. There can be as many as 15 = hops from the DODAG to the furthest leaf node in the network. 2) One border router that supports ROLL RPL. All devices in the network a= re ROLL RPL aware (some as routers, some end devices). What would be reall= y nice is if we could have non-RPL aware end devices also in the network bu= t I think that is another topic :-) 3) We support all of the mandatory multicast groups (eg all routers) in ou= r networked devices 4) From an application point of view, we want to use special application-d= efined multicast groups for things like: A. Control a geographic collection of street lights (like all the= ones in an area where there is to be a festival this evening) B. Control a geographically diverse collection of devices that a= re not the entire population (for example, I want a message sent to all of = my pre-pay customers which are mainly focused in some neighborhoods, less i= n others) 5) I don't want to incur the MPL overhead of all multicast traffic floodin= g all 5000 devices/forwarded up to 15 hops in my network when I send these = special multicast group messages. What would be great in the above scenario is if the multicast traffic only = traversed the portions of the network where members of the multicast group = exist (eg, don't forward down portions of the tree where there are no multi= cast members). MPL as a flooding mechanism fails this goal (which is fine = with relatively few devices but not so when talking about 5000 devices/24 h= ops! Is the above good enough to start a discussion on how to solve the problem? Don From: "Pascal Thubert (pthubert)" > Reply-To: Routing Over Low power and Lossy networks > Date: Wednesday, October 15, 2014 9:38 AM To: Routing Over Low power and Lossy networks > Cc: "IJsbrand Wijnands (iwijnand)" > Subject: Re: [Roll] multicast & MLD on LLN Hello Kerry: Or Roll Multicast Operations ( : ROLLMOps? : ) Basically, BIER needs a preexisting tree structure and RPL is designed to b= uild and maintain one. They need a root node and we have one. On paper it is a perfect match. Now the question is whether there is enough= need for that work, and then we'll find a place to make it happen. To start with, would you have a specific use case of multicast in LLNs wher= e MPL is less applicable than the classical tree-based forwarding? With that, we could connect into the BIER effort. Strong points: - very limited state in the nodes, could even be used for unicast, independ= ent on the number of groups and the size of the network - bit aggregation easy to advertise in existing DAOs, low cost there too - transparent support for v4 and v6 (since it is an overlay) Weak points: - extra encapsulation (since it is an overlay) - new routing and forwarding operation to implement in the nodes (bitwise) - limited number of nodes per DODAG (roughly 100). Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Kerry Lynn Sent: mercredi 15 octobre 2014 18:25 To: Routing Over Low power and Lossy networks Cc: IJsbrand Wijnands (iwijnand) Subject: Re: [Roll] multicast & MLD on LLN On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) > wrote: Or form a new group :) What about Routing Over Complete Kaos? More seriously, it's probably a good idea to goto through the BoF sequence = again to analyze what's left to be done. I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL. For me the first question is whether multicast in the LLN would be RPL- dependent, or have RPL-like features (e.g. dependence on a DODAG). That could argue for doing the work in ROLL or a follow on group (ROLLMAN?) At least some of the 6lo proposals (MS/TP comes to mind) are not mesh networks, but still constrained from a host and bandwidth perspective. I like the topology-independence of MPL, but I think work still needs to be done to see how far it is from optimal (in terms of energy and bandwidth usage) under different operating conditions and parameter settings. -K- Cheers, Pascal _______________________________________________ Roll mailing list Roll@ietf= .org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD842E1C822xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks a bunch, Don!=

 <= /p>

Cheers,<= /o:p>

 

Pascal

 <= /p>

From: Roll [ma= ilto:roll-bounces@ietf.org] On Behalf Of Don Sturek
Sent: mercredi 15 octobre 2014 18:58
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

 

Hi Pascal,

 

Let me try to provide a us= e case.

 

The network is a Neighborh= ood Area Network.  The application can be something like street lights= or a smart metering AMI (really any collection of devices that are networked centrally with a non-trivial number of devices in the networ= k)

 

Here are some details:

1)   Around 5000 devi= ces in the network total.  There can be as many as 15 hops from the DO= DAG to the furthest leaf node in the network.

2)  One border router= that supports ROLL RPL.  All devices in the network are ROLL RPL awar= e (some as routers, some end devices).  What would be really nice is if we could have non-RPL aware end devices also in the network but I th= ink that is another topic :-)

3)  We support all of= the mandatory multicast groups (eg all routers) in our networked devices

4)  From an applicati= on point of view, we want to use special application-defined multicast grou= ps for things like:

       = ;A.    Control a geographic collection of street lights (like all= the ones in an area where there is to be a festival this evening)

       = ;B.    Control a geographically  diverse collection of devic= es that are not the entire population (for example, I want a message sent t= o all of my pre-pay customers which are mainly focused in some neighborhoods, less in others)<= o:p>

5)  I don't want to i= ncur the MPL overhead of all multicast traffic flooding all 5000 devices/fo= rwarded up to 15 hops in my network when I send these special multicast group messages.

 

What would be great in the= above scenario is if the multicast traffic only traversed the portions of = the network where members of the multicast group exist (eg, don't forward down portions of the tree where there are no multicast membe= rs).  MPL as a flooding mechanism fails this goal (which is fine with = relatively few devices but not so when talking about 5000 devices/24 hops!<= o:p>

 

Is the above good enough t= o start a discussion on how to solve the problem?

 

Don

 

 

From: "Pascal Thubert (pthubert)" &= lt;pthubert@cisco.com>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
Date: Wednesday, October 15, 2014 9:38 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
Subject: Re: [Roll] multicast & MLD on LLN

 

Hello Kerry:

 

Or Roll Multicast Operati= ons ( : ROLLMOps? : )<= /p>

 

Basically, BIER needs a p= reexisting tree structure and RPL is designed to build and maintain one. Th= ey need a root node and we have one.

On paper it is a perfect = match. Now the question is whether there is enough need for that work, and = then we’ll find a place to make it happen.

 

To start with, would you = have a specific use case of multicast in LLNs where MPL is less applicable = than the classical tree-based forwarding?

 

With that, we could conne= ct into the BIER effort.

 

Strong points:

- very limited state in t= he nodes, could even be used for unicast, independent on the number of grou= ps and the size of the network

- bit aggregation easy to= advertise in existing DAOs, low cost there too

- transparent support for= v4 and v6 (since it is an overlay)=

 

Weak points:

- extra encapsulation (si= nce it is an overlay)<= /p>

- new routing and forward= ing operation to implement in the nodes (bitwise)

- limited number of nodes= per DODAG (roughly 100).

 

Cheers,

 

Pascal

 

From: Roll [mailto:roll-= bounces@ietf.org] On Behalf Of Kerry Lynn
Sent: mercredi 15 octobre 2014 18:25
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

 =

On Wed, Oct 15, 2014 at = 12:00 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Or form a new group J

 

What about Routing Over Complete Kaos?<= /span>

 

More seriously, it’s probably a g= ood idea to goto through the BoF sequence again to analyze what’s left to be done.

I can certainly see an analog of what t= he 6lo is to 6LoWPAN, but for ROLL.=

 

For me the first questio= n is whether multicast in the LLN would be RPL-

dependent, or have RPL-l= ike features (e.g. dependence on a DODAG).

That could argue for doi= ng the work in ROLL or a follow on group

(ROLLMAN?)

 =

At least some of the 6lo= proposals (MS/TP comes to mind) are not mesh

networks, but still cons= trained from a host and bandwidth perspective.

 =

I like the topology-inde= pendence of MPL, but I think work still needs to be

done to see how far it i= s from optimal (in terms of energy and bandwidth

usage) under different o= perating conditions and parameter settings.

 =

-K-

 =

Cheers,

 

Pascal

 

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

--_000_E045AECD98228444A58C61C200AE1BD842E1C822xmbrcdx01ciscoc_-- From nobody Wed Oct 15 13:09:44 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 BF8FD1A902D for ; Wed, 15 Oct 2014 13:09:27 -0700 (PDT) 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 BFIVHX9htZ9A for ; Wed, 15 Oct 2014 13:09:26 -0700 (PDT) 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 082561AC439 for ; Wed, 15 Oct 2014 13:09:02 -0700 (PDT) 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 s9FK8uUt013694; Wed, 15 Oct 2014 22:08:56 +0200 (CEST) Received: from [192.168.217.145] (p5489134F.dip0.t-ipconnect.de [84.137.19.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 596E5A30; Wed, 15 Oct 2014 22:08:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Oct 2014 22:08:53 +0200 X-Mao-Original-Outgoing-Id: 435096533.73991-8ac3133ee9aa38ba971cd9892588dac8 Content-Transfer-Encoding: quoted-printable Message-Id: <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DfWDGkDoZGF27BEgaAf5h8tbM8c Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 20:09:28 -0000 Hi Don, this sounds exactly like a use case our multicasting approach can solve. Two questions: 1) Are you using storing or non-storing mode for RPL? 2) For the kinds of groups below, was is the likely distribution of = group sizes? Gr=FC=DFe, Carsten On 15 Oct 2014, at 18:58, Don Sturek wrote: > 4) =46rom an application point of view, we want to use special = application-defined multicast groups for things like: > A. Control a geographic collection of street lights (like = all the ones in an area where there is to be a festival this evening) > B. Control a geographically diverse collection of devices = that are not the entire population (for example, I want a message sent = to all of my pre-pay customers which are mainly focused in some = neighborhoods, less in others) From nobody Wed Oct 15 13:24:10 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 4F7331ACC87 for ; Wed, 15 Oct 2014 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 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, MALFORMED_FREEMAIL=2.511, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJoXEjvDi0TR for ; Wed, 15 Oct 2014 13:24:04 -0700 (PDT) Received: from nm18-vm6.access.bullet.mail.bf1.yahoo.com (nm18-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.85]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091D61ACC89 for ; Wed, 15 Oct 2014 13:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413404641; bh=DqUehMGUiYeSVo9Bz+ELZpgazMeY1c4AyFBvAXl01Dk=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=n5TEkMcCunymvxbuv2gE+Ews4nfPqWKd6oockAlCkKbZagFfMrOcYqmlFG5GP1D50eIyBaFWfQcq2IxDJokELG6vTY5lFoOC3iXeqKP4ORXBqqSNO8nMTYb8x5Alc4Qfco0ORtWXZqy8cjnZ6TmZffwkiQKlTtoue4ihEt3o5i0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=DMPf3lnQHAKIEgt7gnLMoACRjZYKNrzHdDwv43+dc1QmvxgA5wASO5PdY4SGRvh6udqZWxxWC4EVF0on+t6x2MlzdQ1EtOWYFnZjDmd02AKm2euEm8B00fcLNhltJxeoz9WVFkJHoH2u58+eWl/oZnBFllI+q1JxJgmPmP0ViDQ=; Received: from [66.196.81.165] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 20:24:01 -0000 Received: from [98.138.104.97] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 20:24:01 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 15 Oct 2014 20:24:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413404641; bh=DqUehMGUiYeSVo9Bz+ELZpgazMeY1c4AyFBvAXl01Dk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=1nmgUk00t6h5y9Ws2CzcpbHHdlympnqEMFH9tQwJIxdm1xqZ20qgsx4Plty7J/oMH48zRpoKh3HpqYHWUme5gAHa8G1hjkXbELT/FFaP7uL5vGlRD/7SwFFTCpW2swQvKBhkVbim1m7Bab8DO4/KOfuxNH3KaK9re6pUhqQiybA= X-Yahoo-Newman-Id: 72597.19861.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: flbN_6sVM1n87WDQ7.wrzU1w.JHeI.K._QtYkPRcespmIM8 IUw84cOvKL4jjaCldGXirbz4Z_rzfKmKlNRVv4JgAahTNBE_KYHkdrIXk9iP 6SgVMvrVPn4yoGbEKHfpu2qU0Bzu1YGpUGoBTzukT6erfK6f25rBSTyiw0Po GzM1g.hjzp4jvNruUOoKc1bySZaLX2gzLmGAKKSpCHAHpuKeCkdV.XjLaPte LJJtNxuj7F5Aohnfmeb6CIyPhKgTSvIwCyxE5vnAPGznqEXKKrWdm86BnMfk I_0xb1g2uz1VIOKVXk.H4XFPnQ7pXLc7y88O82rVed8ApYfDQA3hVr4D6QGk IT6J0UQgE1XB49IYAzG0gEaCVBDL9ezqLQjFRk2g4OPILsAM_ofqxcsi0MRK tqq0DjXKvNTKC0ZdpDJ3gX2Mp2M1XEgRWnHJBDNinA14YN0tR1h4yI0G5CXn a4vfQqScHRIc8Jn.tswV0gZbWO1fAAPAqnqgHyo21i9ZTV3cQUFEeArQtVK6 0og7KSTEk4wpHVwXttN2Od.Vc_ecTS79rjRBxyU3L X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 13:23:56 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] multicast & MLD on LLN References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> In-Reply-To: <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/OLfSm7bQHfbTQu7jHbTqzQ3cyJ8 Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 20:24:05 -0000 Hi Carsten, On your questions posed below: 1) We are using non-storing 2) Distribution of group sizes. This is a tough question. I think some groups may be nearly the size of the entire network (say I want to send a message to all of my smart meters but don't need the relays or AP's to get the message). Some may be regionally focused and therefore small (eg, I have an outage and I want the smart meters in one location to report on the quality of the electric service they are seeing). Some may be geographically focused (like the example for the street light application wanting to manage street lights around a festival). I think the right answer here is we want applications to opt in/opt out of application multicast groups and we want the network forwarding to be smart enough to not flood the entire network if that is not needed. I know that is not the answer you are particularly looking for but I think that is the right answer. By the way, if I have an application multicast group that is nearly the entire population of the network, it would be really great if the network operator knew this and reduced those types of multicast transmissions. The biggest savings would be where we really only want to hit devices in a certain georgraphy and now we don't need every device in the network to see that traffic..... If we do this right, then we will arm the application developers with the ability to create their own groups (with some knowledge/understanding from the network operator) and the ability for the forwarding of the multicast traffic to avoid saturating the network with broadcast traffic that is not needed for that application multicast group. Don On 10/15/14 1:08 PM, "Carsten Bormann" wrote: >Hi Don, > >this sounds exactly like a use case our multicasting approach can solve. > >Two questions: > >1) Are you using storing or non-storing mode for RPL? > >2) For the kinds of groups below, was is the likely distribution of group >sizes? > >Gr=FC=DFe, Carsten > >On 15 Oct 2014, at 18:58, Don Sturek wrote: > >> 4) From an application point of view, we want to use special >>application-defined multicast groups for things like: >> A. Control a geographic collection of street lights (like all >>the ones in an area where there is to be a festival this evening) >> B. Control a geographically diverse collection of devices >>that are not the entire population (for example, I want a message sent >>to all of my pre-pay customers which are mainly focused in some >>neighborhoods, less in others) > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From nobody Wed Oct 15 13:27:46 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 AD49B1ACC82 for ; Wed, 15 Oct 2014 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 uSEPH2-60XrV for ; Wed, 15 Oct 2014 13:27:38 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D831A1A7001 for ; Wed, 15 Oct 2014 13:27:37 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 20:27:15 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 20:27:14 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8AAX0deAAACcwoAA3HB9gAAAUc4AAADViYAAAH71gAAArNuAAAaploD//8ISAA== Date: Wed, 15 Oct 2014 20:27:14 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> In-Reply-To: <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2.228.114.172] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(377454003)(189002)(199003)(24454002)(129404003)(51704005)(31966008)(36756003)(83506001)(15975445006)(19580395003)(19580405001)(80022003)(21056001)(107886001)(93886004)(2656002)(64706001)(66066001)(20776003)(97736003)(87936001)(85306004)(110136001)(40100003)(107046002)(76176999)(106356001)(54356999)(50986999)(92566001)(122556002)(92726001)(85852003)(86362001)(101416001)(105586002)(4396001)(99396003)(120916001)(95666004)(46102003)(76482002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RJ768S9xPa6fGlkalTKDz3tNwvI Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 20:27:43 -0000 Hi Pascal, This multicast use-case is similar to the street light group use-case, except aimed at the AMI grid network: There is of course a need to multicast firmware updates to devices in the smart grid. In that example (and in other AMR use-cases) all devices in the network subscribe to a common multicast address =8B it=B9s really a broadcast, if all devices need to be updated at the same time, with the same firmware. Then there is a multicast group scenario where, say, only 500 of 5000 nodes need to be updated (possibly associated with a geographic region of the grid) THere=B9s also a region-oriented multicast group address that could be used to send control/management information to a particular set of smart meters in the field. For instance if there is problem with a substation controlling a particular geographic region of homes, the grid head-end systems may elect to send a particular command to this region of home meters to adjust their operation in light of upstream grid issues. There may be some mapping of multicast address to geographic region so that meters can use their GPS location to automatically derive what multicast address to subscribe to. Hope this helps Randy On 10/15/14, 4:08 PM, "Carsten Bormann" wrote: >Hi Don, > >this sounds exactly like a use case our multicasting approach can solve. > >Two questions: > >1) Are you using storing or non-storing mode for RPL? > >2) For the kinds of groups below, was is the likely distribution of group >sizes? > >Gr=FC=DFe, Carsten > >On 15 Oct 2014, at 18:58, Don Sturek wrote: > >> 4) From an application point of view, we want to use special >>application-defined multicast groups for things like: >> A. Control a geographic collection of street lights (like all >>the ones in an area where there is to be a festival this evening) >> B. Control a geographically diverse collection of devices >>that are not the entire population (for example, I want a message sent >>to all of my pre-pay customers which are mainly focused in some >>neighborhoods, less in others) > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. From nobody Wed Oct 15 13:33: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 90D7E1A8961 for ; Wed, 15 Oct 2014 13:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 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, MALFORMED_FREEMAIL=2.511, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9q1i8e88LZu for ; Wed, 15 Oct 2014 13:33:20 -0700 (PDT) Received: from nm21-vm3.access.bullet.mail.gq1.yahoo.com (nm21-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.79]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653BE1A7001 for ; Wed, 15 Oct 2014 13:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413405200; bh=YDSRjoIbW5nBhg8xBOpxKNZxvpW1dZjzemxnvICNbNk=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=JaqqmQJMAXqc3oPD/a6YEIKNmgrCayVEOH3aqcGOYEY8eyajFvqrZjfGkJOSMf8s8IYO45ByPNkYjAdzmDUZT1Ahjge0zVTtkUkFe1F3svAOiVeMOWF9nXDefQHiphbFNE7US+afa1in4DWwohObFgggdCIY83YyU4ebYxlIz2s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=Mu1KVN1F7Sd7ZF5vAOzd7w3KBUkyzD38m41kUMDS2Wn5bOFQXIvbQd02HQ3oRJfyfonoH0KDWN+taXphTJ9ynbl0h5/X1lTdiXEBNOi5EiJxIAg4Ar7mVt7Dt3VCxKejOba4H4tJ4VVShLpVNdN2hPIAOU1QKz09YrJudGxId/Q=; Received: from [216.39.60.176] by nm21.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2014 20:33:20 -0000 Received: from [98.138.226.242] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2014 20:33:19 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 15 Oct 2014 20:33:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413405199; bh=YDSRjoIbW5nBhg8xBOpxKNZxvpW1dZjzemxnvICNbNk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=oZ5OkmhJPjM6MghJN5FTZwyl41r8qBW7kc/jBgIvQ6Te7sKLGBhREPCO4DBFbfESp1OZZqI+J4VL5v3jQpmqEecO10VgynfbshmyzX4uwn+x9gKTX7e99vtLPRIJJNkHIYH+q3iWx2X4UnccMMDF0rd/3rRFfq4WbGABDc6ZDjI= X-Yahoo-Newman-Id: 786303.87599.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2YU6cbIVM1nh6fIqXe7WvOJNL4e4AaiCU8mQvxnrevwNvq8 Ty_aS8Na6krSEX1XEdd0wADCRkuwCiDIVZeDtFJ49QBt0b4zQz26xh5Dg_iX vz7VcZfmwsH2Js6Wg9rjoK.PjtUG124iKV0fkkCyGt8d0w1oYDZPdTbgH5Qt T_X_0iUX8qphC9A6ykYJuchTZaJvX5yxTS_G1Ti23wgvkpOzVHW3AUuqPRCW NZqw2dPhTkkxUhgMo.rrzxiT5_Vsp18VgBONl.rvWzov8WVwsGvhBpEfrxU0 CD723fD8pzv1QfdGAuMkaJnX_CZphHTn9MLanDOMAcRWW_hmZAgEfrAGGDJT OB0SuBJgqHHIJ90rUAJ0Upavae8IO9lx1ZJrXOgjL8bKG4fVyqdCHK75UPip RgFctmrjTuNzF99OBFI7SZoLuyb.x89fMtrAiOIv8WjVNhFHvaFL8lBBfFpK E7jP9g4c.b9AmpZ4LyFk9M8X6Xmw2qI7XpaRTcTWD67UrRdM3wO4Lw3GFyG. oaCjub1IwW6M4eEG0M_r1qz.QCZ.GmDeM8Fx8JzaW X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 13:33:16 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] multicast & MLD on LLN References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/dUijpjgHNaAVmhojCcZNPMwv8Ys Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 20:33:21 -0000 .... By the way, I worked on an application using IPv4 multicast that worked nicely as defined below. My previous company did the original IP-enabling for NASDAQ. There were tiers of service that mapped to IPv4 multicast groups. Of course with the topological nature of IPv4, this was a much simpler problem (plus not having an LLN in the middle). The key feature was the ability to opt-in/opt-out of the multicast groups and the ability for the network to route traffic appropriately depending on membership of the multicast group. Hopefully we can come up with something similar..... Don On 10/15/14 1:23 PM, "Don Sturek" wrote: >Hi Carsten, > >On your questions posed below: >1) We are using non-storing >2) Distribution of group sizes. This is a tough question. I think >some=20 >groups may be nearly the size of the entire network (say I want to send a >message to all of my smart meters but don't need the relays or AP's to >get=20 >the message). Some may be regionally focused and therefore small (eg, I >have an outage and I want the smart meters in one location to report on >the quality of the electric service they are seeing). Some may be >geographically focused (like the example for the street light application >wanting to manage street lights around a festival). I think the right >answer here is we want applications to opt in/opt out of application >multicast groups and we want the network forwarding to be smart enough to >not flood the entire network if that is not needed. I know that is not >the answer you are particularly looking for but I think that is the right >answer. By the way, if I have an application multicast group that is >nearly the entire population of the network, it would be really great if >the network operator knew this and reduced those types of multicast >transmissions. The biggest savings would be where we really only want >to=20 >hit devices in a certain georgraphy and now we don't need every device in >the network to see that traffic..... > >If we do this right, then we will arm the application developers with the >ability to create their own groups (with some knowledge/understanding >from=20 >the network operator) and the ability for the forwarding of the multicast >traffic to avoid saturating the network with broadcast traffic that is >not=20 >needed for that application multicast group. > >Don > > > >On 10/15/14 1:08 PM, "Carsten Bormann" wrote: > >>Hi Don, >> >>this sounds exactly like a use case our multicasting approach can solve. >> >>Two questions: >> >>1) Are you using storing or non-storing mode for RPL? >> >>2) For the kinds of groups below, was is the likely distribution of >>group=20 >>sizes? >> >>Gr=FC=DFe, Carsten >> >>On 15 Oct 2014, at 18:58, Don Sturek wrote: >> >>> 4) From an application point of view, we want to use special >>>application-defined multicast groups for things like: >>> A. Control a geographic collection of street lights (like >>>all=20 >>>the ones in an area where there is to be a festival this evening) >>> B. Control a geographically diverse collection of devices >>>that are not the entire population (for example, I want a message sent >>>to all of my pre-pay customers which are mainly focused in some >>>neighborhoods, less in others) >> >>_______________________________________________ >>Roll mailing list >>Roll@ietf.org >>https://www.ietf.org/mailman/listinfo/roll From nobody Wed Oct 15 13:38: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 253D61ACCEE for ; Wed, 15 Oct 2014 13:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy26X3u8nbDc for ; Wed, 15 Oct 2014 13:38:41 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ADC1ACD0F for ; Wed, 15 Oct 2014 13:38:41 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id uy5so1749605obc.13 for ; Wed, 15 Oct 2014 13:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=jioFb873K3mryi2ughIRA6eR03J5SHZ8PUkawI8hdwQ=; b=A74FDYbeqftltc9WBfi8e2xSGeW0OlIK1dB4+o+cAg+ZBwZLYYG38fs2P56dMomt4h 2MGQYK5FcXV66I3vxGZYb4XHIxwWqiMQknVauHdQ1Qepu+J3pydhdyAjmQGcH7qU92Yh cbEyi1tTM+cGMIHt/CygMYsYrofEbwqnqs9JQC9olWZrdwMvRPaAc/Ij21yge0nSS2gS yn/2qVb0coA4jU4lTOlmiN3XaN1t3xgH5Ub0OmmaT4BoM+RnFAMcpEWCLulvsa8Y+M9T z0V5e3Q1IpDRHfmmkNZIBGgnC+3Fgcu8TIhxgETX/59Z4CAKfTcMpPv1+8Y7aGh5cZB4 BT5g== MIME-Version: 1.0 X-Received: by 10.202.179.10 with SMTP id c10mr2852795oif.102.1413405520533; Wed, 15 Oct 2014 13:38:40 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.15.129 with HTTP; Wed, 15 Oct 2014 13:38:40 -0700 (PDT) In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> Date: Wed, 15 Oct 2014 16:38:40 -0400 X-Google-Sender-Auth: QqHnjbc-1rpbaDjAmr3DnIYDG0M Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a113ce148f9a77f05057c1d36 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hVQnN9UM-e-dS8iW1ot-A22PC68 Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 20:38:43 -0000 --001a113ce148f9a77f05057c1d36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 4:27 PM, Turner, Randy wrote: > Hi Pascal, > > This multicast use-case is similar to the street light group use-case, > except aimed at the AMI grid network: > > There is of course a need to multicast firmware updates to devices in the > smart grid. In that example (and in other AMR use-cases) all devices in > the network subscribe to a common multicast address =E2=80=B9 it=C2=B9s r= eally a > broadcast, if all devices need to be updated at the same time, with the > same firmware. > > Surely you'd want to do OTA updates in a secure fashion? Does this highlight a need for secure multicast? > Then there is a multicast group scenario where, say, only 500 of 5000 > nodes need to be updated (possibly associated with a geographic region of > the grid) > > THere=C2=B9s also a region-oriented multicast group address that could be= used > to send control/management information to a particular set of smart meter= s > in the field. For instance if there is problem with a substation > controlling a particular geographic region of homes, the grid head-end > systems may elect to send a particular command to this region of home > meters to adjust their operation in light of upstream grid issues. > > There may be some mapping of multicast address to geographic region so > that meters can use their GPS location to automatically derive what > multicast address to subscribe to. > > Is the GPS position manually configured in the meter? If so, perhaps manual configuration of multicast group address is just marginally more expensive. It could also be the case that multicast group addresses are named objects. For example, one could assign DNS names to groups and resolve this to a AAAA record (just as with unicast addresses) or use DNS-SD to find a multicast service binding. -K- > > Hope this helps > Randy > > > On 10/15/14, 4:08 PM, "Carsten Bormann" wrote: > > >Hi Don, > > > >this sounds exactly like a use case our multicasting approach can solve. > > > >Two questions: > > > >1) Are you using storing or non-storing mode for RPL? > > > >2) For the kinds of groups below, was is the likely distribution of grou= p > >sizes? > > > >Gr=C3=BC=C3=9Fe, Carsten > > > >On 15 Oct 2014, at 18:58, Don Sturek wrote: > > > >> 4) From an application point of view, we want to use special > >>application-defined multicast groups for things like: > >> A. Control a geographic collection of street lights (like al= l > >>the ones in an area where there is to be a festival this evening) > >> B. Control a geographically diverse collection of devices > >>that are not the entire population (for example, I want a message sent > >>to all of my pre-pay customers which are mainly focused in some > >>neighborhoods, less in others) > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legall= y > privileged. If you are not an intended recipient or an authorized > representative of an intended recipient, you are prohibited from using, > copying or distributing the information in this e-mail or its attachments= . > If you have received this e-mail in error, please notify the sender > immediately by return e-mail and delete all copies of this message and an= y > attachments. Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a113ce148f9a77f05057c1d36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 15, 2014 at 4:27 PM, Turner, Randy <Randy.Turner@landisgy= r.com> wrote:
Hi Pascal,
This multicast use-case is similar to the street light group use-case,
except aimed at the AMI grid network:

There is of course a need to multicast firmware updates to devices in the smart grid. In that example (and in other AMR use-cases) all devices in
the network subscribe to a common multicast address =E2=80=B9 it=C2=B9s rea= lly a
broadcast, if all devices need to be updated at the same time, with the
same firmware.

Surely you'd want to do OTA updates in a secure f= ashion?=C2=A0 Does this highlight
a need for secure multicast?
=C2=A0
Then there is a multicast group scenario where, say, only 500 of 5000
nodes need to be updated (possibly associated with a geographic region of the grid)

THere=C2=B9s also a region-oriented multicast group address that could be u= sed
to send control/management information to a particular set of smart meters<= br> in the field. For instance if there is problem with a substation
controlling a particular geographic region of homes, the grid head-end
systems may elect to send a particular command to this region of home
meters to adjust their operation in light of upstream grid issues.

There may be some mapping of multicast address to geographic region so
that meters can use their GPS location to automatically derive what
multicast address to subscribe to.

Is the GPS position manually configured in the meter?= =C2=A0 If so, perhaps manual
configuration of multicast group add= ress is just marginally more expensive.

It could a= lso be the case that multicast group addresses are named objects.
For example, one could assign DNS names to groups and resolve this to a
AAAA record (just as with unicast addresses) or use DNS-SD to find = a
multicast service binding.

-K-=C2=A0

Hope this helps
Randy


On 10/15/14, 4:08 PM, "Carsten Bormann" <cabo@tzi.org> wrote:

>Hi Don,
>
>this sounds exactly like a use case our multicasting approach can solve= .
>
>Two questions:
>
>1) Are you using storing or non-storing mode for RPL?
>
>2) For the kinds of groups below, was is the likely distribution of gro= up
>sizes?
>
>Gr=C3=BC=C3=9Fe, Carsten
>
>On 15 Oct 2014, at 18:58, Don Sturek <d.sturek@att.net> wrote:
>
>> 4)=C2=A0 From an application point of view, we want to use special=
>>application-defined multicast groups for things like:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A.=C2=A0 =C2=A0 Control a geographic co= llection of street lights (like all
>>the ones in an area where there is to be a festival this evening) >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 B.=C2=A0 =C2=A0 Control a geographicall= y=C2=A0 diverse collection of devices
>>that are not the entire population (for example, I want a message s= ent
>>to all of my pre-pay customers which are mainly focused in some
>>neighborhoods, less in others)
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


P PLEASE CONSIDER OUR ENVIRONMENT BEF= ORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you.

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

--001a113ce148f9a77f05057c1d36-- From nobody Wed Oct 15 14:17:03 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 684DE1ACD9D for ; Wed, 15 Oct 2014 14:16:59 -0700 (PDT) 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 W9lSCIpWSrd9 for ; Wed, 15 Oct 2014 14:16:58 -0700 (PDT) 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 5D9881ACD1D for ; Wed, 15 Oct 2014 14:16:58 -0700 (PDT) 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 s9FLGtvo018789 for ; Wed, 15 Oct 2014 23:16:55 +0200 (CEST) Received: from [192.168.217.145] (p5489134F.dip0.t-ipconnect.de [84.137.19.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2E0F7A7A; Wed, 15 Oct 2014 23:16:55 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Oct 2014 23:16:53 +0200 X-Mao-Original-Outgoing-Id: 435100613.391469-b12c171cbd81708fea21f47266f3ebb0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/j_XVpVMS9g7GGR38qYMtR8qvzhY Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 21:17:00 -0000 On 15 Oct 2014, at 22:38, Kerry Lynn wrote: > Surely you'd want to do OTA updates in a secure fashion? Does this = highlight > a need for secure multicast? What is the security objective here? If it is integrity/authenticity, this is best done with object security = on the OTA image, which also can provide confidentiality for the bits in = the OTA image. (I don=92t think there is a need [or even a way] to keep the fact that = an OTA update is occurring confidential.) Gr=FC=DFe, Carsten From nobody Wed Oct 15 14:49: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 8A55B1ACDD8 for ; Wed, 15 Oct 2014 14:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 8xoOXq7LLGcf for ; Wed, 15 Oct 2014 14:49:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::709]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1311ACDC3 for ; Wed, 15 Oct 2014 14:49:04 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 21:48:41 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 21:48:41 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8AAX0deAAACcwoAA3HB9gAAAUc4AAADViYAAAH71gAAArNuAAAaploD//8ISAIAARkAAgAAKrYD//8XSgA== Date: Wed, 15 Oct 2014 21:48:40 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> 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.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2.228.114.172] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(51704005)(377454003)(479174003)(189002)(120916001)(95666004)(4396001)(99396003)(76482002)(46102003)(20776003)(93886004)(64706001)(66066001)(2656002)(85306004)(87936001)(97736003)(83506001)(15975445006)(19580405001)(19580395003)(31966008)(36756003)(21056001)(80022003)(107886001)(122556002)(92726001)(85852003)(105586002)(86362001)(101416001)(106356001)(76176999)(40100003)(110136001)(107046002)(92566001)(50986999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zEFkIUq5mswLgPZGMMLUiHINTGk Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 21:49:06 -0000 I=B9m not saying confidentiality isn=B9t an issue with updates, but I think it=B9s more important that the integrity of the image be correct, and that the image is appropriate for the target =8B- both of these concerns can be handled at the application layer =8B multicast is just the transport. Randy On 10/15/14, 5:16 PM, "Carsten Bormann" wrote: >On 15 Oct 2014, at 22:38, Kerry Lynn wrote: > >> Surely you'd want to do OTA updates in a secure fashion? Does this >>highlight >> a need for secure multicast? > >What is the security objective here? >If it is integrity/authenticity, this is best done with object security >on the OTA image, which also can provide confidentiality for the bits in >the OTA image. >(I don=B9t think there is a need [or even a way] to keep the fact that an >OTA update is occurring confidential.) > >Gr=FC=DFe, Carsten > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. From nobody Wed Oct 15 14:57: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 DAAA51ACD3E for ; Wed, 15 Oct 2014 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vnog-IGwO9t for ; Wed, 15 Oct 2014 14:57:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522C21A00E4 for ; Wed, 15 Oct 2014 14:57:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3B0512002D; Wed, 15 Oct 2014 17:57:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2EB3763B40; Wed, 15 Oct 2014 17:56:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1C28C63B3F; Wed, 15 Oct 2014 17:56:59 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> 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/_Ne89BjncDpNe1Pg992FmO0ynKU Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 21:57:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kerry Lynn wrote: > On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann wrote: >> Right, MLD is a host-router protocol. Routers among them speak a >> routing protocol, so they wouldn=E2=80=99t exchange MLD. (A RPL =E2= =80=9Cleaf=E2=80=9D is a >> router.) >> >> > Finally I'm looking at BIER see how their ideas could apply to LLN= s=E2=80=A6 >> >> Yep. We (TZI) have done (specified, implemented, analyzed) an >> efficient BIER-like multicast forwarding protocol for non-storing mo= de >> a while ago. >> > I admit to some confusion here. Is (topology-free) MPL no longer the > default multicast forwarding protocol for LLN? I don't know anything about BIER really... MPL is still the default at this= point. (proceedural delays getting trickle-mcast out, not-with-standing) My take on the conversation is that BIER has some kind of helper node that unicasts everything out as appropriate. =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) iQEVAwUBVD7tqoCLcPvd0N1lAQLx3QgAohErcrBjR7nhSQD9B8QJMBFPsZeP/cxC EjvBjD2GiH/C9uuO9JWv9Zsg6Gq37Vhv8rkCKxhwWiAMvKkudpX2Xol/QvTeopzh JsrMYqwdfszSIOhGn3HrWmrsfW2Ztnl8iV244UFmuazGyVZFMpNKz5h09jxj3Gix eiMeB8SmkRkUtT3eAjdhLj5aBrW+grux3qD572FPVgJH5dLTqHHATpf2q92YpiLe obxD5Wt3fs3C2oWMSvUt/MLjpVZ7Cvzzpw4iv0QhKOwYyhfttREACAnRcJg1XFMe HwkGkTN1gUrKyZJLdcIQEfi9TczjdtPCbTyBFy4AkyF0XvkhSvDOKw== =hI0V -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 15 15: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 146F51ACDDA for ; Wed, 15 Oct 2014 15:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eUrnJDPn8zX for ; Wed, 15 Oct 2014 15:00:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0731B1ACDDC for ; Wed, 15 Oct 2014 15:00:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 41A842002D; Wed, 15 Oct 2014 18:00:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DBEFC63B40; Wed, 15 Oct 2014 18:00:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C17A163B3F; Wed, 15 Oct 2014 18:00:18 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> 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/Qs1F4XXZCyuCTig1awebgGbBtKk Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 22:00:22 -0000 --=-=-= Don Sturek wrote: > Let me try to provide a use case. Thank you. > The network is a Neighborhood Area Network. The application can be > something like street lights or a smart metering AMI (really any > collection of devices that are networked centrally with a non-trivial > number of devices in the network) ... > What would be great in the above scenario is if the multicast traffic > only traversed the portions of the network where members of the > multicast group exist (eg, don't forward down portions of the tree > where there are no multicast members). MPL as a flooding mechanism > fails this goal (which is fine with relatively few devices but not so > when talking about 5000 devices/24 hops! > Is the above good enough to start a discussion on how to solve the > problem? could you write this in the form of a requirements draft? Even if it just has the above three paragraphs... :-) -- 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) iQEVAwUBVD7ucoCLcPvd0N1lAQIUawf/cETY0Z4CnMWqR/PP8fjk3o0IxJeaC5/W Rbizs0iLq+KL4zrsYcPHCTuGDTsLgLFVbOg073TCMQNFfHgW0EYniGGijYolRi1f kDczf9UVCO0eh0VeWg7PNM6Na9LPiwswwyOCz+Op8hOmNmRamZ1Q2zSb73FX+5Mj hklRGCml7FcGraNGZqtnfG070zqGeOYXeuJZLdQqJpsmJ+NKb2+mTdpqN67os+Jq FfwVRQcjmIG27j5vXoM55V/JVTMxZtgSHn4KvSAlyoQzxbVOwVRCo4fVJND10B+p +6mTElRqDu5TrWlvP5bzI686TxK5nqvkLPeXbEhe4aFHLOzyhu7BpA== =bMEH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 15 15:02: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 0FA301ACDE6 for ; Wed, 15 Oct 2014 15:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-Sj2gMndjN6 for ; Wed, 15 Oct 2014 15:02:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890731ACDC9 for ; Wed, 15 Oct 2014 15:02:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 09AB12002D; Wed, 15 Oct 2014 18:02:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B85EF63B40; Wed, 15 Oct 2014 18:02:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A10C663B3F; Wed, 15 Oct 2014 18:02:27 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <23BA6593-C10E-4E30-8769-77C37A5480CB@landisgyr.com> References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> , <23BA6593-C10E-4E30-8769-77C37A5480CB@landisgyr.com> 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/EOeu9O75VEUsuaIXNJk-S1mHzRQ Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 22:02:30 -0000 --=-=-= Turner, Randy wrote: > It might be nice to have a document that "rolls up" the best ideas from > these documents into a guide for developers. For instance, "cherry > picking" mechanisms across RFCs 6775, 6550, etc to produce a definitive > way to deliver a solution that can scale to thousands of nodes, or > gracefully backdown its capabilities to address smaller home > environments This is called an applicability statement. Getting this out the door is the last thing this WG has to done, and why we are still alive. -- 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) iQEVAwUBVD7u84CLcPvd0N1lAQJ8hwf/SalCl2SmZoPCG+MhQLXBuAPVxqdTOP+d xx/EWopXTsbzq2mmKDCtq0kYsoUlZw3N0b7d5V6hvVDCjl8yFAXBXPmhVvJEPxvl DmR0xBd7SCm22dD/x6y/XqEDN3+0mRyjck7GDuLZke6pW3Azrq3DWATaUEuDMqZs yScMUuh62w/p8hJtUlorvIQ9Q+o/VhhfliYb9ZOAdLRIvvhSk1AojbB9ObvYBovW RFamyDWoEdBaHjCJklgLC+wudmbmPNQRUh5RuaqOx2PeWVIlmZjtGceEHlRehgIR g5CYqdg16eNL0Alw/J1XKOK41jSbFdZ7XWueVTaeWrF+OJL3+o04tw== =N1mC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 15 15:06:19 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 9361F1ACDEA for ; Wed, 15 Oct 2014 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI9p1b0SfCDy for ; Wed, 15 Oct 2014 15:06:08 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A7E1ACDED for ; Wed, 15 Oct 2014 15:05:54 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id m8so1907307obr.0 for ; Wed, 15 Oct 2014 15:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=6cQtmAW3unUXuwinDSbo9PfX98oSmsouvsWHGPjBXoQ=; b=ioYuSpf0thmDQgLEwBCKA6CQ75BAbNbHsDuLlYiF1DauYJLpFpCJ9XW6a0YFcTCZMV cPKHOpVpL4nI1PLAdvtW5AS3PMeOYlZc6MC6JdVAC6oWEi9jHRRL1OczdY2tGEF0hzuS UHZi+fOxh00L2bGyoqkqSPgaru+eYGFOqm451ocVrYqI/ZokZEapNWn7rYNub37CUwkJ vzpL28dBkRw8eA9HIYlO4Mtbgl2pSMclpk5U5rdg812fiV7We3JC/nmSNl+MWrl/+P7d wBYgmOB+r+0aSPk2YZPa8GE7El9SF0HEsdATn3Wn+ss0wY/uINDfMxabcUToifK5Pua/ jqPg== MIME-Version: 1.0 X-Received: by 10.60.47.100 with SMTP id c4mr13634569oen.9.1413410754398; Wed, 15 Oct 2014 15:05:54 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.15.129 with HTTP; Wed, 15 Oct 2014 15:05:54 -0700 (PDT) In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <73405C1D-6BD2-4030-8AE9-11B0EDBCE308@tzi.org> Date: Wed, 15 Oct 2014 18:05:54 -0400 X-Google-Sender-Auth: _OO-Ej9r69mDeVMhVCpSBgLXT2I Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c20b2cf00fa605057d552a Archived-At: http://mailarchive.ietf.org/arch/msg/roll/dHEk6MLc_EZQFTupo9dRGJMqFts Subject: Re: [Roll] multicast & MLD on LLN 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, 15 Oct 2014 22:06:09 -0000 --001a11c20b2cf00fa605057d552a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 5:16 PM, Carsten Bormann wrote: > On 15 Oct 2014, at 22:38, Kerry Lynn wrote: > > > Surely you'd want to do OTA updates in a secure fashion? Does this > highlight > > a need for secure multicast? > > What is the security objective here? > If it is integrity/authenticity, this is best done with object security o= n > the OTA image, which also can provide confidentiality for the bits in the > OTA image. > Yes, and also authorization (although perhaps this is implied by authentication). -K- > (I don=E2=80=99t think there is a need [or even a way] to keep the fact t= hat an > OTA update is occurring confidential.) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11c20b2cf00fa605057d552a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 15, 2014 at 5:16 PM, Carsten Bormann <cabo@tzi.org> wrot= e:
On 15 Oct 2014, at 22= :38, Kerry Lynn <kerlyn@ieee.org&= gt; wrote:

> Surely you'd want to do OTA updates in a secure fashion?=C2=A0 Doe= s this highlight
> a need for secure multicast?

What is the security objective here?
If it is integrity/authenticity, this is best done with object security on = the OTA image, which also can provide confidentiality for the bits in the O= TA image.

Yes, and also authorization (= although perhaps this is implied by authentication).

-K-
=C2=A0
(I don=E2=80=99t think there is a need [or even a way] to keep the fact tha= t an OTA update is occurring confidential.)

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

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

--001a11c20b2cf00fa605057d552a-- From nobody Thu Oct 16 00:17: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 CD4301A037A for ; Thu, 16 Oct 2014 00:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, 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 LyMzxwxkdAlR for ; Thu, 16 Oct 2014 00:17:21 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925791A036C for ; Thu, 16 Oct 2014 00:17:20 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9G7HAV3057971; Thu, 16 Oct 2014 09:17:11 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-252-223.w92-133.abo.wanadoo.fr ([92.133.143.223]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Oct 2014 09:17:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Oct 2014 09:17:10 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> Message-ID: <8024d634f6820545d3d8200fc3585572@xs4all.nl> X-Sender: stokcons@xs4all.nl (bvZrQqdYbumAwowfrPrVP+vbB9fvg2yG) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/z9ObaXegGXSZvVjAniqDHx4SIUM Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 16 Oct 2014 07:17:24 -0000 Hi Don, > 5) I don't want to incur the MPL overhead of all multicast traffic > flooding all 5000 devices/forwarded up to 15 hops in my network when I > send these special multicast group messages. I think this is possible with current MPL by managing which nodes are MPL forwarders. First requirement is to select a multicast address per group of destination nodes. Second, enable the interfaces for a selection of nodes which are supposed to forward and which are supposed to receive only messages with this particular MC address. Today, this must be done by hand. Automating it is an option. Peter Don Sturek schreef op 2014-10-15 18:58: > Hi Pascal, > > Let me try to provide a use case. > > The network is a Neighborhood Area Network. The application can be > something like street lights or a smart metering AMI (really any > collection of devices that are networked centrally with a non-trivial > number of devices in the network) > > Here are some details: > 1) Around 5000 devices in the network total. There can be as many as > 15 hops from the DODAG to the furthest leaf node in the network. > 2) One border router that supports ROLL RPL. All devices in the > network are ROLL RPL aware (some as routers, some end devices). What > would be really nice is if we could have non-RPL aware end devices > also in the network but I think that is another topic :-) > 3) We support all of the mandatory multicast groups (eg all routers) > in our networked devices > 4) From an application point of view, we want to use special > application-defined multicast groups for things like: > A. Control a geographic collection of street lights (like all the > ones in an area where there is to be a festival this evening) > B. Control a geographically diverse collection of devices that are > not the entire population (for example, I want a message sent to all > of my pre-pay customers which are mainly focused in some > neighborhoods, less in others) > 5) I don't want to incur the MPL overhead of all multicast traffic > flooding all 5000 devices/forwarded up to 15 hops in my network when I > send these special multicast group messages. > > What would be great in the above scenario is if the multicast traffic > only traversed the portions of the network where members of the > multicast group exist (eg, don't forward down portions of the tree > where there are no multicast members). MPL as a flooding mechanism > fails this goal (which is fine with relatively few devices but not so > when talking about 5000 devices/24 hops! > > Is the above good enough to start a discussion on how to solve the > problem? > > Don > > From: "Pascal Thubert (pthubert)" > Reply-To: Routing Over Low power and Lossy networks > Date: Wednesday, October 15, 2014 9:38 AM > To: Routing Over Low power and Lossy networks > Cc: "IJsbrand Wijnands (iwijnand)" > Subject: Re: [Roll] multicast & MLD on LLN > > Hello Kerry: > > Or Roll Multicast Operations ( : ROLLMOps? : ) > > Basically, BIER needs a preexisting tree structure and RPL is designed > to build and maintain one. They need a root node and we have one. > > On paper it is a perfect match. Now the question is whether there is > enough need for that work, and then we'll find a place to make it > happen. > > To start with, would you have a specific use case of multicast in LLNs > where MPL is less applicable than the classical tree-based forwarding? > > With that, we could connect into the BIER effort. > > Strong points: > > - very limited state in the nodes, could even be used for unicast, > independent on the number of groups and the size of the network > > - bit aggregation easy to advertise in existing DAOs, low cost there > too > > - transparent support for v4 and v6 (since it is an overlay) > > Weak points: > > - extra encapsulation (since it is an overlay) > > - new routing and forwarding operation to implement in the nodes > (bitwise) > > - limited number of nodes per DODAG (roughly 100). > > Cheers, > > Pascal > > FROM: Roll [mailto:roll-bounces@ietf.org] ON BEHALF OF Kerry Lynn > SENT: mercredi 15 octobre 2014 18:25 > TO: Routing Over Low power and Lossy networks > CC: IJsbrand Wijnands (iwijnand) > SUBJECT: Re: [Roll] multicast & MLD on LLN > > On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) > wrote: > > Or form a new group J > > What about Routing Over Complete Kaos? > > More seriously, it's probably a good idea to goto through the BoF > sequence again to analyze what's left to be done. > > I can certainly see an analog of what the 6lo is to 6LoWPAN, but for > ROLL. > > For me the first question is whether multicast in the LLN would be > RPL- > > dependent, or have RPL-like features (e.g. dependence on a DODAG). > > That could argue for doing the work in ROLL or a follow on group > > (ROLLMAN?) > > At least some of the 6lo proposals (MS/TP comes to mind) are not mesh > > networks, but still constrained from a host and bandwidth perspective. > > I like the topology-independence of MPL, but I think work still needs > to be > > done to see how far it is from optimal (in terms of energy and > bandwidth > > usage) under different operating conditions and parameter settings. > > -K- > >> Cheers, >> >> Pascal > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll [1] > > Links: > ------ > [1] https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 16 05:39: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 3D3661A1AC9 for ; Thu, 16 Oct 2014 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 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, MALFORMED_FREEMAIL=2.511, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-_GG3n86lbz for ; Thu, 16 Oct 2014 05:39:08 -0700 (PDT) Received: from nm10-vm1.access.bullet.mail.bf1.yahoo.com (nm10-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.208]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283F51A0360 for ; Thu, 16 Oct 2014 05:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413463147; bh=p+ZMu4Uaq5Se2zc9bMJU88Onc0mqqOBvhtZu+29rIB8=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=nWJqxAzWY/RYb22vItth8mTefMFBqeTvPxz8NncpFkU/9s41/MnHiKi9/TjdKdzbV3cpG00ErqLOQ2rmxB5vT0Qw5AvqnehY4rPEsP0QuDSPL/S/pqQeN0Qqn6uRTfK+vf4/u7PJ0PpqDvXU696dswXHkEycL0faFWjrxq+C4jc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=zkKxEilTqtMMfXAy/vLwclGpB9RbyhEaTfkJ/9BxA+y/jyU71VqyGxlNp4uMMV/XiEYsRi0S+QaN+ns2U3baFRvh3k5UR6LxizW/DPeRviFGNEqlO+ANXavpi15pXqKMi9oVJc0dKzw86tDJE+vimzIWkrqztNuQvgFkcC0+LTY=; Received: from [66.196.81.165] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2014 12:39:07 -0000 Received: from [98.138.226.240] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2014 12:39:07 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 16 Oct 2014 12:39:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413463147; bh=p+ZMu4Uaq5Se2zc9bMJU88Onc0mqqOBvhtZu+29rIB8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=x43nyTVKhkrAiOXZGJnvNTc0RqZMzADM7kP0x+AnNfBnd6tT76gq677/UySEPvTVvsvfEpVxyOCnGOmocpv1BzeFSPOtC1500SNjPTM0N/KOyUleKe4oaqngbDbf+5qdGkX+4EZSl+2l4z3wwqywIJLiibwW6ZiWh8wYY1dDMsM= X-Yahoo-Newman-Id: 202670.18753.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: wLG87EQVM1lVCmaQkAhKOjdUiyQo81JYvjGvmeVyU0TWykY TBonXEu3ugpHg6kM2dxirN7co9BGdtn2trvNKuvV11DfoBN9iiE1w_agVq0b 5eNsIqCzUuhHuunFxFKwCfO4NOQGhMK6S.QLmvwAYNRsCkGGGfSWXHqbkBwV yInZ1Y9WwdWWAGTLvoveOGB6oURlXFpxhRsGNSlAveHTEc_QMnkNJThLva94 37WKTZSAmpd1SDfGWkdBrHmK1T5ZCKWxWsw.xs305O7J5OQ3ijPNOpAT85IS MAPHuA4ZmdQ6SwIhciTrQ1ES7pBOuo8HvgMwkzj7RlJwWJ6P.mQ0yoOO8SXp qr8JVGC0s0BJWyTOQvBv5lbi0GbCwX3lYWk7kgMd.dtFUekLsHj0Rh9_s4Nk I4UmSOrXf37aak5EKZ42mvr_lY6N49ilY7n7CLZdd4wM8Kr6pr7JBpTu_rtT tmjkdfVuF.ETNxjs0DE_edxMjEPvkAUmdhZdkChtFLiA13g6HVxJr8GBdPdQ ZkdgAsbJb9pJ8_Z4_OuQapY1i_Q1xxAN0gtAQzw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Thu, 16 Oct 2014 05:39:00 -0700 From: Don Sturek To: , Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] multicast & MLD on LLN References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <8024d634f6820545d3d8200fc3585572@xs4all.nl> In-Reply-To: <8024d634f6820545d3d8200fc3585572@xs4all.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/G90u6uu-cXWHrMPAfWPokWtQjxQ Cc: "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 16 Oct 2014 12:39:10 -0000 Hi Peter, I really don't see how in MPL we could configure routers which may not be multicast group members to forward unless they are somehow provided information that the forwarding path has multicast group members that need the message. Even if we somehow hand configured them to forward certain multicast group packet streams, that would fail if the device changes rank. In addition, we could not create new multicast groups and have the device understand whether or not forwarding was needed. One thing I saw when using application multicast groups in IPv4: Once the application developers realized how the multicast groups worked, they created more of them as time went on. For the AMI/smart city applications we are working on, I really think most of the application multicast group definition will occur after the system is deployed and developers realize (hopefully!) how efficient it is to use targeted application multicast groups. Don On 10/16/14 12:17 AM, "peter van der Stok" wrote: >Hi Don, > >> 5) I don't want to incur the MPL overhead of all multicast traffic >> flooding all 5000 devices/forwarded up to 15 hops in my network when I >> send these special multicast group messages. > > >I think this is possible with current MPL by managing which nodes are >MPL forwarders. >First requirement is to select a multicast address per group of >destination nodes. >Second, enable the interfaces for a selection of nodes which are >supposed to forward and which are supposed to receive only messages with >this particular MC address. > >Today, this must be done by hand. >Automating it is an option. > >Peter > >Don Sturek schreef op 2014-10-15 18:58: >> Hi Pascal, >> >> Let me try to provide a use case. >> >> The network is a Neighborhood Area Network. The application can be >> something like street lights or a smart metering AMI (really any >> collection of devices that are networked centrally with a non-trivial >> number of devices in the network) >> >> Here are some details: >> 1) Around 5000 devices in the network total. There can be as many as >> 15 hops from the DODAG to the furthest leaf node in the network. >> 2) One border router that supports ROLL RPL. All devices in the >> network are ROLL RPL aware (some as routers, some end devices). What >> would be really nice is if we could have non-RPL aware end devices >> also in the network but I think that is another topic :-) >> 3) We support all of the mandatory multicast groups (eg all routers) >> in our networked devices >> 4) From an application point of view, we want to use special >> application-defined multicast groups for things like: >> A. Control a geographic collection of street lights (like all the >> ones in an area where there is to be a festival this evening) >> B. Control a geographically diverse collection of devices that are >> not the entire population (for example, I want a message sent to all >> of my pre-pay customers which are mainly focused in some >> neighborhoods, less in others) >> 5) I don't want to incur the MPL overhead of all multicast traffic >> flooding all 5000 devices/forwarded up to 15 hops in my network when I >> send these special multicast group messages. >> >> What would be great in the above scenario is if the multicast traffic >> only traversed the portions of the network where members of the >> multicast group exist (eg, don't forward down portions of the tree >> where there are no multicast members). MPL as a flooding mechanism >> fails this goal (which is fine with relatively few devices but not so >> when talking about 5000 devices/24 hops! >> >> Is the above good enough to start a discussion on how to solve the >> problem? >> >> Don >> >> From: "Pascal Thubert (pthubert)" >> Reply-To: Routing Over Low power and Lossy networks >> Date: Wednesday, October 15, 2014 9:38 AM >> To: Routing Over Low power and Lossy networks >> Cc: "IJsbrand Wijnands (iwijnand)" >> Subject: Re: [Roll] multicast & MLD on LLN >> >> Hello Kerry: >> >> Or Roll Multicast Operations ( : ROLLMOps? : ) >> >> Basically, BIER needs a preexisting tree structure and RPL is designed >> to build and maintain one. They need a root node and we have one. >> >> On paper it is a perfect match. Now the question is whether there is >> enough need for that work, and then we'll find a place to make it >> happen. >> >> To start with, would you have a specific use case of multicast in LLNs >> where MPL is less applicable than the classical tree-based forwarding? >> >> With that, we could connect into the BIER effort. >> >> Strong points: >> >> - very limited state in the nodes, could even be used for unicast, >> independent on the number of groups and the size of the network >> >> - bit aggregation easy to advertise in existing DAOs, low cost there >> too >> >> - transparent support for v4 and v6 (since it is an overlay) >> >> Weak points: >> >> - extra encapsulation (since it is an overlay) >> >> - new routing and forwarding operation to implement in the nodes >> (bitwise) >> >> - limited number of nodes per DODAG (roughly 100). >> >> Cheers, >> >> Pascal >> >> FROM: Roll [mailto:roll-bounces@ietf.org] ON BEHALF OF Kerry Lynn >> SENT: mercredi 15 octobre 2014 18:25 >> TO: Routing Over Low power and Lossy networks >> CC: IJsbrand Wijnands (iwijnand) >> SUBJECT: Re: [Roll] multicast & MLD on LLN >> >> On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) >> wrote: >> >> Or form a new group J >> >> What about Routing Over Complete Kaos? >> >> More seriously, it's probably a good idea to goto through the BoF >> sequence again to analyze what's left to be done. >> >> I can certainly see an analog of what the 6lo is to 6LoWPAN, but for >> ROLL. >> >> For me the first question is whether multicast in the LLN would be >> RPL- >> >> dependent, or have RPL-like features (e.g. dependence on a DODAG). >> >> That could argue for doing the work in ROLL or a follow on group >> >> (ROLLMAN?) >> >> At least some of the 6lo proposals (MS/TP comes to mind) are not mesh >> >> networks, but still constrained from a host and bandwidth perspective. >> >> I like the topology-independence of MPL, but I think work still needs >> to be >> >> done to see how far it is from optimal (in terms of energy and >> bandwidth >> >> usage) under different operating conditions and parameter settings. >> >> -K- >> >>> Cheers, >>> >>> Pascal >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll [1] >> >> Links: >> ------ >> [1] https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 16 05:54: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 030091A1A2F for ; Thu, 16 Oct 2014 05:54:37 -0700 (PDT) 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 mcN2sBbYYDhO for ; Thu, 16 Oct 2014 05:54:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3A41A1A27 for ; Thu, 16 Oct 2014 05:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5084; q=dns/txt; s=iport; t=1413464067; x=1414673667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CdeK5M/YBfVdquu/cBEIV8Uzdg1rBg0Ehe4QmsQ4EcQ=; b=fiUp28uMr6rT2fwOjWtcNFkQ/eVmIFmJtHN3Y4PhEeIksZELojpqtwzx JDXB7GzbNUlnwyRO7QtVd3QI20Az7d9XBgR/CuI5fgqeR7BG5Ge0wNmNz 2iWkAZlm8mL3/pRbMeG/wZot4el8MY+fyZNvil9BPCTNoqe3UEkd/8uOi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAEO/P1StJA2K/2dsb2JhbABbgw5TXIMCyRqHTQIbexYBfYQCAQEBBCMRRQwEAgEIDgMBAwEBAQICBh0DAgICMBQBAgYIAgQBDQUIiDYNtQmVIAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI5THTEHBoJxNoEeBZF/hEaIfpQwgX4ggVlsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208";a="363748399" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 16 Oct 2014 12:54:25 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9GCsPRd028240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 12:54:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.132]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 07:54:25 -0500 From: "Pascal Thubert (pthubert)" To: Don Sturek , "Turner, Randy" , Kerry Lynn Thread-Topic: [Roll] multicast & MLD on LLN Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxu7kcgADwEZA= Date: Thu, 16 Oct 2014 12:54:24 +0000 Deferred-Delivery: Thu, 16 Oct 2014 12:54:00 +0000 Message-ID: References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <29960.1413410219@sandelman.ca> In-Reply-To: <29960.1413410219@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AvfiD3Ua5wFjcG-VbKM4-Uk34X8 Cc: "Greg Shepherd \(shep\)" , Routing Over Low power and Lossy networks , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 16 Oct 2014 12:54:37 -0000 SGVsbG8gTWljaGFlbA0KDQpJIHRoaW5rIHRoYXQgc2F5aW5nIHRoYXQgTVBMIGlzIHRoZSBkZWZh dWx0IGlzIHF1aXRlIGV4YWdnZXJhdGVkLiANCg0KUlBMIGhhcyBhIGNsYXNzaWNhbCBtdWx0aWNh c3QgYnVpbHQgaW4sIHdoaWNoIGlzIGEgc2ltcGxlIGV4dGVuc2lvbiB0byBzdG9yaW5nIG1vZGUg KCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU1MCNzZWN0aW9uLTEyKS4gDQpUaGUg dHJvdWJsZSBpcyB0aGF0IHRoaXMgaGFyZGx5IGZpdHMgd2l0aCBub24tc3RvcmluZy4NCg0KQklF UiAoZHJhZnQtd2lqbmFuZHMtYmllci1hcmNoaXRlY3R1cmUtMDAudHh0KSBzZWVtcyBhbiBhcHBy b3ByaWF0ZSBhcHByb2FjaCBmb3Igbm9uLXN0b3JpbmcgZGV2aWNlcywgY29uc2lkZXJpbmcgdGhh dCBpdCBtYWtlcyB0aGUgc2FtZSB0cmFkZW9mZiBvZiBieXRlcyBpbiBwYWNrZXRzIHZzLiBzdGF0 ZSBpbiB0aGUgbm9kZXMuIEJJRVIgY291bGQgYmUgdXNlZCBmb3IgYm90aCB1bmljYXN0IGFuZCBt dWx0aWNhc3QsIHVuaWNhc3QgYmVpbmcgc2VlbiBhcyBhbiBleHRyZW1lIGZvcm0gb2YgbXVsdGlj YXN0LiBFYWNoIGFkZHJlc3MsIG9yIGdyb3VwLCBvciAoc291cmNlLCBncm91cCksICB0aGUgbm9k ZSByZWdpc3RlcnMgdW5pY2FzdCB0byB0aGUgcm9vdCBpbiBwcmV0dHkgbXVjaCB0aGUgc2FtZSB3 YXkgYXMgd2UgZG8gdG9kYXkgaW4gbm9uLXN0b3JpbmcuIFRoZXJlIGlzIGEgYml0IG9mZnNldCBh c3NvY2lhdGVkIHRvIGVhY2ggbm9kZS4gV2hlbiBhIHBhY2tldCBjb21lcyBpbiwgdGhlIHJvb3Qg bG9va3MgdXAgdGhlIGxpc3Qgb2YgaW50ZXJlc3RlZCBub2Rlcywgc2V0cyBhIGJpdCBtYXAgYXQg YWxsIHRoZSByZWxldmFudCBiaXQgb2Zmc2V0cywgYW5kIGVuY2Fwc3VsYXRlcyB0aGUgcGFja2V0 IGFkZGluZyB0aGF0IGJpdG1hcCwgZS5nLiBpbiBhbiBhZGRyZXNzIG9yIGFuIG9wdGlvbiBoZWFk ZXIuIEVhY2ggbm9kZSBtYWludGFpbnMgYSBiaXRtYXAgcGVyIGNoaWxkIGRvd24gdGhlIFJQTCBw cmVmZXJyZWQgdHJlZSwgd2hpY2ggaGFzIHRoZSBiaXRzIHNldCBmb3IgdGhlIGVuZCBub2RlcyB0 aGF0IGFyZSByZWFjaGFibGUgdmlhIHRoaXMgY2hpbGQuIFRoZXNlIGJpdG1hcHMgY291bGQgYmUg YnVpbHQgYW5kIHJlLWFkdmVydGlzZWQgb3ZlciBjbGFzc2ljYWwgc3RvcmluZy1tb2RlIERBTyBt ZXNzYWdlcyB3aGVyZWJ5IGEgbm9kZSBqdXN0IGFkdmVydGlzZXMgdGhlIEFORCBvZiBhbGwgaXRz IGJpdG1hcHMgdG8gaXRzIHByZWZlcnJlZCBwYXJlbnQuDQoNCkl0IHdvdWxkIHNlZW0gdG8gYmUg dGhlIHJpZ2h0IGFwcHJvYWNoIGZvciBEb24ncyBwcm9ibGVtIGlmIGl0IHdlcmUgbm90IGZvciB0 aGUgc2hlZXIgc2l6ZSBvZiAiIEFyb3VuZCA1MDAwIGRldmljZXMgaW4gdGhlIG5ldHdvcmsgdG90 YWwgIi4NCg0KQklFUiBuZWVkcyBvbmUgYml0IHBlciBkZXZpY2UgaW4gdGhlIHJvdXRpbmcgYml0 bWFwLiBXZSBjYW5ub3QgaGF2ZSBhIDVLIGJpdG1hcCBpbiBldmVyeSBwYWNrZXQuIElmIHdlIHN0 ZWFsIG9uZSBiaXQgaW4gdGhlIGZmMSAoUkZDIDczNzEpIHRvIGluZGljYXRlIGEgQklFUiByb3V0 aW5nLCB3ZSBjb3VsZCBmaXQgdXAgdG8gMTEyIGhvc3RzIGluIGEgbXVsdGljYXN0IElQdjYgYWRk cmVzcy4gIFRvIHJlYWNoIDVLLCB3ZSdsbCBuZWVkIHRvIHN1Ym5ldC4gRm9yIGluc3RhbmNlLCBi eSB1c2luZyA4IGJpdHMgYXMgYSBwcmVmaXgsIHdlIGNvdWxkIGNhcnZlIG91dCAyNTYgc2V0cyBv ZiAxMDQgZGV2aWNlcy4gRm9yIDUwMDAgbm9kZXMsIHRoaXMgbWVhbnMgcm91Z2hseSA1MCBncm91 cHMsIGFuZCBjb3VsZCBtdWx0aXBseSB0aGUgc3RhdGUgaW4gZXZlcnkgbm9kZSBieSA1MCwgdGhv dWdoIHRoZSBudW1iZXJzIGFyZSBwcm9iYWJseSBhIGxvdCBsZXNzIGlmIHRoZSBzZXRzIGFyZSBm b3JtZWQgYmFzZWQgb24gZ2VvZ3JhcGh5LiBCdXQgdGhlbiwgdGhlIHJvb3QgbWF5IGhhdmUgdG8g c2VuZCBtdWx0aXBsZSBjb3BpZXMgb2YgYSBwYWNrZXQsIGFzIG1hbnkgYXMgdGhlcmUgYXJlIGdy b3VwcyB3aXRoIGF0IGxlYXN0IG9uZSBsaXN0ZW5lciBmb3IgdGhhdCBwYWNrZXQuDQoNCkRvbjog YXJlIHRoZXNlIG5vZGVzIGFsbCBpbiBhIHNhbWUgRE9EQUc/IE9yIGFyZSB0aGV5IHBhcnRpdGlv bmVkIGluIHNtYWxsZXIgZ3JvdXBzIHRocm91Z2ggbXVsdGlwbGUgcm9vdHMsIG9yIG11bHRpcGxl IGluc3RhbmNlcz8NCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IG1lcmNyZWRpIDE1IG9jdG9icmUgMjAxNCAyMzo1 Nw0KPiBUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MNCj4gQ2M6 IElKc2JyYW5kIFdpam5hbmRzIChpd2lqbmFuZCkNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBtdWx0 aWNhc3QgJiBNTEQgb24gTExODQo+IA0KPiANCj4gS2VycnkgTHlubiA8a2VybHluQGllZWUub3Jn PiB3cm90ZToNCj4gICAgID4gT24gU2F0LCBPY3QgMTEsIDIwMTQgYXQgMjozOSBBTSwgQ2Fyc3Rl biBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+IHdyb3RlOg0KPiANCj4gICAgID4+IFJpZ2h0LCBN TEQgaXMgYSBob3N0LXJvdXRlciBwcm90b2NvbC4gIFJvdXRlcnMgYW1vbmcgdGhlbSBzcGVhayBh DQo+ICAgICA+PiByb3V0aW5nIHByb3RvY29sLCBzbyB0aGV5IHdvdWxkbuKAmXQgZXhjaGFuZ2Ug TUxELiAgKEEgUlBMIOKAnGxlYWbigJ0gaXMgYQ0KPiAgICAgPj4gcm91dGVyLikNCj4gICAgID4+ DQo+ICAgICA+PiA+IEZpbmFsbHkgSSdtIGxvb2tpbmcgYXQgQklFUiBzZWUgaG93IHRoZWlyIGlk ZWFzIGNvdWxkIGFwcGx5IHRvIExMTnPigKYNCj4gICAgID4+DQo+ICAgICA+PiBZZXAuICBXZSAo VFpJKSBoYXZlIGRvbmUgKHNwZWNpZmllZCwgaW1wbGVtZW50ZWQsIGFuYWx5emVkKSBhbg0KPiAg ICAgPj4gZWZmaWNpZW50IEJJRVItbGlrZSBtdWx0aWNhc3QgZm9yd2FyZGluZyBwcm90b2NvbCBm b3Igbm9uLXN0b3JpbmcgbW9kZQ0KPiAgICAgPj4gYSB3aGlsZSBhZ28uDQo+ICAgICA+Pg0KPiAN Cj4gICAgID4gSSBhZG1pdCB0byBzb21lIGNvbmZ1c2lvbiBoZXJlLiAgSXMgKHRvcG9sb2d5LWZy ZWUpIE1QTCBubyBsb25nZXIgdGhlDQo+ICAgICA+IGRlZmF1bHQgbXVsdGljYXN0IGZvcndhcmRp bmcgcHJvdG9jb2wgZm9yIExMTj8NCj4gDQo+IEkgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBC SUVSIHJlYWxseS4uLiBNUEwgaXMgc3RpbGwgdGhlIGRlZmF1bHQgYXQgdGhpcw0KPiBwb2ludC4N Cj4gKHByb2NlZWR1cmFsIGRlbGF5cyBnZXR0aW5nIHRyaWNrbGUtbWNhc3Qgb3V0LCBub3Qtd2l0 aC1zdGFuZGluZykgTXkgdGFrZSBvbg0KPiB0aGUgY29udmVyc2F0aW9uIGlzIHRoYXQgQklFUiBo YXMgc29tZSBraW5kIG9mIGhlbHBlciBub2RlIHRoYXQgdW5pY2FzdHMNCj4gZXZlcnl0aGluZyBv dXQgYXMgYXBwcm9wcmlhdGUuDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJ RVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiBJRVRGIFJPTEwg V0cgY28tY2hhaXIuICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9yb2xsL2NoYXJ0 ZXIvDQoNCg== From nobody Thu Oct 16 06:09:18 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 5F6CB1A1B59 for ; Thu, 16 Oct 2014 06:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 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, MALFORMED_FREEMAIL=2.511, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3m_gF6o1vaD for ; Thu, 16 Oct 2014 06:09:15 -0700 (PDT) Received: from nm15-vm4.access.bullet.mail.gq1.yahoo.com (nm15-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.103]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134861A1B7A for ; Thu, 16 Oct 2014 06:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413464954; bh=uVpCanAnnnXjZpeodKRdB6YJvKQNHU5ew8c2AfsjCow=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=4I14mQRLsn0pC3r7TCCMxhNWSh6vv6NI3zsxQbvPtTKlwXBCLf3w/lE4BrmP7W5zUKMLqm7iSd4XPjDBE/Zrl1Fk7v6H/K7ymXf2/vT3fGRXpDgPgUFnYud2IYb547A+CB3+hNCnO62Wx5mJYgGJsm5gH55S82s9ugB5e11FIow= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=owI2AuSCTdahknt5+U9RdM3FVI7SOzRFOan2KGq4jWe1pvChGeb2GbRjk866fyr9XqbK40nbSaSLOi5SK8acxAAWKYmtP+UDookWI4cf3Il0LUYfcNlxc1/YzNZ6cDfayndkTtSZmWpz21V3qkjCyVWXJrV5zB53Dwl+2kqdwOc=; Received: from [216.39.60.176] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2014 13:09:14 -0000 Received: from [98.138.226.244] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2014 13:09:14 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 16 Oct 2014 13:09:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413464954; bh=uVpCanAnnnXjZpeodKRdB6YJvKQNHU5ew8c2AfsjCow=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=lAiJk4P8qDNwGc9ZbEyCMZCDsYsua/cDVNWTsWet3jUREjdkVPBfGyEAuwhN1yayW+qHykD0fA5SKttySOm2hUYjRiV63FK9I3gYCl9AHZ7BG6f49u+FoqmMmtIhbvueyUJFj0q3K446/RYBZho5M1lBYC40nPyixIFSNxwMbVw= X-Yahoo-Newman-Id: 434739.96881.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 92dUGG4VM1mJZJNxBo_0D5zJiRjasF.K9uzX9Fz4W1wjhCv Tq9rIB0dDXVoepfQN00DHjkMkIWI_SePCTf.INZX8T6RUEU6_0lJh5dpAEtn IjogN6zpCs4wAubPgQlXMLTM30CVvz3OqzmVuCwboFUd_yCaSvfsUpq5Gs5r .xsEaVFOztb.w7JPNLUJYeS8nwwMl7P3KrjzqZtGTXdnfpX4Hhb1ADKtIu1Y Fg9umrmCjMk_Qz1bQjxbmvKn3cwgczQluLUn.iKVA3OgMoRKv23TZutvHMeW lbTK4czsJWzubZjGStM3mX_kDpM_8Kudk60AiA8BItwJaCIjNUqixYzRk3gd ZdHT99zUtrSDRtXNmnruDXSOLW6gM8QD7Q5TtEXADfwIBrxgFNNJVczWL7.t eK3e33O5qtgXGHOg582ONnpdOCEBXNGoAsGtD2f9WmdmLJyUJaMn6rF7tJIm ra4lCtJk0SaZgQbrwSGgSM4ExmGeL3MoDUUctkI6OU2knDIt7AmlLGiluc5z vzSukk0HkgpMPom7aA4EXhd9uCjNqKcgMIHi.aQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Thu, 16 Oct 2014 06:09:06 -0700 From: Don Sturek To: "Pascal Thubert (pthubert)" , "Turner, Randy" , Kerry Lynn Message-ID: Thread-Topic: [Roll] multicast & MLD on LLN References: <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <29960.1413410219@sandelman.ca> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/btCesO3eKBb3oUrcL0gak7OEqYI Cc: "Greg Shepherd \(shep\)" , Routing Over Low power and Lossy networks , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Roll] multicast & MLD on LLN 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, 16 Oct 2014 13:09:16 -0000 Hi Pascal, Currently, all 5000 devices are members of the same DODAG. Don On 10/16/14 5:54 AM, "Pascal Thubert (pthubert)" wrote: >Hello Michael > >I think that saying that MPL is the default is quite exaggerated. > >RPL has a classical multicast built in, which is a simple extension to >storing mode ( https://tools.ietf.org/html/rfc6550#section-12). >The trouble is that this hardly fits with non-storing. > >BIER (draft-wijnands-bier-architecture-00.txt) seems an appropriate >approach for non-storing devices, considering that it makes the same >tradeoff of bytes in packets vs. state in the nodes. BIER could be used >for both unicast and multicast, unicast being seen as an extreme form of >multicast. Each address, or group, or (source, group), the node >registers unicast to the root in pretty much the same way as we do today >in non-storing. There is a bit offset associated to each node. When a >packet comes in, the root looks up the list of interested nodes, sets a >bit map at all the relevant bit offsets, and encapsulates the packet >adding that bitmap, e.g. in an address or an option header. Each node >maintains a bitmap per child down the RPL preferred tree, which has the >bits set for the end nodes that are reachable via this child. These >bitmaps could be built and re-advertised over classical storing-mode DAO >messages whereby a node just advertises the AND of all its bitmaps to its >preferred parent. > >It would seem to be the right approach for Don's problem if it were not >for the sheer size of " Around 5000 devices in the network total ". > >BIER needs one bit per device in the routing bitmap. We cannot have a 5K >bitmap in every packet. If we steal one bit in the ff1 (RFC 7371) to >indicate a BIER routing, we could fit up to 112 hosts in a multicast IPv6 >address. To reach 5K, we'll need to subnet. For instance, by using 8 >bits as a prefix, we could carve out 256 sets of 104 devices. For 5000 >nodes, this means roughly 50 groups, and could multiply the state in >every node by 50, though the numbers are probably a lot less if the sets >are formed based on geography. But then, the root may have to send >multiple copies of a packet, as many as there are groups with at least >one listener for that packet. > >Don: are these nodes all in a same DODAG? Or are they partitioned in >smaller groups through multiple roots, or multiple instances? > >Pascal > > >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael >>Richardson >> Sent: mercredi 15 octobre 2014 23:57 >> To: Routing Over Low power and Lossy networks >> Cc: IJsbrand Wijnands (iwijnand) >> Subject: Re: [Roll] multicast & MLD on LLN >>=20 >>=20 >> Kerry Lynn wrote: >> > On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann >> wrote: >>=20 >> >> Right, MLD is a host-router protocol. Routers among them speak a >> >> routing protocol, so they wouldn=B9t exchange MLD. (A RPL =B3leaf=B2 >>is a >> >> router.) >> >> >> >> > Finally I'm looking at BIER see how their ideas could apply to >>LLNs=8A >> >> >> >> Yep. We (TZI) have done (specified, implemented, analyzed) an >> >> efficient BIER-like multicast forwarding protocol for >>non-storing mode >> >> a while ago. >> >> >>=20 >> > I admit to some confusion here. Is (topology-free) MPL no longer >>the >> > default multicast forwarding protocol for LLN? >>=20 >> I don't know anything about BIER really... MPL is still the default at >>this >> point. >> (proceedural delays getting trickle-mcast out, not-with-standing) My >>take on >> the conversation is that BIER has some kind of helper node that unicasts >> everything out as appropriate. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > From nobody Sat Oct 18 04:37: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 5DD391A6F9B; Sat, 18 Oct 2014 04:37:36 -0700 (PDT) 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 mjZ0Ma-DCUUN; Sat, 18 Oct 2014 04:37:35 -0700 (PDT) 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 DE2771A6F9A; Sat, 18 Oct 2014 04:37:34 -0700 (PDT) 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 s9IBbVkA006270; Sat, 18 Oct 2014 13:37:31 +0200 (CEST) Received: from [192.168.217.113] (p54892213.dip0.t-ipconnect.de [84.137.34.19]) (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 55C39E13; Sat, 18 Oct 2014 13:37:31 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann Date: Sat, 18 Oct 2014 13:37:28 +0200 X-Mao-Original-Outgoing-Id: 435325048.303209-f6e3a5c5b0bf25ea1d07764ec72633e2 Content-Transfer-Encoding: quoted-printable Message-Id: <4E958567-8A2E-4AA0-8A12-28AB69A06A1C@tzi.org> References: To: Routing Over Low power and Lossy networks , Tisch <6tisch@ietf.org> X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/B0rGj-k0zHvQhlaacWyrIjugghU Subject: [Roll] Fwd: [6lo] Constrained Node/Network Cluster @ IETF91, "final" version 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, 18 Oct 2014 11:37:36 -0000 Sorry for the separate message, but there are too many WGs in this = cluster now for a single cross posting... > On 12 Oct 2014, at 10:40, Carsten Bormann wrote: >=20 >> A first draft version of the IETF91 agenda is out. >> ** THIS IS GOING TO CHANGE ** for conflict resolution, >> so please don't make travel arrangements based on it. >>=20 >> Here is my usual eclectic condensed agenda built from that. =20 >> All times are HST (UTC-1000) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). >=20 > Here is an update with the =93final=94 agenda (caveat viator). > Note the 6TiSCH move, and the newly scheduled JOSE meeting (across = DICE, ouch). >=20 > Gr=FC=DFe, Carsten >=20 >=20 > MONDAY, November 10, 2014 >=20 > 0900-1130 Morning Session I > Coral 2 APP appsawg Applications Area Working Group WG - = Combined with APPAREA > Coral 4 OPS v6ops IPv6 Operations WG >=20 > 1300-1500 Afternoon Session I > Coral 4 RTG bier Bit Indexed Explicit Replication BOF >=20 > 1520-1720 Afternoon Session II > Coral 1 INT detnet Deterministic Networking BOF > Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF > Coral 3 OPS v6ops IPv6 Operations WG >=20 > 1730-1830 Afternoon Session III > Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF > Coral 1 SEC *** dice DTLS In Constrained Environments WG > Rainbow Ste 1/2 SEC jose Javascript Object Signing and = Encryption WG >=20 > TUESDAY, November 11, 2014 >=20 > 0900-1130 Morning Session I > Coral 2 APP uta Using TLS in Applications WG > Kahili 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG > Coral 5 TSV tsvarea Transport Area Open Meeting >=20 > 1300-1500 Afternoon Session I > Coral 1 APP httpbis Hypertext Transfer Protocol WG > Coral 4 RTG rtgarea Routing Area Open Meeting > Coral 2 TSV tsvwg Transport Area Working Group WG >=20 > 1520-1720 Afternoon Session II > Coral 2 APP *** core Constrained RESTful Environments WG > Coral 5 RAI webpush Web-Based Push Notifications WG >=20 > WEDNESDAY, November 12, 2014 >=20 > 0900-1130 Morning Session I > Kahili 1/2 APP *** core Constrained RESTful Environments WG > Coral 3 INT homenet Home Networking WG > Lehua Suite SEC oauth Web Authorization Protocol WG > Coral 4 TSV rmcat RTP Media Congestion Avoidance = Techniques WG >=20 > 1300-1500 Afternoon Session I > Coral 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG >=20 > 1520-1650 Afternoon Session II > Coral 4 APP httpbis Hypertext Transfer Protocol WG >=20 > THURSDAY, November 13, 2014 >=20 > 0900-1130 Morning Session I > Hibiscus 1/2 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG > Coral 5 SEC tls Transport Layer Security WG > Coral 2 TSV taps Transport Services WG >=20 > 1300-1500 Afternoon Session I > Coral 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG > Coral 3 SEC saag Security Area Open Meeting > Coral 1 TSV tsvwg Transport Area Working Group WG >=20 > 1520-1620 Afternoon Session II > Coral 4 INT *** lwig Light-Weight Implementation Guidance WG >=20 > FRIDAY, November 14, 2014 >=20 > 0900-1130 Morning Session I > Coral 3 INT 6man IPv6 Maintenance WG > Coral 1 TSV tcpinc TCP Increased Security WG >=20 > 1150-1320 Afternoon Session I > Coral 4 INT intarea Internet Area Working Group WG > Coral 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >=20 >=20 From nobody Tue Oct 21 10:25: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 A0AFE1A1B4A for ; Tue, 21 Oct 2014 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 F5NZiV3PRNch for ; Tue, 21 Oct 2014 10:25:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::606]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115B41A1A0E for ; Tue, 21 Oct 2014 10:25:29 -0700 (PDT) Received: from DB4PR06MB047.eurprd06.prod.outlook.com (10.242.154.154) by DB4PR06MB045.eurprd06.prod.outlook.com (10.242.154.145) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 17:23:24 +0000 Received: from DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.129]) by DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.129]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 17:23:24 +0000 From: Yvonne-Anne Pignolet To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-05.txt Thread-Index: Ac/tUX/RlGHPVNYmQ9SLCKvmUUjnhQ== Date: Tue, 21 Oct 2014 17:23:23 +0000 Message-ID: <3dc940374515412880bd6f8123508e7e@DB4PR06MB047.eurprd06.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [12.238.14.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB045; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(25584003)(252514010)(13464003)(199003)(189002)(377424004)(33646002)(64706001)(76576001)(120916001)(95666004)(4396001)(74316001)(21056001)(77096002)(97736003)(106356001)(46102003)(99396003)(105586002)(2501002)(76482002)(230783001)(107886001)(66066001)(80022003)(107046002)(108616004)(20776003)(122556002)(50986999)(86362001)(54356999)(85306004)(40100003)(31966008)(101416001)(19580395003)(19580405001)(15202345003)(85852003)(87936001)(2656002)(92566001)(15975445006)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR06MB045; H:DB4PR06MB047.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; 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/kMOjXs7ovAV1jahKP6Et_KP2dXU 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: 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, 21 Oct 2014 17:25:33 -0000 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 tr= affic 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 L= LNs. I suggest to include both P2P-RPL and basic RPL in the recommended pro= tocol portfolio for home and building automation. 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 th= e industrial applicability statement I thus recommend a paragraph such as "= Nodes send DAO messages to establish downward paths from the root to themse= lves. DAO messages are not acknowledged in networks composed of battery ope= rated field devices in order to minimize the power consumption overhead ass= ociated with path discovery. If devices in LLNs participate in multiple RP= L 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 Ackn= owledgement (P2P-DRO-ACK) would be helpful 3. Please correct 4.1.4. OF0 is not a metric. Did you mean ETX or HC? Or an= other metric from http://tools.ietf.org/html/rfc6551#section-6.1 ? 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 5. About Section 6, 2hy would manageability be out of scope for home networ= k scenarios? And can you give more detail on what central control based on = MIBs entails? =20 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: Dienstag, 7. Oktober 2014 00:10 To: roll@ietf.org Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-home-buildin= g-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:=20 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 director= ies. This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. Title : Applicability Statement: The use of the RPL=20 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-buildin= g/ 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=3Ddraft-ietf-roll-applicability-home-build= ing-05 Please note that it may take a couple of minutes from the time of submissio= n 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 Oct 21 17:38: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 7F7131A88A7; Tue, 21 Oct 2014 17:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njitel33pNpd; Tue, 21 Oct 2014 17:38:38 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C5D1A8841; Tue, 21 Oct 2014 17:38:38 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so2504041pab.6 for ; Tue, 21 Oct 2014 17:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=axWZkA5iFh73t+DAO132LP2O8hacTNfk8NpuXNfUWuo=; b=yRxHrOX/VjTCVmfvQMwfJQ2gHJp23UEyZ0EeANO+/ELC9jkWP1xVv/2ErGvwXiexgc hWTudrZ6/SN9qU5AvcV4rGSpXOXjesJ2r/E5CmdTLY8GlyTU0hHDjPF+vHsDS5iVgEv3 vkXdVwDFnuAFu8Ih15bl82nmyqvNB47Kg8pr7/PNgK2xrvvroo0o0hiTA8C35LQzfPaB dQADN/QcQPHrHHgqoDJk9okJWp9+MML03l0vCGiOhR1MjIQoMvcvyKW0/AkfKDYkzR07 NZqcmaIOrDMiMHopkIJ2Ap1NRWQYns6sJlII2mNGMmbQ1V8b1ODj764iGW7AfcXm83dj pjgg== X-Received: by 10.66.160.225 with SMTP id xn1mr15198780pab.24.1413938318399; Tue, 21 Oct 2014 17:38:38 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.250.169 with HTTP; Tue, 21 Oct 2014 17:38:18 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 21 Oct 2014 17:38:18 -0700 X-Google-Sender-Auth: cYjlX6zgW7wzoU_V5Cfv0E0o8o8 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b6d883a33e1e60505f82b9f Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pb6sGfm78Bo8bKyHM6-njxqzUfg Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "roll-chairs@tools.ietf.org" , "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 00:38:40 -0000 --047d7b6d883a33e1e60505f82b9f Content-Type: text/plain; charset=UTF-8 +1 on the proposal. On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana < xvilajosana@eecs.berkeley.edu> wrote: > All, > > I fully support that approach. Hope to contribute and make it happen as > soon as possible. > > regards, > Xavi > > 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) : > > Dear all: >> >> During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the >> minimal I-D (draft-ietf-6tisch-minimal) must indicate the compression >> method for the RPL Information (see RFC 6553), so as to ensure >> interoperation between 6TiSCH devices. >> >> We discussed our options, basically either a 6lo approach or a Flow Label >> approach. The rough consensus at the call was to try and focus on a 6lo >> approach and evaluate where that leads us. >> >> Because this means that the minimal draft will have a normative reference >> on a WIP I-D, we recognized that this approach may delay the publication of >> the final RFC. Per IETF procedures, the minimal draft will be stalled in >> the RFC editor queue in MISREF state until the 6lo work completes. So the >> consensus was also to support the 6lo work so as to expedite it as much as >> possible. >> >> The idea would be to republish a standard track draft-ietf-6lo- ASAP, >> based on the existing proposals (which are rapidly converging); then, Xavi >> would include a normative reference to that work in the minimal I-D before >> its publication to IESG, which is scheduled in November (yes, this is >> aggressive). >> >> This is a call to confirm the rough consensus on the ML, open till the >> next interim call on October 24th. Please provide us with any relevant >> comment (and participate to the 6lo discussions in the meantime!). >> >> If the result is positive: >> - we plan to call for a 6lo WG doc adoption in Hawaii >> - we are looking for an aggressive schedule to limit the impact on the >> publication of the minimal RFC >> >> 6TiSCH may host the 6lo discussion so as to: >> - benefit from the early morning schedule >> - attract more 6TiSCH people to the discussion >> >> More the published minutes: >> - Webex recording: >> https://cisco.webex.com/ciscosales/lsr.php?RCID=36a3b7df06694258a3ac65bfc519212f >> - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex >> - Slides: >> https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010_webex.ppt >> >> Cheers, >> >> Pascal >> >> _______________________________________________ >> 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 > > --047d7b6d883a33e1e60505f82b9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on the proposal.

On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosan= a <xvilajosana@eecs.berkeley.edu> wrote:
All,

I fully= support that approach. Hope to contribute and make it happen as soon as po= ssible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pasca= l Thubert (pthubert) <pthubert@cisco.com>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webe= x.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex<= /a>
- Slides: https://bitbucket.org/6t= isch/meetings/src/master/141010_webex/slides_141010_webex.ppt

Cheers,

Pascal

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


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


--047d7b6d883a33e1e60505f82b9f-- From nobody Tue Oct 21 17:59:15 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 4C1501A88C0; Tue, 21 Oct 2014 17:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 aEhltLG_RFwC; Tue, 21 Oct 2014 17:59:02 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB5A1A88CF; Tue, 21 Oct 2014 17:59:01 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0430.eurprd01.prod.exchangelabs.com (10.242.221.21) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 00:56:55 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 00:56:56 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Call to confirm a rough consensus on RPL info Thread-Index: Ac/oQa0i5HZn0oJrT3qpZBX3hHGwVAAAfziAAVMzxgD//8E8AA== Date: Wed, 22 Oct 2014 00:56:55 +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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [24.126.172.117] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0430; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(41574002)(24454002)(377424004)(377454003)(189002)(55674003)(199003)(561944003)(31966008)(97736003)(110136001)(19617315012)(46102003)(122556002)(85852003)(106356001)(16799955002)(107046002)(21056001)(95666004)(66066001)(85306004)(120916001)(4396001)(40100003)(15975445006)(83506001)(16236675004)(76482002)(19580395003)(20776003)(80022003)(92566001)(92726001)(86362001)(54356999)(76176999)(50986999)(87936001)(2656002)(101416001)(19580405001)(99396003)(105586002)(64706001)(36756003)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0430; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D06C76D52136randyturnerlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/va9mkWZvISlDi4GDWtTmXg6uawk Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 00:59:06 -0000 --_000_D06C76D52136randyturnerlandisgyrcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I'm +1 on the proposal - was compression of 6553 options the ONLY r= equired compression in the "minimal" case ? (apologies...I wasn't on the ca= ll) I did a quick search of minimal-02 and didn't see the word compression = anywhere. Thanks! Randy From: Thomas Watteyne > Reply-To: "roll@ietf.org" > Date: Tuesday, October 21, 2014 at 8:38 PM To: "roll@ietf.org" > Cc: "6lo-chairs@tools.ietf.org" <6lo-chai= rs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.o= rg" <6lo@ietf.org>, "roll-chairs@= tools.ietf.org" >, "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info +1 on the proposal. On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana > wrote: All, I fully support that approach. Hope to contribute and make it happen as soo= n as possible. regards, Xavi 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) >: Dear all: During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices. We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us. Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible. The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ). This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!). If the result is positive: - we plan to call for a 6lo WG doc adoption in Hawaii - we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC 6TiSCH may host the 6lo discussion so as to: - benefit from the early morning schedule - attract more 6TiSCH people to the discussion More the published minutes: - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7= df06694258a3ac65bfc519212f - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex - Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/sli= des_141010_webex.ppt Cheers, Pascal _______________________________________________ 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 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_D06C76D52136randyturnerlandisgyrcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2ECB771156F8FD44A73CD3B65290F14C@eurprd01.prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable

I think I’m +1 on the proposal – was compression of 65= 53 options the ONLY required compression in the “minimal” case = ? (apologies…I wasn’t on the call) I did a quick search of mini= mal-02 and didn’t see the word compression anywhere.  

Thanks!
Randy

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Reply-To: "roll@ietf.org" <= roll@ietf.org>
Date: Tuesday, October 21, 2014 at = 8:38 PM
To: "roll@ietf.org" <roll@i= etf.org>
Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "roll-chairs@tools.ietf.org" <roll-chairs@tools.ietf.org>, &qu= ot;6tisch-chairs@tools.ietf= .org" <6tisch-chairs@tools.ie= tf.org>
Subject: Re: [Roll] Call to confirm= a rough consensus on RPL info

+1 on the proposal.

On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajos= ana <xvil= ajosana@eecs.berkeley.edu> wrote:
All,

I fully support that approach. Hope to contribute and make it happen a= s soon as possible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pt= hubert) <pthubert@cisco.= com>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the consensus was also to support the 6lo= work so as to expedite it as much as possible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc= 519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex
- Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010= _webex.ppt

Cheers,

Pascal

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


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

P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_D06C76D52136randyturnerlandisgyrcom_-- From nobody Tue Oct 21 18:09: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 BB9D31A88E2 for ; Tue, 21 Oct 2014 18:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 461iSQ5k5Nbw for ; Tue, 21 Oct 2014 18:09:06 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8DF1A88D6 for ; Tue, 21 Oct 2014 18:09:04 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so2640505wgh.22 for ; Tue, 21 Oct 2014 18:09:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y7rbv3/1Z4Muvj2TYXHGTC88ve80SyOi7wvLqOEXrfg=; b=eFV/f9p4wB7dxEf17i+G71WhAAGZceWUHBDHe8IeZaiQdpo2BCjll6hnRtn77CAOSn NY2qIwmdKUyBc4bvbJumPhuOXX+CFbw20bhdn4ZVseuM+7xYnrrJGcx26zHRt7FsftVb YeFGUJaRZbYZotxTMqKRdahwnnmgHJG517bnrgZLmwJM17thMZ2LQYVxz+niUEp6Qf9L GUzKcPavNGZEkRmEeunAMGK5tvAdz0LnL8B0hSr19Wws7htnXAB7wKuxDG9YCCFI8NJo Vl2OsZ4/BKPiaepBSmodpKs9LSEcbbMmybtd2UyVk4/jdrfLJQB0+IhzWuIHBYaRmmMS HLSQ== X-Gm-Message-State: ALoCoQm/VVOztN5eNA4p7B2EU0fdm8kTABSlyOfPfHsR+/n8POTalBjIkvXy6pFb6wgx3uoJUvEP MIME-Version: 1.0 X-Received: by 10.180.83.104 with SMTP id p8mr1745399wiy.74.1413940142890; Tue, 21 Oct 2014 18:09:02 -0700 (PDT) Received: by 10.194.191.170 with HTTP; Tue, 21 Oct 2014 18:09:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 22:09:02 -0300 Message-ID: From: "Prof. Diego Dujovne" To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=f46d044289eef3975d0505f897e3 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zVVwiZd2wcmoW9tzzxx-fJgN7zU Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "roll-chairs@tools.ietf.org" , "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 01:09:08 -0000 --f46d044289eef3975d0505f897e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1! 2014-10-21 21:38 GMT-03:00 Thomas Watteyne : > +1 on the proposal. > > On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > >> All, >> >> I fully support that approach. Hope to contribute and make it happen as >> soon as possible. >> >> regards, >> Xavi >> >> 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) = : >> >> Dear all: >>> >>> During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that >>> the minimal I-D (draft-ietf-6tisch-minimal) must indicate the compressi= on >>> method for the RPL Information (see RFC 6553), so as to ensure >>> interoperation between 6TiSCH devices. >>> >>> We discussed our options, basically either a 6lo approach or a Flow >>> Label approach. The rough consensus at the call was to try and focus on= a >>> 6lo approach and evaluate where that leads us. >>> >>> Because this means that the minimal draft will have a normative >>> reference on a WIP I-D, we recognized that this approach may delay the >>> publication of the final RFC. Per IETF procedures, the minimal draft wi= ll >>> be stalled in the RFC editor queue in MISREF state until the 6lo work >>> completes. So the consensus was also to support the 6lo work so as to >>> expedite it as much as possible. >>> >>> The idea would be to republish a standard track draft-ietf-6lo- ASAP, >>> based on the existing proposals (which are rapidly converging); then, X= avi >>> would include a normative reference to that work in the minimal I-D bef= ore >>> its publication to IESG, which is scheduled in November (yes, this is >>> aggressive). >>> >>> This is a call to confirm the rough consensus on the ML, open till the >>> next interim call on October 24th. Please provide us with any relevant >>> comment (and participate to the 6lo discussions in the meantime!). >>> >>> If the result is positive: >>> - we plan to call for a 6lo WG doc adoption in Hawaii >>> - we are looking for an aggressive schedule to limit the impact on the >>> publication of the minimal RFC >>> >>> 6TiSCH may host the 6lo discussion so as to: >>> - benefit from the early morning schedule >>> - attract more 6TiSCH people to the discussion >>> >>> More the published minutes: >>> - Webex recording: >>> https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac6= 5bfc519212f >>> - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex >>> - Slides: >>> https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_14= 1010_webex.ppt >>> >>> Cheers, >>> >>> Pascal >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 DIEGO DUJOVNE Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunic= aciones Facultad de Ingenier=C3=ADa UDP www.ingenieria.udp.cl (56 2) 676 8125 --f46d044289eef3975d0505f897e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1!

2014-10-21 21:38 GMT-03:00 Thomas Watteyne &= lt;watteyne= @eecs.berkeley.edu>:
+1 on the proposal.

On Tue, Oct 14, = 2014 at 11:45 PM, Xavier Vilajosana <xvilajosana@eecs.berkeley= .edu> wrote:
All,

I fully support that approach. Hope to contribut= e and make it happen as soon as possible.

regards,=
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) &l= t;pthubert@cisco.co= m>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webe= x.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex<= /a>
- Slides: https://bitbucket.org/6t= isch/meetings/src/master/141010_webex/slides_141010_webex.ppt

Cheers,

Pascal

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


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



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




--
DIEGO DUJOVNE
Ac= ad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomunicac= iones
Facultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125
--f46d044289eef3975d0505f897e3-- From nobody Tue Oct 21 19:17: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 7B8F11A8A25; Tue, 21 Oct 2014 19:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA4n7Mt0h7ky; Tue, 21 Oct 2014 19:17:18 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFA31A8A1A; Tue, 21 Oct 2014 19:17:18 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kx10so2640545pab.23 for ; Tue, 21 Oct 2014 19:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+o7VwoIzZJNJ/gS+pwDlEfNYa6DwOs2OQJuAHwW70o4=; b=eFTdceN3NG/As/qLPqJgx4wmtVpoFODWo7eZTZrOuDqAfV2PqboY8LLNJ/te9A+qzP OXKS5DLu31AAx5pOfJviwW4HbrXBxYnPkC24bpZRnr2v+5vTQ1NUklOoYAzW6Sg8OGyF jQsXzjmj13Tw/FmmeMh/QuJJIDSWWsdDLbjmQ44P722fxWxe5dnDub/dbFRPDldmRJiW iG6jNF0LcVpvSX4TeiRPrYWP2BAqTnSR+sVPvE4nv5raPTNNaStyIcgo8I4n8yzA7M+Q al7ov00r2tqKrmzdxiR1f1hzF/HhZ4/f+FcJnXSCQEqTlCmrusOU2apXIIiDLKpoXoRR M0GA== X-Received: by 10.68.235.103 with SMTP id ul7mr39187937pbc.63.1413944237695; Tue, 21 Oct 2014 19:17:17 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.250.169 with HTTP; Tue, 21 Oct 2014 19:16:57 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 21 Oct 2014 19:16:57 -0700 X-Google-Sender-Auth: PwgN_FPqEl-_179p6RC5wErKj5Q Message-ID: To: "Turner, Randy" Content-Type: multipart/alternative; boundary=047d7b33cfaa0528070505f98cb4 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/VTC43GGwXuPFgoPTXd3OUWm9mbs Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 02:17:20 -0000 --047d7b33cfaa0528070505f98cb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Randy, Are you alluding to 6554? Thomas On Tue, Oct 21, 2014 at 5:56 PM, Turner, Randy wrote: > > I think I=E2=80=99m +1 on the proposal =E2=80=93 was compression of 6553= options the > ONLY required compression in the =E2=80=9Cminimal=E2=80=9D case ? (apolog= ies=E2=80=A6I wasn=E2=80=99t on > the call) I did a quick search of minimal-02 and didn=E2=80=99t see the w= ord > compression anywhere. > > Thanks! > Randy > > From: Thomas Watteyne > Reply-To: "roll@ietf.org" > Date: Tuesday, October 21, 2014 at 8:38 PM > To: "roll@ietf.org" > Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, " > 6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, " > roll-chairs@tools.ietf.org" , " > 6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> > Subject: Re: [Roll] Call to confirm a rough consensus on RPL info > > +1 on the proposal. > > On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > >> All, >> >> I fully support that approach. Hope to contribute and make it happen as >> soon as possible. >> >> regards, >> Xavi >> >> 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) = : >> >> >> Dear all: >>> >>> During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that >>> the minimal I-D (draft-ietf-6tisch-minimal) must indicate the compressi= on >>> method for the RPL Information (see RFC 6553), so as to ensure >>> interoperation between 6TiSCH devices. >>> >>> We discussed our options, basically either a 6lo approach or a Flow >>> Label approach. The rough consensus at the call was to try and focus on= a >>> 6lo approach and evaluate where that leads us. >>> >>> Because this means that the minimal draft will have a normative >>> reference on a WIP I-D, we recognized that this approach may delay the >>> publication of the final RFC. Per IETF procedures, the minimal draft wi= ll >>> be stalled in the RFC editor queue in MISREF state until the 6lo work >>> completes. So the consensus was also to support the 6lo work so as to >>> expedite it as much as possible. >>> >>> The idea would be to republish a standard track draft-ietf-6lo- ASAP, >>> based on the existing proposals (which are rapidly converging); then, X= avi >>> would include a normative reference to that work in the minimal I-D bef= ore >>> its publication to IESG, which is scheduled in November (yes, this is >>> aggressive). >>> >>> This is a call to confirm the rough consensus on the ML, open till the >>> next interim call on October 24th. Please provide us with any relevant >>> comment (and participate to the 6lo discussions in the meantime!). >>> >>> If the result is positive: >>> - we plan to call for a 6lo WG doc adoption in Hawaii >>> - we are looking for an aggressive schedule to limit the impact on the >>> publication of the minimal RFC >>> >>> 6TiSCH may host the 6lo discussion so as to: >>> - benefit from the early morning schedule >>> - attract more 6TiSCH people to the discussion >>> >>> More the published minutes: >>> - Webex recording: >>> https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac6= 5bfc519212f >>> - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex >>> - Slides: >>> https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_14= 1010_webex.ppt >>> >>> Cheers, >>> >>> Pascal >>> >>> _______________________________________________ >>> 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 >> >> > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legall= y > privileged. If you are not an intended recipient or an authorized > representative of an intended recipient, you are prohibited from using, > copying or distributing the information in this e-mail or its attachments= . > If you have received this e-mail in error, please notify the sender > immediately by return e-mail and delete all copies of this message and an= y > attachments. Thank you. > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --047d7b33cfaa0528070505f98cb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Randy,
Are you alluding to 6554?
Thomas

On Tue, Oc= t 21, 2014 at 5:56 PM, Turner, Randy <Randy.Turner@landisgyr.com<= /a>> wrote:

I think I=E2=80=99m +1 on the proposal =E2=80=93 was compression of 65= 53 options the ONLY required compression in the =E2=80=9Cminimal=E2=80=9D c= ase ? (apologies=E2=80=A6I wasn=E2=80=99t on the call) I did a quick search= of minimal-02 and didn=E2=80=99t see the word compression anywhere. =C2=A0=

Thanks!
Randy

From: Thomas Watteyne <watteyne@eecs.berk= eley.edu>
Reply-To: "roll@ietf.org" <roll@ietf.org>
Date: Tuesday, October 21, 2014 at = 8:38 PM
To: "roll@ietf.org" <roll@ietf.org>
Cc: "6lo-chairs@tools.ietf.org" &= lt;6lo-chair= s@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org&q= uot; <6lo@ietf.org= >, "roll-chairs@tools.ietf.org" <roll-chairs@tools.ietf.org>, "6tisch-chai= rs@tools.ietf.org" <6tis= ch-chairs@tools.ietf.org>
Subject: Re: [Roll] Call to confirm= a rough consensus on RPL info

+1 on the proposal.

On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajos= ana <xvil= ajosana@eecs.berkeley.edu> wrote:
All,

I fully support that approach. Hope to contribute and make it happen a= s soon as possible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthube= rt) <pthubert@cisco.= com>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the consensus was also to support the 6lo= work so as to expedite it as much as possible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc= 519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex
- Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010= _webex.ppt

Cheers,

Pascal

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


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



P PLEASE C= ONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confi= dential and may be legally privileged. If you are not an intended recipient= or an authorized representative of an intended recipient, you are prohibit= ed from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.


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


--047d7b33cfaa0528070505f98cb4-- From nobody Tue Oct 21 21:21: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 B02811A8A8D; Tue, 21 Oct 2014 21:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 wFCQJ2GcQLWX; Tue, 21 Oct 2014 21:20:47 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::795]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2668C1A8A89; Tue, 21 Oct 2014 21:20:47 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 04:13:35 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 04:13:35 +0000 From: "Turner, Randy" To: Randy Turner Thread-Topic: [6lo] [6tisch] [Roll] Call to confirm a rough consensus on RPL info Thread-Index: Ac/oQa0i5HZn0oJrT3qpZBX3hHGwVAAAfziAAVMzxgD//8E8AIAAWlSAgAAgGQCAAAB8ww== Date: Wed, 22 Oct 2014 04:13:34 +0000 Message-ID: <2B22B172-9DF3-4317-B724-5B1E8538C0C1@landisgyr.com> References: , <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> In-Reply-To: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:0:8ec0:4a:c1e5:ade5:1c08:b976] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(41574002)(24454002)(189002)(199003)(377454003)(377424004)(31966008)(16236675004)(33656002)(120916001)(82746002)(15975445006)(561944003)(40100003)(101416001)(93886004)(85306004)(99396003)(76482002)(122556002)(16799955002)(20776003)(64706001)(4396001)(21056001)(86362001)(92726001)(76176999)(54356999)(87936001)(107046002)(80022003)(83716003)(50986999)(2656002)(46102003)(95666004)(36756003)(19580395003)(19580405001)(19617315012)(105586002)(85852003)(110136001)(92566001)(106356001)(104396001)(24704002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2B22B1729DF34317B7245B1E8538C0C1landisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QntLY03LBs9yyiqjur7kKXSynmM Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 04:20:52 -0000 --_000_2B22B1729DF34317B7245B1E8538C0C1landisgyrcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Forgot to reply to lists as well :)...see my reply to Thomas below On Oct 22, 2014, at 12:11 AM, "Randy Turner" > wrote: Yes, in Pascal's call for consensus he only mentions 6553... Just curious i= f the phone call consensus was only about requiring compression of 6553 opt= ions...or are there any other compression methods that the minimal draft mu= st include Thanks! Randy Sent from my iPad On Oct 21, 2014, at 10:16 PM, Thomas Watteyne > wrote: Randy, Are you alluding to 6554? Thomas On Tue, Oct 21, 2014 at 5:56 PM, Turner, Randy > wrote: I think I=92m +1 on the proposal =96 was compression of 6553 options the ON= LY required compression in the =93minimal=94 case ? (apologies=85I wasn=92t= on the call) I did a quick search of minimal-02 and didn=92t see the word = compression anywhere. Thanks! Randy From: Thomas Watteyne > Reply-To: "roll@ietf.org" > Date: Tuesday, October 21, 2014 at 8:38 PM To: "roll@ietf.org" > Cc: "6lo-chairs@tools.ietf.org" <6lo-chai= rs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.o= rg" <6lo@ietf.org>, "roll-chairs@= tools.ietf.org" >, "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info +1 on the proposal. On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana > wrote: All, I fully support that approach. Hope to contribute and make it happen as soo= n as possible. regards, Xavi 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) >: Dear all: During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices. We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us. Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as pos= sible. The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive= ). This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!). If the result is positive: - we plan to call for a 6lo WG doc adoption in Hawaii - we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC 6TiSCH may host the 6lo discussion so as to: - benefit from the early morning schedule - attract more 6TiSCH people to the discussion More the published minutes: - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7= df06694258a3ac65bfc519212f - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex - Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/sli= des_141010_webex.ppt Cheers, Pascal _______________________________________________ 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 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo --_000_2B22B1729DF34317B7245B1E8538C0C1landisgyrcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Forgot to reply to lists as well :)...see my reply to Thomas below

On Oct 22, 2014, at 12:11 AM, "Randy Turner" <rturner@amalfisystems.com> wrote:

Yes, in Pascal's call for consensus he only mentions 6553... Just curi= ous if the phone call consensus was only about requiring compression of 655= 3 options...or are there any other compression methods that the minimal dra= ft must include

Thanks!
Randy

Sent from my iPad

On Oct 21, 2014, at 10:16 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

Randy,
Are you alluding to 6554?
Thomas

On Tue, Oct 21, 2014 at 5:56 PM, Turner, Randy <= span dir=3D"ltr"> <Randy.T= urner@landisgyr.com> wrote:

I think I=92m +1 on the proposal =96 was compression of 6553 optio= ns the ONLY required compression in the =93minimal=94 case ? (apologies=85I= wasn=92t on the call) I did a quick search of minimal-02 and didn=92t see = the word compression anywhere.  

Thanks!
Randy


+1 on the proposal.

On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajos= ana <xvil= ajosana@eecs.berkeley.edu> wrote:
All,

I fully support that approach. Hope to contribute and make it happen a= s soon as possible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pt= hubert) <pthubert@cisco.= com>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the m= inimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method= for the RPL Information (see RFC 6553), so as to ensure interoperation bet= ween 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label a= pproach. The rough consensus at the call was to try and focus on a 6lo appr= oach and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference o= n a WIP I-D, we recognized that this approach may delay the publication of = the final RFC. Per IETF procedures, the minimal draft will be stalled in th= e RFC editor queue in MISREF state until the 6lo work completes. So the consensus was also to support the 6lo= work so as to expedite it as much as possible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based= on the existing proposals (which are rapidly converging); then, Xavi would= include a normative reference to that work in the minimal I-D before its p= ublication to IESG, which is scheduled in November (yes, this is aggressive).

This is a call to confirm the rough consensus on the ML, open till the next= interim call on October 24th. Please provide us with any relevant comment = (and participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publ= ication of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc= 519212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex
- Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010= _webex.ppt

Cheers,

Pascal

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


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

P PLEASE C= ONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confi= dential and may be legally privileged. If you are not an intended recipient= or an authorized representative of an intended recipient, you are prohibit= ed from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.


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


_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.iet= f.org/mailman/listinfo/6lo
--_000_2B22B1729DF34317B7245B1E8538C0C1landisgyrcom_-- From nobody Wed Oct 22 00:12: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 C79181A8A83 for ; Tue, 21 Oct 2014 21:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NamISwjukuM for ; Tue, 21 Oct 2014 21:11:56 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id E0D571A8A85 for ; Tue, 21 Oct 2014 21:11:52 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9M4Boj0006124 for ; Wed, 22 Oct 2014 00:11:50 -0400 Received: (qmail 13903 invoked by uid 0); 22 Oct 2014 04:11:50 -0000 X-TCPREMOTEIP: 24.126.172.117 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?192.168.1.144?) (rturner@amalfisystems.com@24.126.172.117) by 0 with ESMTPA; 22 Oct 2014 04:11:50 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-73D8E95F-CFFF-4EC2-989A-26B3EA0C1FD8 Mime-Version: 1.0 (1.0) From: Randy Turner X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Wed, 22 Oct 2014 00:11:50 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> References: To: Thomas Watteyne Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RQ6lwMVfb6wbCw4l-GuwmEy9E68 X-Mailman-Approved-At: Wed, 22 Oct 2014 00:12:29 -0700 Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 04:11:59 -0000 --Apple-Mail-73D8E95F-CFFF-4EC2-989A-26B3EA0C1FD8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, in Pascal's call for consensus he only mentions 6553... Just curious if= the phone call consensus was only about requiring compression of 6553 optio= ns...or are there any other compression methods that the minimal draft must i= nclude Thanks! Randy Sent from my iPad > On Oct 21, 2014, at 10:16 PM, Thomas Watteyne = wrote: >=20 > Randy, > Are you alluding to 6554? > Thomas >=20 >> On Tue, Oct 21, 2014 at 5:56 PM, Turner, Randy wrote: >>=20 >> I think I=E2=80=99m +1 on the proposal =E2=80=93 was compression of 6553 o= ptions the ONLY required compression in the =E2=80=9Cminimal=E2=80=9D case ?= (apologies=E2=80=A6I wasn=E2=80=99t on the call) I did a quick search of mi= nimal-02 and didn=E2=80=99t see the word compression anywhere. =20 >>=20 >> Thanks! >> Randy >>=20 >> From: Thomas Watteyne >> Reply-To: "roll@ietf.org" >> Date: Tuesday, October 21, 2014 at 8:38 PM >> To: "roll@ietf.org" >> Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf= .org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "roll-chairs@tools.i= etf.org" , "6tisch-chairs@tools.ietf.org" <6tisc= h-chairs@tools.ietf.org> >> Subject: Re: [Roll] Call to confirm a rough consensus on RPL info >>=20 >> +1 on the proposal. >>=20 >>> On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosana wrote: >>> All, >>>=20 >>> I fully support that approach. Hope to contribute and make it happen as s= oon as possible. >>>=20 >>> regards, >>> Xavi >>>=20 >>> 2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthubert) = : >>>=20 >>>> Dear all: >>>>=20 >>>> During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that t= he minimal I-D (draft-ietf-6tisch-minimal) must indicate the compression met= hod for the RPL Information (see RFC 6553), so as to ensure interoperation b= etween 6TiSCH devices. >>>>=20 >>>> We discussed our options, basically either a 6lo approach or a Flow Lab= el approach. The rough consensus at the call was to try and focus on a 6lo a= pproach and evaluate where that leads us. >>>>=20 >>>> Because this means that the minimal draft will have a normative referen= ce on a WIP I-D, we recognized that this approach may delay the publication o= f the final RFC. Per IETF procedures, the minimal draft will be stalled in t= he RFC editor queue in MISREF state until the 6lo work completes. So the con= sensus was also to support the 6lo work so as to expedite it as much as poss= ible. >>>>=20 >>>> The idea would be to republish a standard track draft-ietf-6lo- ASAP, b= ased on the existing proposals (which are rapidly converging); then, Xavi wo= uld include a normative reference to that work in the minimal I-D before its= publication to IESG, which is scheduled in November (yes, this is aggressiv= e). >>>>=20 >>>> This is a call to confirm the rough consensus on the ML, open till the n= ext interim call on October 24th. Please provide us with any relevant commen= t (and participate to the 6lo discussions in the meantime!). >>>>=20 >>>> If the result is positive: >>>> - we plan to call for a 6lo WG doc adoption in Hawaii >>>> - we are looking for an aggressive schedule to limit the impact on the p= ublication of the minimal RFC >>>>=20 >>>> 6TiSCH may host the 6lo discussion so as to: >>>> - benefit from the early morning schedule >>>> - attract more 6TiSCH people to the discussion >>>>=20 >>>> More the published minutes: >>>> - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36= a3b7df06694258a3ac65bfc519212f >>>> - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex >>>> - Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex= /slides_141010_webex.ppt >>>>=20 >>>> Cheers, >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.=20 >>=20 >> This e-mail (including any attachments) is confidential and may be legall= y privileged. If you are not an intended recipient or an authorized represen= tative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have r= eceived this e-mail in error, please notify the sender immediately by return= e-mail and delete all copies of this message and any attachments. Thank you= . >>=20 >>=20 >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo --Apple-Mail-73D8E95F-CFFF-4EC2-989A-26B3EA0C1FD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, in Pascal's call for consensus he= only mentions 6553... Just curious if the phone call consensus was only abo= ut requiring compression of 6553 options...or are there any other compressio= n methods that the minimal draft must include

Thank= s!
Randy

Sent from my iPad

On Oct 21, 2014, a= t 10:16 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

Randy,
Are you alluding to 6554?
= Thomas

= On Tue, Oct 21, 2014 at 5:56 PM, Turner, Randy <Randy.Turner@landis= gyr.com> wrote:

I think I=E2=80=99m +1 on the proposal =E2=80=93 was compression of 655= 3 options the ONLY required compression in the =E2=80=9Cminimal=E2=80=9D cas= e ? (apologies=E2=80=A6I wasn=E2=80=99t on the call) I did a quick search of= minimal-02 and didn=E2=80=99t see the word compression anywhere.  

Thanks!
Randy

From: Thomas Watteyne <watteyne@eecs.berkeley= .edu>
Reply-To: "roll@ietf.org" <roll@ietf.org>
Date: Tuesday, October 21, 2014 at 8= :38 PM
To: "roll@ietf.org" <roll@ietf.org>
Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.o= rg>, "6tisch@iet= f.org" <6tisch@i= etf.org>, "6lo@ietf.org" <6lo@ietf.org>, "roll-chairs@tools= .ietf.org" <roll-chairs@tools.ietf.org>, "6tisch-chairs@tools.ietf.org" <6tisc= h-chairs@tools.ietf.org>
Subject: Re: [Roll] Call to confirm a= rough consensus on RPL info

+1 on the proposal.

On Tue, Oct 14, 2014 at 11:45 PM, Xavier Vilajosa= na <xvila= josana@eecs.berkeley.edu> wrote:
All,

I fully support that approach. Hope to contribute and make it happen as= soon as possible.

regards,
Xavi

2014-10-15 8:32 GMT+02:00 Pascal Thubert (pthuber= t) <pthubert@cisco.c= om>:

Dear all:

During the 6TiSCH bi-weekly virtual interim on Friday, we agreed that the mi= nimal I-D (draft-ietf-6tisch-minimal) must indicate the compression method f= or the RPL Information (see RFC 6553), so as to ensure interoperation betwee= n 6TiSCH devices.

We discussed our options, basically either a 6lo approach or a Flow Label ap= proach. The rough consensus at the call was to try and focus on a 6lo approa= ch and evaluate where that leads us.

Because this means that the minimal draft will have a normative reference on= a WIP I-D, we recognized that this approach may delay the publication of th= e final RFC. Per IETF procedures, the minimal draft will be stalled in the R= FC editor queue in MISREF state until the 6lo work completes. So the consensus was also to support the 6lo w= ork so as to expedite it as much as possible.

The idea would be to republish a standard track draft-ietf-6lo- ASAP, based o= n the existing proposals (which are rapidly converging); then, Xavi would in= clude a normative reference to that work in the minimal I-D before its publi= cation to IESG, which is scheduled in November (yes, this is aggressive).

This is a call to confirm the rough consensus on the ML, open till the next i= nterim call on October 24th. Please provide us with any relevant comment (an= d participate to the 6lo discussions in the meantime!).

If the result is positive:
- we plan to call for a 6lo WG doc adoption in Hawaii
- we are looking for an aggressive schedule to limit the impact on the publi= cation of the minimal RFC

6TiSCH may host the 6lo discussion so as to:
- benefit from the early morning schedule
- attract more 6TiSCH people to the discussion

More the published minutes:
- Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D36a3b7df06694258a3ac65bfc5= 19212f
- Wiki: https://bitbucket.org/6tisch/meetings/wiki/141010_webex
- Slides: https://bitbucket.org/6tisch/meetings/src/master/141010_webex/slides_141010_= webex.ppt

Cheers,

Pascal

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


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

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confid= ential and may be legally privileged. If you are not an intended recipient o= r an authorized representative of an intended recipient, you are prohibited f= rom using, copying or distributing the information in this e-mail or its attachments. If you have received thi= s e-mail in error, please notify the sender immediately by return e-mail and= delete all copies of this message and any attachments. Thank you.


_______________________________________________
6tisch mailing list
6tisch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tisch


____________________= ___________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/lis= tinfo/6lo
= --Apple-Mail-73D8E95F-CFFF-4EC2-989A-26B3EA0C1FD8-- From nobody Wed Oct 22 01:06: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 BD4821A8AF0; Wed, 22 Oct 2014 01:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 n8m2f1XOZOJG; Wed, 22 Oct 2014 01:06:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7B1A8AF5; Wed, 22 Oct 2014 01:06:26 -0700 (PDT) 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.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022080626.31875.54356.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 01:06:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/tQKnpZJFq_RipDfnkeu2dOFTHNw Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-admin-local-policy-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 08:06:31 -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-01.txt Pages : 12 Date : 2014-10-22 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 22 02:50:37 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 128BD1A8F43 for ; Wed, 22 Oct 2014 02:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, 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 1orN_0PL_mhO for ; Wed, 22 Oct 2014 02:50:33 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12C51A8F48 for ; Wed, 22 Oct 2014 02:50:32 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9M9oT6V075472 for ; Wed, 22 Oct 2014 11:50:30 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-201-25.w92-145.abo.wanadoo.fr ([92.145.80.25]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 22 Oct 2014 11:50:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Oct 2014 11:50:29 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20141022080626.31875.54356.idtracker@ietfa.amsl.com> References: <20141022080626.31875.54356.idtracker@ietfa.amsl.com> Message-ID: <066b14b601a850a86a21271e6c5ce459@xs4all.nl> X-Sender: stokcons@xs4all.nl (eR0/SPz0MImJRBMD94jL15rMFEQ7WL4r) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/V53_WqaTRLQZ32gcJzz96brIi34 Subject: Re: [Roll] I-D Action: draft-ietf-roll-admin-local-policy-01.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: Wed, 22 Oct 2014 09:50:35 -0000 Dear wg, I submitted a new version of draft-ietf-roll-admin-local-policy. Given the remarks I received, the following changes were done with respect to the former version. o Default parameter values declared o Security section extended o scope 5 of higher messages specified o messages with address ALL_MPL_FORWARDERS are not allowed from outside zone Looking forward to your comments, Peter __________________________________________________________________________________ internet-drafts@ietf.org schreef op 2014-10-22 10:06: > 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-01.txt > Pages : 12 > Date : 2014-10-22 > > 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-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Oct 22 05:21:17 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 1DE8D1A90B3; Wed, 22 Oct 2014 05:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQdwY8mZp7de; Wed, 22 Oct 2014 05:21:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C21A90A0; Wed, 22 Oct 2014 05:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31246; q=dns/txt; s=iport; t=1413980472; x=1415190072; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=umI0ysN5coC062bce7ABZP+oZJdyDZFsqcxQ1szB5fs=; b=MuZzhsjIp2E8WT+MBsuBh1gJWagvQwNlkR823hF3yollQbLkE5J7eYsR J0nDsZ5aND5WI5o5pkuOCZjQ27LvQKja1Z9sXMHUl9SKhVHfSJ91q/NRL i28uH+sCPHvRCqAZpdFO5byDk5mn5fLe1Bvz7Loj3kVzqePBXO3VVYWxI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAESgR1StJA2G/2dsb2JhbABCGg6COkZUWASDArcUkkgBC4Z3VAIbcBYBfYQCAQEBBAEBARoGCj8CCxACAQgOAwMBAQELFgcDAgICJQsUCQgCBAENBQiIOA04sEeUagEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3ULBgECHQYHCQoMAQQGAQIEgnE2gR4Fj2aCHoRGiESDSYgDiS2DOEBsAQSBAggXIoEDAQEB X-IronPort-AV: E=Sophos;i="5.04,768,1406592000"; d="scan'208,217";a="365638141" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2014 12:21:11 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9MCLADw013757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:21:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.200]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 07:21:10 -0500 From: "Pascal Thubert (pthubert)" To: Randy Turner , Thomas Watteyne Thread-Topic: [6lo] [6tisch] [Roll] Call to confirm a rough consensus on RPL info Thread-Index: AQHP7a5X9wLLa/e8i02jf47M6Vzh75w8CVug Date: Wed, 22 Oct 2014 12:21:09 +0000 Deferred-Delivery: Wed, 22 Oct 2014 12:21:00 +0000 Message-ID: References: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> In-Reply-To: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.82.231] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A1872Fxmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Hx0TIM9ue5bkXAdy8iLrOYkztfo Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 12:21:16 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A1872Fxmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFuZHk6DQoNCjY1NTMgaXMgd2hlcmUgdGhlcmUgd2FzIGEgbG90IHRvIGJlIGdhaW5l ZDsgT1RPSCwgNjU1NCBhbHJlYWR5IG9wdGltaXplcyBieSBmYWN0b3JpbmcgcHJlZml4ZXMuIFdv dWxkIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIGZvciBiZXR0ZXI/DQoNCkNoZWVycywNCg0KUGFzY2Fs DQoNCkZyb206IDZsbyBbbWFpbHRvOjZsby1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UmFuZHkgVHVybmVyDQpTZW50OiBtZXJjcmVkaSAyMiBvY3RvYnJlIDIwMTQgMDY6MTINClRvOiBU aG9tYXMgV2F0dGV5bmUNCkNjOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrczsgVHVybmVyLCBSYW5keTsgNnRpc2NoQGlldGYub3JnOyA2bG9AaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbNmxvXSBbNnRpc2NoXSBbUm9sbF0gQ2FsbCB0byBjb25maXJtIGEgcm91Z2ggY29u c2Vuc3VzIG9uIFJQTCBpbmZvDQoNClllcywgaW4gUGFzY2FsJ3MgY2FsbCBmb3IgY29uc2Vuc3Vz IGhlIG9ubHkgbWVudGlvbnMgNjU1My4uLiBKdXN0IGN1cmlvdXMgaWYgdGhlIHBob25lIGNhbGwg Y29uc2Vuc3VzIHdhcyBvbmx5IGFib3V0IHJlcXVpcmluZyBjb21wcmVzc2lvbiBvZiA2NTUzIG9w dGlvbnMuLi5vciBhcmUgdGhlcmUgYW55IG90aGVyIGNvbXByZXNzaW9uIG1ldGhvZHMgdGhhdCB0 aGUgbWluaW1hbCBkcmFmdCBtdXN0IGluY2x1ZGUNCg0KVGhhbmtzIQ0KUmFuZHkNCg0KU2VudCBm cm9tIG15IGlQYWQNCg0KT24gT2N0IDIxLCAyMDE0LCBhdCAxMDoxNiBQTSwgVGhvbWFzIFdhdHRl eW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdTxtYWlsdG86d2F0dGV5bmVAZWVjcy5iZXJr ZWxleS5lZHU+PiB3cm90ZToNClJhbmR5LA0KQXJlIHlvdSBhbGx1ZGluZyB0byA2NTU0Pw0KVGhv bWFzDQoNCk9uIFR1ZSwgT2N0IDIxLCAyMDE0IGF0IDU6NTYgUE0sIFR1cm5lciwgUmFuZHkgPFJh bmR5LlR1cm5lckBsYW5kaXNneXIuY29tPG1haWx0bzpSYW5keS5UdXJuZXJAbGFuZGlzZ3lyLmNv bT4+IHdyb3RlOg0KDQpJIHRoaW5rIEnigJltICsxIG9uIHRoZSBwcm9wb3NhbCDigJMgd2FzIGNv bXByZXNzaW9uIG9mIDY1NTMgb3B0aW9ucyB0aGUgT05MWSByZXF1aXJlZCBjb21wcmVzc2lvbiBp biB0aGUg4oCcbWluaW1hbOKAnSBjYXNlID8gKGFwb2xvZ2llc+KApkkgd2FzbuKAmXQgb24gdGhl IGNhbGwpIEkgZGlkIGEgcXVpY2sgc2VhcmNoIG9mIG1pbmltYWwtMDIgYW5kIGRpZG7igJl0IHNl ZSB0aGUgd29yZCBjb21wcmVzc2lvbiBhbnl3aGVyZS4NCg0KVGhhbmtzIQ0KUmFuZHkNCg0KRnJv bTogVGhvbWFzIFdhdHRleW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdTxtYWlsdG86d2F0 dGV5bmVAZWVjcy5iZXJrZWxleS5lZHU+Pg0KUmVwbHktVG86ICJyb2xsQGlldGYub3JnPG1haWx0 bzpyb2xsQGlldGYub3JnPiIgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0K RGF0ZTogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCBhdCA4OjM4IFBNDQpUbzogInJvbGxAaWV0 Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+IiA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBp ZXRmLm9yZz4+DQpDYzogIjZsby1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOjZsby1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+IiA8NmxvLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Nmxv LWNoYWlyc0B0b29scy5pZXRmLm9yZz4+LCAiNnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hA aWV0Zi5vcmc+IiA8NnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc+PiwgIjZs b0BpZXRmLm9yZzxtYWlsdG86NmxvQGlldGYub3JnPiIgPDZsb0BpZXRmLm9yZzxtYWlsdG86Nmxv QGlldGYub3JnPj4sICJyb2xsLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cm9sbC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+IiA8cm9sbC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJv bGwtY2hhaXJzQHRvb2xzLmlldGYub3JnPj4sICI2dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzo2dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3JnPiIgPDZ0aXNjaC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtSb2xsXSBDYWxsIHRvIGNvbmZpcm0gYSByb3VnaCBjb25zZW5zdXMgb24gUlBMIGlu Zm8NCg0KKzEgb24gdGhlIHByb3Bvc2FsLg0KDQpPbiBUdWUsIE9jdCAxNCwgMjAxNCBhdCAxMTo0 NSBQTSwgWGF2aWVyIFZpbGFqb3NhbmEgPHh2aWxham9zYW5hQGVlY3MuYmVya2VsZXkuZWR1PG1h aWx0bzp4dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdT4+IHdyb3RlOg0KQWxsLA0KDQpJIGZ1 bGx5IHN1cHBvcnQgdGhhdCBhcHByb2FjaC4gSG9wZSB0byBjb250cmlidXRlIGFuZCBtYWtlIGl0 IGhhcHBlbiBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpyZWdhcmRzLA0KWGF2aQ0KDQoyMDE0LTEw LTE1IDg6MzIgR01UKzAyOjAwIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNp c2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj46DQoNCkRlYXIgYWxsOg0KDQpEdXJp bmcgdGhlIDZUaVNDSCBiaS13ZWVrbHkgdmlydHVhbCBpbnRlcmltIG9uIEZyaWRheSwgd2UgYWdy ZWVkIHRoYXQgdGhlIG1pbmltYWwgSS1EIChkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsKSBtdXN0 IGluZGljYXRlIHRoZSBjb21wcmVzc2lvbiBtZXRob2QgZm9yIHRoZSBSUEwgSW5mb3JtYXRpb24g KHNlZSBSRkMgNjU1MyksIHNvIGFzIHRvIGVuc3VyZSBpbnRlcm9wZXJhdGlvbiBiZXR3ZWVuIDZU aVNDSCBkZXZpY2VzLg0KDQpXZSBkaXNjdXNzZWQgb3VyIG9wdGlvbnMsIGJhc2ljYWxseSBlaXRo ZXIgYSA2bG8gYXBwcm9hY2ggb3IgYSBGbG93IExhYmVsIGFwcHJvYWNoLiBUaGUgcm91Z2ggY29u c2Vuc3VzIGF0IHRoZSBjYWxsIHdhcyB0byB0cnkgYW5kIGZvY3VzIG9uIGEgNmxvIGFwcHJvYWNo IGFuZCBldmFsdWF0ZSB3aGVyZSB0aGF0IGxlYWRzIHVzLg0KDQpCZWNhdXNlIHRoaXMgbWVhbnMg dGhhdCB0aGUgbWluaW1hbCBkcmFmdCB3aWxsIGhhdmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIG9u IGEgV0lQIEktRCwgd2UgcmVjb2duaXplZCB0aGF0IHRoaXMgYXBwcm9hY2ggbWF5IGRlbGF5IHRo ZSBwdWJsaWNhdGlvbiBvZiB0aGUgZmluYWwgUkZDLiBQZXIgSUVURiBwcm9jZWR1cmVzLCB0aGUg bWluaW1hbCBkcmFmdCB3aWxsIGJlIHN0YWxsZWQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgaW4g TUlTUkVGIHN0YXRlIHVudGlsIHRoZSA2bG8gd29yayBjb21wbGV0ZXMuIFNvIHRoZSBjb25zZW5z dXMgd2FzIGFsc28gdG8gc3VwcG9ydCB0aGUgNmxvIHdvcmsgc28gYXMgdG8gZXhwZWRpdGUgaXQg YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KVGhlIGlkZWEgd291bGQgYmUgdG8gcmVwdWJsaXNoIGEg c3RhbmRhcmQgdHJhY2sgZHJhZnQtaWV0Zi02bG8tIEFTQVAsIGJhc2VkIG9uIHRoZSBleGlzdGlu ZyBwcm9wb3NhbHMgKHdoaWNoIGFyZSByYXBpZGx5IGNvbnZlcmdpbmcpOyB0aGVuLCBYYXZpIHdv dWxkIGluY2x1ZGUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoYXQgd29yayBpbiB0aGUgbWlu aW1hbCBJLUQgYmVmb3JlIGl0cyBwdWJsaWNhdGlvbiB0byBJRVNHLCB3aGljaCBpcyBzY2hlZHVs ZWQgaW4gTm92ZW1iZXIgKHllcywgdGhpcyBpcyBhZ2dyZXNzaXZlKS4NCg0KVGhpcyBpcyBhIGNh bGwgdG8gY29uZmlybSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9uIHRoZSBNTCwgb3BlbiB0aWxsIHRo ZSBuZXh0IGludGVyaW0gY2FsbCBvbiBPY3RvYmVyIDI0dGguIFBsZWFzZSBwcm92aWRlIHVzIHdp dGggYW55IHJlbGV2YW50IGNvbW1lbnQgKGFuZCBwYXJ0aWNpcGF0ZSB0byB0aGUgNmxvIGRpc2N1 c3Npb25zIGluIHRoZSBtZWFudGltZSEpLg0KDQpJZiB0aGUgcmVzdWx0IGlzIHBvc2l0aXZlOg0K LSB3ZSBwbGFuIHRvIGNhbGwgZm9yIGEgNmxvIFdHIGRvYyBhZG9wdGlvbiBpbiBIYXdhaWkNCi0g d2UgYXJlIGxvb2tpbmcgZm9yIGFuIGFnZ3Jlc3NpdmUgc2NoZWR1bGUgdG8gbGltaXQgdGhlIGlt cGFjdCBvbiB0aGUgcHVibGljYXRpb24gb2YgdGhlIG1pbmltYWwgUkZDDQoNCjZUaVNDSCBtYXkg aG9zdCB0aGUgNmxvIGRpc2N1c3Npb24gc28gYXMgdG86DQotIGJlbmVmaXQgZnJvbSB0aGUgZWFy bHkgbW9ybmluZyBzY2hlZHVsZQ0KLSBhdHRyYWN0IG1vcmUgNlRpU0NIIHBlb3BsZSB0byB0aGUg ZGlzY3Vzc2lvbg0KDQpNb3JlIHRoZSBwdWJsaXNoZWQgbWludXRlczoNCi0gV2ViZXggcmVjb3Jk aW5nOiBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/UkNJRD0zNmEz YjdkZjA2Njk0MjU4YTNhYzY1YmZjNTE5MjEyZg0KLSBXaWtpOiBodHRwczovL2JpdGJ1Y2tldC5v cmcvNnRpc2NoL21lZXRpbmdzL3dpa2kvMTQxMDEwX3dlYmV4DQotIFNsaWRlczogaHR0cHM6Ly9i aXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy9zcmMvbWFzdGVyLzE0MTAxMF93ZWJleC9zbGlk ZXNfMTQxMDEwX3dlYmV4LnBwdA0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJv bGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRv OlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jv bGwNCg0KDQoNClAgUExFQVNFIENPTlNJREVSIE9VUiBFTlZJUk9OTUVOVCBCRUZPUkUgUFJJTlRJ TkcgVEhJUyBFTUFJTC4NCg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMp IGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9yIGFuIGF1dGhvcml6ZWQgcmVwcmVzZW50YXRp dmUgb2YgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIHByb2hpYml0ZWQgZnJvbSB1c2lu ZywgY29weWluZyBvciBkaXN0cmlidXRpbmcgdGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZS1tYWls IG9yIGl0cyBhdHRhY2htZW50cy4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gZS1t YWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cy4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KNnRpc2NoIG1haWxpbmcgbGlzdA0KNnRpc2NoQGlldGYub3JnPG1haWx0bzo2 dGlzY2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0 aXNjaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K NmxvIG1haWxpbmcgbGlzdA0KNmxvQGlldGYub3JnPG1haWx0bzo2bG9AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsbw0K --_000_E045AECD98228444A58C61C200AE1BD848A1872Fxmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldlYmRpbmdzOw0KCXBhbm9zZS0xOjUgMyAxIDIgMSA1 IDkgNiA3IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gUmFuZHk6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj42NTUzIGlz IHdoZXJlIHRoZXJlIHdhcyBhIGxvdCB0byBiZSBnYWluZWQ7IE9UT0gsIDY1NTQgYWxyZWFkeSBv cHRpbWl6ZXMgYnkgZmFjdG9yaW5nIHByZWZpeGVzLiBXb3VsZCB5b3UgaGF2ZSBzdWdnZXN0aW9u cyBmb3IgYmV0dGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhc2NhbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDZsbyBb bWFpbHRvOjZsby1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SYW5keSBU dXJuZXI8YnI+DQo8Yj5TZW50OjwvYj4gbWVyY3JlZGkgMjIgb2N0b2JyZSAyMDE0IDA2OjEyPGJy Pg0KPGI+VG86PC9iPiBUaG9tYXMgV2F0dGV5bmU8YnI+DQo8Yj5DYzo8L2I+IFJvdXRpbmcgT3Zl ciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzOyBUdXJuZXIsIFJhbmR5OyA2dGlzY2hAaWV0 Zi5vcmc7IDZsb0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWzZsb10gWzZ0aXNj aF0gW1JvbGxdIENhbGwgdG8gY29uZmlybSBhIHJvdWdoIGNvbnNlbnN1cyBvbiBSUEwgaW5mbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMs IGluIFBhc2NhbCdzIGNhbGwgZm9yIGNvbnNlbnN1cyBoZSBvbmx5IG1lbnRpb25zIDY1NTMuLi4g SnVzdCBjdXJpb3VzIGlmIHRoZSBwaG9uZSBjYWxsIGNvbnNlbnN1cyB3YXMgb25seSBhYm91dCBy ZXF1aXJpbmcgY29tcHJlc3Npb24gb2YgNjU1MyBvcHRpb25zLi4ub3IgYXJlIHRoZXJlIGFueSBv dGhlciBjb21wcmVzc2lvbiBtZXRob2RzIHRoYXQgdGhlIG1pbmltYWwgZHJhZnQgbXVzdCBpbmNs dWRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJhbmR5PGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQYWQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gT2N0IDIxLCAyMDE0LCBhdCAxMDoxNiBQTSwgVGhvbWFzIFdhdHRleW5l ICZsdDs8YSBocmVmPSJtYWlsdG86d2F0dGV5bmVAZWVjcy5iZXJrZWxleS5lZHUiPndhdHRleW5l QGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYW5keSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IGFsbHVkaW5nIHRvIDY1NTQ/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9t YXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBPY3QgMjEsIDIwMTQgYXQgNTo1NiBQTSwgVHVybmVyLCBSYW5keSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlJhbmR5LlR1cm5lckBsYW5kaXNneXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+UmFu ZHkuVHVybmVyQGxhbmRpc2d5ci5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkkgdGhpbmsgSeKAmW0gJiM0MzsxIG9uIHRoZSBwcm9wb3NhbCDigJMgd2FzIGNv bXByZXNzaW9uIG9mIDY1NTMgb3B0aW9ucyB0aGUgT05MWSByZXF1aXJlZCBjb21wcmVzc2lvbiBp biB0aGUg4oCcbWluaW1hbOKAnSBjYXNlID8gKGFwb2xvZ2llc+KApkkgd2FzbuKAmXQgb24gdGhl IGNhbGwpIEkgZGlkDQogYSBxdWljayBzZWFyY2ggb2YgbWluaW1hbC0wMiBhbmQgZGlkbuKAmXQg c2VlIHRoZSB3b3JkIGNvbXByZXNzaW9uIGFueXdoZXJlLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+UmFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRob21hcyBXYXR0ZXluZSAmbHQ7PGEgaHJlZj0ibWFp bHRvOndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1IiB0YXJnZXQ9Il9ibGFuayI+d2F0dGV5bmVA ZWVjcy5iZXJrZWxleS5lZHU8L2E+Jmd0Ozxicj4NCjxiPlJlcGx5LVRvOiA8L2I+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yb2xsQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5yb2xsQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgT2N0 b2JlciAyMSwgMjAxNCBhdCA4OjM4IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJt YWlsdG86cm9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJvbGxAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJv bGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv OjZsby1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42bG8tY2hhaXJzQHRv b2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZsby1jaGFpcnNAdG9v bHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42bG8tY2hhaXJzQHRvb2xzLmlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzo2dGlz Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj42dGlzY2hAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOjZsb0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsb0BpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzo2bG9AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj42bG9AaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJvbGwt Y2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cm9sbC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWNoYWlyc0B0b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJvbGwtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzo2dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NnRpc2NoLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzo2dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+NnRpc2NoLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbUm9sbF0gQ2FsbCB0byBjb25maXJtIGEgcm91Z2ggY29uc2Vuc3VzIG9u IFJQTCBpbmZvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mIzQzOzEgb24gdGhlIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+T24gVHVlLCBPY3QgMTQsIDIwMTQgYXQgMTE6NDUgUE0sIFhhdmllciBWaWxh am9zYW5hICZsdDs8YSBocmVmPSJtYWlsdG86eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHUi IHRhcmdldD0iX2JsYW5rIj54dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsbCwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+SSBmdWxseSBzdXBwb3J0IHRoYXQgYXBwcm9hY2guIEhvcGUgdG8g Y29udHJpYnV0ZSBhbmQgbWFrZSBpdCBoYXBwZW4gYXMgc29vbiBhcyBwb3NzaWJsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+cmVnYXJkcyw8YnI+DQpYYXZpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIwMTQtMTAtMTUgODozMiBHTVQmIzQzOzAyOjAw IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0OzoNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIGFsbDo8YnI+DQo8YnI+DQpEdXJp bmcgdGhlIDZUaVNDSCBiaS13ZWVrbHkgdmlydHVhbCBpbnRlcmltIG9uIEZyaWRheSwgd2UgYWdy ZWVkIHRoYXQgdGhlIG1pbmltYWwgSS1EIChkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsKSBtdXN0 IGluZGljYXRlIHRoZSBjb21wcmVzc2lvbiBtZXRob2QgZm9yIHRoZSBSUEwgSW5mb3JtYXRpb24g KHNlZSBSRkMgNjU1MyksIHNvIGFzIHRvIGVuc3VyZSBpbnRlcm9wZXJhdGlvbiBiZXR3ZWVuIDZU aVNDSCBkZXZpY2VzLjxicj4NCjxicj4NCldlIGRpc2N1c3NlZCBvdXIgb3B0aW9ucywgYmFzaWNh bGx5IGVpdGhlciBhIDZsbyBhcHByb2FjaCBvciBhIEZsb3cgTGFiZWwgYXBwcm9hY2guIFRoZSBy b3VnaCBjb25zZW5zdXMgYXQgdGhlIGNhbGwgd2FzIHRvIHRyeSBhbmQgZm9jdXMgb24gYSA2bG8g YXBwcm9hY2ggYW5kIGV2YWx1YXRlIHdoZXJlIHRoYXQgbGVhZHMgdXMuPGJyPg0KPGJyPg0KQmVj YXVzZSB0aGlzIG1lYW5zIHRoYXQgdGhlIG1pbmltYWwgZHJhZnQgd2lsbCBoYXZlIGEgbm9ybWF0 aXZlIHJlZmVyZW5jZSBvbiBhIFdJUCBJLUQsIHdlIHJlY29nbml6ZWQgdGhhdCB0aGlzIGFwcHJv YWNoIG1heSBkZWxheSB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZpbmFsIFJGQy4gUGVyIElFVEYg cHJvY2VkdXJlcywgdGhlIG1pbmltYWwgZHJhZnQgd2lsbCBiZSBzdGFsbGVkIGluIHRoZSBSRkMg ZWRpdG9yIHF1ZXVlIGluIE1JU1JFRiBzdGF0ZQ0KIHVudGlsIHRoZSA2bG8gd29yayBjb21wbGV0 ZXMuIFNvIHRoZSBjb25zZW5zdXMgd2FzIGFsc28gdG8gc3VwcG9ydCB0aGUgNmxvIHdvcmsgc28g YXMgdG8gZXhwZWRpdGUgaXQgYXMgbXVjaCBhcyBwb3NzaWJsZS48YnI+DQo8YnI+DQpUaGUgaWRl YSB3b3VsZCBiZSB0byByZXB1Ymxpc2ggYSBzdGFuZGFyZCB0cmFjayBkcmFmdC1pZXRmLTZsby0g QVNBUCwgYmFzZWQgb24gdGhlIGV4aXN0aW5nIHByb3Bvc2FscyAod2hpY2ggYXJlIHJhcGlkbHkg Y29udmVyZ2luZyk7IHRoZW4sIFhhdmkgd291bGQgaW5jbHVkZSBhIG5vcm1hdGl2ZSByZWZlcmVu Y2UgdG8gdGhhdCB3b3JrIGluIHRoZSBtaW5pbWFsIEktRCBiZWZvcmUgaXRzIHB1YmxpY2F0aW9u IHRvIElFU0csIHdoaWNoIGlzIHNjaGVkdWxlZA0KIGluIE5vdmVtYmVyICh5ZXMsIHRoaXMgaXMg YWdncmVzc2l2ZSkuPGJyPg0KPGJyPg0KVGhpcyBpcyBhIGNhbGwgdG8gY29uZmlybSB0aGUgcm91 Z2ggY29uc2Vuc3VzIG9uIHRoZSBNTCwgb3BlbiB0aWxsIHRoZSBuZXh0IGludGVyaW0gY2FsbCBv biBPY3RvYmVyIDI0dGguIFBsZWFzZSBwcm92aWRlIHVzIHdpdGggYW55IHJlbGV2YW50IGNvbW1l bnQgKGFuZCBwYXJ0aWNpcGF0ZSB0byB0aGUgNmxvIGRpc2N1c3Npb25zIGluIHRoZSBtZWFudGlt ZSEpLjxicj4NCjxicj4NCklmIHRoZSByZXN1bHQgaXMgcG9zaXRpdmU6PGJyPg0KLSB3ZSBwbGFu IHRvIGNhbGwgZm9yIGEgNmxvIFdHIGRvYyBhZG9wdGlvbiBpbiBIYXdhaWk8YnI+DQotIHdlIGFy ZSBsb29raW5nIGZvciBhbiBhZ2dyZXNzaXZlIHNjaGVkdWxlIHRvIGxpbWl0IHRoZSBpbXBhY3Qg b24gdGhlIHB1YmxpY2F0aW9uIG9mIHRoZSBtaW5pbWFsIFJGQzxicj4NCjxicj4NCjZUaVNDSCBt YXkgaG9zdCB0aGUgNmxvIGRpc2N1c3Npb24gc28gYXMgdG86PGJyPg0KLSBiZW5lZml0IGZyb20g dGhlIGVhcmx5IG1vcm5pbmcgc2NoZWR1bGU8YnI+DQotIGF0dHJhY3QgbW9yZSA2VGlTQ0ggcGVv cGxlIHRvIHRoZSBkaXNjdXNzaW9uPGJyPg0KPGJyPg0KTW9yZSB0aGUgcHVibGlzaGVkIG1pbnV0 ZXM6PGJyPg0KLSBXZWJleCByZWNvcmRpbmc6IDxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXgu Y29tL2Npc2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTM2YTNiN2RmMDY2OTQyNThhM2FjNjViZmM1MTky MTJmIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVz L2xzci5waHA/UkNJRD0zNmEzYjdkZjA2Njk0MjU4YTNhYzY1YmZjNTE5MjEyZjwvYT48YnI+DQot IFdpa2k6IDxhIGhyZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mvd2lr aS8xNDEwMTBfd2ViZXgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vYml0YnVja2V0Lm9yZy82 dGlzY2gvbWVldGluZ3Mvd2lraS8xNDEwMTBfd2ViZXg8L2E+PGJyPg0KLSBTbGlkZXM6IDxhIGhy ZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mvc3JjL21hc3Rlci8xNDEw MTBfd2ViZXgvc2xpZGVzXzE0MTAxMF93ZWJleC5wcHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mvc3JjL21hc3Rlci8xNDEwMTBfd2ViZXgv c2xpZGVzXzE0MTAxMF93ZWJleC5wcHQ8L2E+PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4N ClBhc2NhbDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9s bEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpSb2xsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Um9sbEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OldlYmRpbmdzO2NvbG9yOmdyZWVuIj5QPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Z3JlZW4iPiBQTEVBU0UgQ09OU0lERVIgT1VSIEVOVklST05NRU5UIEJFRk9S RSBQUklOVElORyBUSElTIEVNQUlMLg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3JheSI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIGxlZ2FsbHkgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9yIGFuIGF1dGhvcml6ZWQg cmVwcmVzZW50YXRpdmUgb2YgYW4gaW50ZW5kZWQNCiByZWNpcGllbnQsIHlvdSBhcmUgcHJvaGli aXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGluZyB0aGUgaW5mb3JtYXRpb24g aW4gdGhpcyBlLW1haWwgb3IgaXRzIGF0dGFjaG1lbnRzLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IHJldHVybiBlLW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZSBh bmQNCiBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdS4gPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3JlZW4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCjZ0aXNjaCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86NnRpc2No QGlldGYub3JnIj42dGlzY2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2giIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo2bG8g bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOjZsb0BpZXRmLm9yZyI+NmxvQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vNmxvIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsbzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_E045AECD98228444A58C61C200AE1BD848A1872Fxmbrcdx01ciscoc_-- From nobody Wed Oct 22 05:24: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 7BD431A90A0; Wed, 22 Oct 2014 05:24:26 -0700 (PDT) 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 p4FSiv5QgLcw; Wed, 22 Oct 2014 05:24:25 -0700 (PDT) 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 D3EE51A907A; Wed, 22 Oct 2014 05:24:24 -0700 (PDT) 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 s9MCO4hu012869; Wed, 22 Oct 2014 14:24:04 +0200 (CEST) Received: from [192.168.217.113] (p54890FCC.dip0.t-ipconnect.de [84.137.15.204]) (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 0B6C3CB0; Wed, 22 Oct 2014 14:24:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 22 Oct 2014 14:24:01 +0200 X-Mao-Original-Outgoing-Id: 435673440.051628-f7d30f12c663ad521055136c3bd8f5b4 Content-Transfer-Encoding: quoted-printable Message-Id: <687C8C64-CF05-405D-99DA-BCA6F7F3C60D@tzi.org> References: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-zh8CL9j8RBOm33MAVKzBRuFi0M Cc: Randy Turner , "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: Re: [Roll] [6lo] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 12:24:26 -0000 On 22 Oct 2014, at 14:21, Pascal Thubert (pthubert) = wrote: >=20 > 6554 already optimizes by factoring prefixes Well, yes. It still has a lot of static overhead. More importantly, in keeping with the routing header construction, it = keeps the full list downstream, which appears to me as a big waste of = energy. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 22 05:34: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 F35D21A90B3; Wed, 22 Oct 2014 05:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 BLtk5rV6QJxu; Wed, 22 Oct 2014 05:34:26 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::766]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199B11A8AD7; Wed, 22 Oct 2014 05:34:26 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0429.eurprd01.prod.exchangelabs.com (10.242.221.20) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 22 Oct 2014 12:34:01 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 12:34:01 +0000 From: "Turner, Randy" To: "Pascal Thubert (pthubert)" Thread-Topic: [6lo] [6tisch] [Roll] Call to confirm a rough consensus on RPL info Thread-Index: Ac/oQa0i5HZn0oJrT3qpZBX3hHGwVAAAfziAAVMzxgD//8E8AIAAWlSAgAAgGQCAAIi2gIAAA5cA Date: Wed, 22 Oct 2014 12:34:01 +0000 Message-ID: References: <4F0DAD50-F95F-4A07-B20C-4A1EC225BC14@amalfisystems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:0:8ec0:4a:c1e5:ade5:1c08:b976] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0429; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(189002)(24454002)(377454003)(85644002)(377424004)(199003)(55674003)(41574002)(16236675004)(80022003)(86362001)(101416001)(107046002)(122556002)(95666004)(40100003)(4396001)(19625215002)(105586002)(106356001)(99396003)(92566001)(92726001)(46102003)(85852003)(16799955002)(19617315012)(120916001)(110136001)(20776003)(64706001)(2656002)(87936001)(83716003)(76482002)(19580405001)(19580395003)(561944003)(54356999)(50986999)(93886004)(76176999)(82746002)(15975445006)(85306004)(33656002)(31966008)(97736003)(36756003)(21056001)(104396001)(24704002)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0429; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; Content-Type: multipart/alternative; boundary="_000_BCD258A0974444F2A215DA6AB55C2FBBlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HBhvfpXCbX193pXtU7IZ7xLZG1c Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Call to confirm a rough consensus on RPL info 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, 22 Oct 2014 12:34:40 -0000 --_000_BCD258A0974444F2A215DA6AB55C2FBBlandisgyrcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGFzY2FsDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgYXQgdGhl IG1vbWVudCwgaXQgd2FzIG1vcmUgb2YgYSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uIHdpdGggcmVn YXJkcyB0byB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgZnJvbSB0aGUgbGFzdCBwaG9uZSBjYWxsLCBz aW5jZSBJIHdhcyB1bmFibGUgdG8gcGFydGljaXBhdGUNCg0KVGhhbmtzIQ0KUmFuZHkNCg0KDQoN Ck9uIE9jdCAyMiwgMjAxNCwgYXQgODoyMSBBTSwgIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCki IDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+IHdyb3RlOg0K DQpIZWxsbyBSYW5keToNCg0KNjU1MyBpcyB3aGVyZSB0aGVyZSB3YXMgYSBsb3QgdG8gYmUgZ2Fp bmVkOyBPVE9ILCA2NTU0IGFscmVhZHkgb3B0aW1pemVzIGJ5IGZhY3RvcmluZyBwcmVmaXhlcy4g V291bGQgeW91IGhhdmUgc3VnZ2VzdGlvbnMgZm9yIGJldHRlcj8NCg0KQ2hlZXJzLA0KDQpQYXNj YWwNCg0KRnJvbTogNmxvIFttYWlsdG86NmxvLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBSYW5keSBUdXJuZXINClNlbnQ6IG1lcmNyZWRpIDIyIG9jdG9icmUgMjAxNCAwNjoxMg0KVG86 IFRob21hcyBXYXR0ZXluZQ0KQ2M6IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzOyBUdXJuZXIsIFJhbmR5OyA2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRm Lm9yZz47IDZsb0BpZXRmLm9yZzxtYWlsdG86NmxvQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFs2 bG9dIFs2dGlzY2hdIFtSb2xsXSBDYWxsIHRvIGNvbmZpcm0gYSByb3VnaCBjb25zZW5zdXMgb24g UlBMIGluZm8NCg0KWWVzLCBpbiBQYXNjYWwncyBjYWxsIGZvciBjb25zZW5zdXMgaGUgb25seSBt ZW50aW9ucyA2NTUzLi4uIEp1c3QgY3VyaW91cyBpZiB0aGUgcGhvbmUgY2FsbCBjb25zZW5zdXMg d2FzIG9ubHkgYWJvdXQgcmVxdWlyaW5nIGNvbXByZXNzaW9uIG9mIDY1NTMgb3B0aW9ucy4uLm9y IGFyZSB0aGVyZSBhbnkgb3RoZXIgY29tcHJlc3Npb24gbWV0aG9kcyB0aGF0IHRoZSBtaW5pbWFs IGRyYWZ0IG11c3QgaW5jbHVkZQ0KDQpUaGFua3MhDQpSYW5keQ0KDQpTZW50IGZyb20gbXkgaVBh ZA0KDQpPbiBPY3QgMjEsIDIwMTQsIGF0IDEwOjE2IFBNLCBUaG9tYXMgV2F0dGV5bmUgPHdhdHRl eW5lQGVlY3MuYmVya2VsZXkuZWR1PG1haWx0bzp3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdT4+ IHdyb3RlOg0KUmFuZHksDQpBcmUgeW91IGFsbHVkaW5nIHRvIDY1NTQ/DQpUaG9tYXMNCg0KT24g VHVlLCBPY3QgMjEsIDIwMTQgYXQgNTo1NiBQTSwgVHVybmVyLCBSYW5keSA8UmFuZHkuVHVybmVy QGxhbmRpc2d5ci5jb208bWFpbHRvOlJhbmR5LlR1cm5lckBsYW5kaXNneXIuY29tPj4gd3JvdGU6 DQoNCkkgdGhpbmsgSeKAmW0gKzEgb24gdGhlIHByb3Bvc2FsIOKAkyB3YXMgY29tcHJlc3Npb24g b2YgNjU1MyBvcHRpb25zIHRoZSBPTkxZIHJlcXVpcmVkIGNvbXByZXNzaW9uIGluIHRoZSDigJxt aW5pbWFs4oCdIGNhc2UgPyAoYXBvbG9naWVz4oCmSSB3YXNu4oCZdCBvbiB0aGUgY2FsbCkgSSBk aWQgYSBxdWljayBzZWFyY2ggb2YgbWluaW1hbC0wMiBhbmQgZGlkbuKAmXQgc2VlIHRoZSB3b3Jk IGNvbXByZXNzaW9uIGFueXdoZXJlLg0KDQpUaGFua3MhDQpSYW5keQ0KDQpGcm9tOiBUaG9tYXMg V2F0dGV5bmUgPHdhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PG1haWx0bzp3YXR0ZXluZUBlZWNz LmJlcmtlbGV5LmVkdT4+DQpSZXBseS1UbzogInJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0 Zi5vcmc+IiA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpEYXRlOiBUdWVz ZGF5LCBPY3RvYmVyIDIxLCAyMDE0IGF0IDg6MzggUE0NClRvOiAicm9sbEBpZXRmLm9yZzxtYWls dG86cm9sbEBpZXRmLm9yZz4iIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4N CkNjOiAiNmxvLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86NmxvLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4iIDw2bG8tY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzo2bG8tY2hhaXJzQHRv b2xzLmlldGYub3JnPj4sICI2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4i IDw2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4+LCAiNmxvQGlldGYub3Jn PG1haWx0bzo2bG9AaWV0Zi5vcmc+IiA8NmxvQGlldGYub3JnPG1haWx0bzo2bG9AaWV0Zi5vcmc+ PiwgInJvbGwtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpyb2xsLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4iIDxyb2xsLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cm9sbC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+PiwgIjZ0aXNjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOjZ0 aXNjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+IiA8NnRpc2NoLWNoYWlyc0B0b29scy5pZXRmLm9y ZzxtYWlsdG86NnRpc2NoLWNoYWlyc0B0b29scy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1Jv bGxdIENhbGwgdG8gY29uZmlybSBhIHJvdWdoIGNvbnNlbnN1cyBvbiBSUEwgaW5mbw0KDQorMSBv biB0aGUgcHJvcG9zYWwuDQoNCk9uIFR1ZSwgT2N0IDE0LCAyMDE0IGF0IDExOjQ1IFBNLCBYYXZp ZXIgVmlsYWpvc2FuYSA8eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHU8bWFpbHRvOnh2aWxh am9zYW5hQGVlY3MuYmVya2VsZXkuZWR1Pj4gd3JvdGU6DQpBbGwsDQoNCkkgZnVsbHkgc3VwcG9y dCB0aGF0IGFwcHJvYWNoLiBIb3BlIHRvIGNvbnRyaWJ1dGUgYW5kIG1ha2UgaXQgaGFwcGVuIGFz IHNvb24gYXMgcG9zc2libGUuDQoNCnJlZ2FyZHMsDQpYYXZpDQoNCjIwMTQtMTAtMTUgODozMiBH TVQrMDI6MDAgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1h aWx0bzpwdGh1YmVydEBjaXNjby5jb20+PjoNCg0KRGVhciBhbGw6DQoNCkR1cmluZyB0aGUgNlRp U0NIIGJpLXdlZWtseSB2aXJ0dWFsIGludGVyaW0gb24gRnJpZGF5LCB3ZSBhZ3JlZWQgdGhhdCB0 aGUgbWluaW1hbCBJLUQgKGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwpIG11c3QgaW5kaWNhdGUg dGhlIGNvbXByZXNzaW9uIG1ldGhvZCBmb3IgdGhlIFJQTCBJbmZvcm1hdGlvbiAoc2VlIFJGQyA2 NTUzKSwgc28gYXMgdG8gZW5zdXJlIGludGVyb3BlcmF0aW9uIGJldHdlZW4gNlRpU0NIIGRldmlj ZXMuDQoNCldlIGRpc2N1c3NlZCBvdXIgb3B0aW9ucywgYmFzaWNhbGx5IGVpdGhlciBhIDZsbyBh cHByb2FjaCBvciBhIEZsb3cgTGFiZWwgYXBwcm9hY2guIFRoZSByb3VnaCBjb25zZW5zdXMgYXQg dGhlIGNhbGwgd2FzIHRvIHRyeSBhbmQgZm9jdXMgb24gYSA2bG8gYXBwcm9hY2ggYW5kIGV2YWx1 YXRlIHdoZXJlIHRoYXQgbGVhZHMgdXMuDQoNCkJlY2F1c2UgdGhpcyBtZWFucyB0aGF0IHRoZSBt aW5pbWFsIGRyYWZ0IHdpbGwgaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ugb24gYSBXSVAgSS1E LCB3ZSByZWNvZ25pemVkIHRoYXQgdGhpcyBhcHByb2FjaCBtYXkgZGVsYXkgdGhlIHB1YmxpY2F0 aW9uIG9mIHRoZSBmaW5hbCBSRkMuIFBlciBJRVRGIHByb2NlZHVyZXMsIHRoZSBtaW5pbWFsIGRy YWZ0IHdpbGwgYmUgc3RhbGxlZCBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSBpbiBNSVNSRUYgc3Rh dGUgdW50aWwgdGhlIDZsbyB3b3JrIGNvbXBsZXRlcy4gU28gdGhlIGNvbnNlbnN1cyB3YXMgYWxz byB0byBzdXBwb3J0IHRoZSA2bG8gd29yayBzbyBhcyB0byBleHBlZGl0ZSBpdCBhcyBtdWNoIGFz IHBvc3NpYmxlLg0KDQpUaGUgaWRlYSB3b3VsZCBiZSB0byByZXB1Ymxpc2ggYSBzdGFuZGFyZCB0 cmFjayBkcmFmdC1pZXRmLTZsby0gQVNBUCwgYmFzZWQgb24gdGhlIGV4aXN0aW5nIHByb3Bvc2Fs cyAod2hpY2ggYXJlIHJhcGlkbHkgY29udmVyZ2luZyk7IHRoZW4sIFhhdmkgd291bGQgaW5jbHVk ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gdGhhdCB3b3JrIGluIHRoZSBtaW5pbWFsIEktRCBi ZWZvcmUgaXRzIHB1YmxpY2F0aW9uIHRvIElFU0csIHdoaWNoIGlzIHNjaGVkdWxlZCBpbiBOb3Zl bWJlciAoeWVzLCB0aGlzIGlzIGFnZ3Jlc3NpdmUpLg0KDQpUaGlzIGlzIGEgY2FsbCB0byBjb25m aXJtIHRoZSByb3VnaCBjb25zZW5zdXMgb24gdGhlIE1MLCBvcGVuIHRpbGwgdGhlIG5leHQgaW50 ZXJpbSBjYWxsIG9uIE9jdG9iZXIgMjR0aC4gUGxlYXNlIHByb3ZpZGUgdXMgd2l0aCBhbnkgcmVs ZXZhbnQgY29tbWVudCAoYW5kIHBhcnRpY2lwYXRlIHRvIHRoZSA2bG8gZGlzY3Vzc2lvbnMgaW4g dGhlIG1lYW50aW1lISkuDQoNCklmIHRoZSByZXN1bHQgaXMgcG9zaXRpdmU6DQotIHdlIHBsYW4g dG8gY2FsbCBmb3IgYSA2bG8gV0cgZG9jIGFkb3B0aW9uIGluIEhhd2FpaQ0KLSB3ZSBhcmUgbG9v a2luZyBmb3IgYW4gYWdncmVzc2l2ZSBzY2hlZHVsZSB0byBsaW1pdCB0aGUgaW1wYWN0IG9uIHRo ZSBwdWJsaWNhdGlvbiBvZiB0aGUgbWluaW1hbCBSRkMNCg0KNlRpU0NIIG1heSBob3N0IHRoZSA2 bG8gZGlzY3Vzc2lvbiBzbyBhcyB0bzoNCi0gYmVuZWZpdCBmcm9tIHRoZSBlYXJseSBtb3JuaW5n IHNjaGVkdWxlDQotIGF0dHJhY3QgbW9yZSA2VGlTQ0ggcGVvcGxlIHRvIHRoZSBkaXNjdXNzaW9u DQoNCk1vcmUgdGhlIHB1Ymxpc2hlZCBtaW51dGVzOg0KLSBXZWJleCByZWNvcmRpbmc6IGh0dHBz Oi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTM2YTNiN2RmMDY2OTQy NThhM2FjNjViZmM1MTkyMTJmDQotIFdpa2k6IGh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gv bWVldGluZ3Mvd2lraS8xNDEwMTBfd2ViZXgNCi0gU2xpZGVzOiBodHRwczovL2JpdGJ1Y2tldC5v cmcvNnRpc2NoL21lZXRpbmdzL3NyYy9tYXN0ZXIvMTQxMDEwX3dlYmV4L3NsaWRlc18xNDEwMTBf d2ViZXgucHB0DQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9y ZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KDQoNCg0K UCBQTEVBU0UgQ09OU0lERVIgT1VSIEVOVklST05NRU5UIEJFRk9SRSBQUklOVElORyBUSElTIEVN QUlMLg0KDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlk ZW50aWFsIGFuZCBtYXkgYmUgbGVnYWxseSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQgb3IgYW4gYXV0aG9yaXplZCByZXByZXNlbnRhdGl2ZSBvZiBhbiBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5n IG9yIGRpc3RyaWJ1dGluZyB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlLW1haWwgb3IgaXRzIGF0 dGFjaG1lbnRzLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlLW1haWwgYW5kIGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFu ayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2bG8gbWFpbGlu ZyBsaXN0DQo2bG9AaWV0Zi5vcmc8bWFpbHRvOjZsb0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvDQo= --_000_BCD258A0974444F2A215DA6AB55C2FBBlandisgyrcom_ Content-Type: text/html; charset="utf-8" Content-ID: <78F9F06DAAF9E541B9E243748D33EEAD@LandisGyr.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpIFBhc2NhbDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkb24ndCBoYXZl IGFueSBzcGVjaWZpYyBzdWdnZXN0aW9ucyBhdCB0aGUgbW9tZW50LCBpdCB3YXMgbW9yZSBvZiBh IGNsYXJpZmljYXRpb24gcXVlc3Rpb24gd2l0aCByZWdhcmRzIHRvIHRoZSBnZW5lcmFsIGNvbnNl bnN1cyBmcm9tIHRoZSBsYXN0IHBob25lIGNhbGwsIHNpbmNlIEkgd2FzIHVuYWJsZSB0byBwYXJ0 aWNpcGF0ZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzITwvZGl2Pg0KPGRp dj5SYW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCk9uIE9jdCAyMiwgMjAxNCwgYXQgODoyMSBBTSwgJnF1b3Q7UGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+ cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXZWJkaW5nczsNCglwYW5vc2UtMTo1IDMgMSAyIDEgNSA5IDYgNyAz O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIFJhbmR5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NjU1MyBpcyB3aGVyZSB0 aGVyZSB3YXMgYSBsb3QgdG8gYmUgZ2FpbmVkOyBPVE9ILCA2NTU0IGFscmVhZHkgb3B0aW1pemVz IGJ5IGZhY3RvcmluZyBwcmVmaXhlcy4gV291bGQgeW91IGhhdmUgc3VnZ2VzdGlvbnMgZm9yIGJl dHRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA2bG8gWzxhIGhyZWY9 Im1haWx0bzo2bG8tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOjZsby1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmFuZHkgVHVybmVyPGJyPg0KPGI+U2VudDo8L2I+ IG1lcmNyZWRpIDIyIG9jdG9icmUgMjAxNCAwNjoxMjxicj4NCjxiPlRvOjwvYj4gVGhvbWFzIFdh dHRleW5lPGJyPg0KPGI+Q2M6PC9iPiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBu ZXR3b3JrczsgVHVybmVyLCBSYW5keTsgPGEgaHJlZj0ibWFpbHRvOjZ0aXNjaEBpZXRmLm9yZyI+ DQo2dGlzY2hAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIj42bG9A aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbNmxvXSBbNnRpc2NoXSBbUm9s bF0gQ2FsbCB0byBjb25maXJtIGEgcm91Z2ggY29uc2Vuc3VzIG9uIFJQTCBpbmZvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgaW4gUGFz Y2FsJ3MgY2FsbCBmb3IgY29uc2Vuc3VzIGhlIG9ubHkgbWVudGlvbnMgNjU1My4uLiBKdXN0IGN1 cmlvdXMgaWYgdGhlIHBob25lIGNhbGwgY29uc2Vuc3VzIHdhcyBvbmx5IGFib3V0IHJlcXVpcmlu ZyBjb21wcmVzc2lvbiBvZiA2NTUzIG9wdGlvbnMuLi5vciBhcmUgdGhlcmUgYW55IG90aGVyIGNv bXByZXNzaW9uIG1ldGhvZHMgdGhhdCB0aGUgbWluaW1hbCBkcmFmdCBtdXN0IGluY2x1ZGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFu ZHk8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpPbiBPY3QgMjEsIDIwMTQsIGF0IDEwOjE2IFBNLCBUaG9tYXMgV2F0dGV5bmUgJmx0Ozxh IGhyZWY9Im1haWx0bzp3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdSI+d2F0dGV5bmVAZWVjcy5i ZXJrZWxleS5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhbmR5LDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3UgYWxsdWRpbmcgdG8gNjU1ND88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob21hczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IE9jdCAyMSwgMjAxNCBhdCA1OjU2IFBNLCBUdXJuZXIsIFJhbmR5ICZsdDs8YSBocmVmPSJtYWls dG86UmFuZHkuVHVybmVyQGxhbmRpc2d5ci5jb20iIHRhcmdldD0iX2JsYW5rIj5SYW5keS5UdXJu ZXJAbGFuZGlzZ3lyLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SSB0aGluayBJ4oCZbSAmIzQzOzEgb24gdGhlIHByb3Bvc2FsIOKAkyB3YXMgY29tcHJlc3Np b24gb2YgNjU1MyBvcHRpb25zIHRoZSBPTkxZIHJlcXVpcmVkIGNvbXByZXNzaW9uIGluIHRoZSDi gJxtaW5pbWFs4oCdIGNhc2UgPyAoYXBvbG9naWVz4oCmSSB3YXNu4oCZdCBvbiB0aGUgY2FsbCkg SSBkaWQNCiBhIHF1aWNrIHNlYXJjaCBvZiBtaW5pbWFsLTAyIGFuZCBkaWRu4oCZdCBzZWUgdGhl IHdvcmQgY29tcHJlc3Npb24gYW55d2hlcmUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5SYW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhvbWFzIFdhdHRleW5lICZsdDs8YSBocmVmPSJtYWlsdG86d2F0 dGV5bmVAZWVjcy5iZXJrZWxleS5lZHUiIHRhcmdldD0iX2JsYW5rIj53YXR0ZXluZUBlZWNzLmJl cmtlbGV5LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+UmVwbHktVG86IDwvYj4mcXVvdDs8YSBocmVmPSJt YWlsdG86cm9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJvbGxAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJv bGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBPY3RvYmVyIDIx LCAyMDE0IGF0IDg6MzggUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpy b2xsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cm9sbEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cm9sbEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86NmxvLWNo YWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsby1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86NmxvLWNoYWlyc0B0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsby1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOjZ0aXNjaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZ0 aXNjaEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZ0aXNjaEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZ0aXNjaEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86NmxvQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NmxvQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZsb0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjZsb0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cm9sbC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yb2xsLWNoYWlyc0B0b29scy5pZXRmLm9y ZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGwtY2hhaXJzQHRvb2xzLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cm9sbC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOjZ0aXNjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj42dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOjZ0aXNjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij42dGlzY2gtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtSb2xsXSBDYWxsIHRvIGNvbmZpcm0gYSByb3VnaCBjb25zZW5zdXMgb24gUlBMIGlu Zm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiYjNDM7MSBvbiB0aGUgcHJvcG9zYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5PbiBUdWUsIE9jdCAxNCwgMjAxNCBhdCAxMTo0NSBQTSwgWGF2aWVyIFZpbGFqb3NhbmEg Jmx0OzxhIGhyZWY9Im1haWx0bzp4dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdSIgdGFyZ2V0 PSJfYmxhbmsiPnh2aWxham9zYW5hQGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWxsLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5JIGZ1bGx5IHN1cHBvcnQgdGhhdCBhcHByb2FjaC4gSG9wZSB0byBjb250cmli dXRlIGFuZCBtYWtlIGl0IGhhcHBlbiBhcyBzb29uIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5yZWdhcmRzLDxicj4NClhhdmk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+MjAxNC0xMC0xNSA4OjMyIEdNVCYjNDM7MDI6MDAgUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7Og0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgYWxsOjxicj4NCjxicj4NCkR1cmluZyB0aGUg NlRpU0NIIGJpLXdlZWtseSB2aXJ0dWFsIGludGVyaW0gb24gRnJpZGF5LCB3ZSBhZ3JlZWQgdGhh dCB0aGUgbWluaW1hbCBJLUQgKGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwpIG11c3QgaW5kaWNh dGUgdGhlIGNvbXByZXNzaW9uIG1ldGhvZCBmb3IgdGhlIFJQTCBJbmZvcm1hdGlvbiAoc2VlIFJG QyA2NTUzKSwgc28gYXMgdG8gZW5zdXJlIGludGVyb3BlcmF0aW9uIGJldHdlZW4gNlRpU0NIIGRl dmljZXMuPGJyPg0KPGJyPg0KV2UgZGlzY3Vzc2VkIG91ciBvcHRpb25zLCBiYXNpY2FsbHkgZWl0 aGVyIGEgNmxvIGFwcHJvYWNoIG9yIGEgRmxvdyBMYWJlbCBhcHByb2FjaC4gVGhlIHJvdWdoIGNv bnNlbnN1cyBhdCB0aGUgY2FsbCB3YXMgdG8gdHJ5IGFuZCBmb2N1cyBvbiBhIDZsbyBhcHByb2Fj aCBhbmQgZXZhbHVhdGUgd2hlcmUgdGhhdCBsZWFkcyB1cy48YnI+DQo8YnI+DQpCZWNhdXNlIHRo aXMgbWVhbnMgdGhhdCB0aGUgbWluaW1hbCBkcmFmdCB3aWxsIGhhdmUgYSBub3JtYXRpdmUgcmVm ZXJlbmNlIG9uIGEgV0lQIEktRCwgd2UgcmVjb2duaXplZCB0aGF0IHRoaXMgYXBwcm9hY2ggbWF5 IGRlbGF5IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZmluYWwgUkZDLiBQZXIgSUVURiBwcm9jZWR1 cmVzLCB0aGUgbWluaW1hbCBkcmFmdCB3aWxsIGJlIHN0YWxsZWQgaW4gdGhlIFJGQyBlZGl0b3Ig cXVldWUgaW4gTUlTUkVGIHN0YXRlDQogdW50aWwgdGhlIDZsbyB3b3JrIGNvbXBsZXRlcy4gU28g dGhlIGNvbnNlbnN1cyB3YXMgYWxzbyB0byBzdXBwb3J0IHRoZSA2bG8gd29yayBzbyBhcyB0byBl eHBlZGl0ZSBpdCBhcyBtdWNoIGFzIHBvc3NpYmxlLjxicj4NCjxicj4NClRoZSBpZGVhIHdvdWxk IGJlIHRvIHJlcHVibGlzaCBhIHN0YW5kYXJkIHRyYWNrIGRyYWZ0LWlldGYtNmxvLSBBU0FQLCBi YXNlZCBvbiB0aGUgZXhpc3RpbmcgcHJvcG9zYWxzICh3aGljaCBhcmUgcmFwaWRseSBjb252ZXJn aW5nKTsgdGhlbiwgWGF2aSB3b3VsZCBpbmNsdWRlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0 aGF0IHdvcmsgaW4gdGhlIG1pbmltYWwgSS1EIGJlZm9yZSBpdHMgcHVibGljYXRpb24gdG8gSUVT Rywgd2hpY2ggaXMgc2NoZWR1bGVkDQogaW4gTm92ZW1iZXIgKHllcywgdGhpcyBpcyBhZ2dyZXNz aXZlKS48YnI+DQo8YnI+DQpUaGlzIGlzIGEgY2FsbCB0byBjb25maXJtIHRoZSByb3VnaCBjb25z ZW5zdXMgb24gdGhlIE1MLCBvcGVuIHRpbGwgdGhlIG5leHQgaW50ZXJpbSBjYWxsIG9uIE9jdG9i ZXIgMjR0aC4gUGxlYXNlIHByb3ZpZGUgdXMgd2l0aCBhbnkgcmVsZXZhbnQgY29tbWVudCAoYW5k IHBhcnRpY2lwYXRlIHRvIHRoZSA2bG8gZGlzY3Vzc2lvbnMgaW4gdGhlIG1lYW50aW1lISkuPGJy Pg0KPGJyPg0KSWYgdGhlIHJlc3VsdCBpcyBwb3NpdGl2ZTo8YnI+DQotIHdlIHBsYW4gdG8gY2Fs bCBmb3IgYSA2bG8gV0cgZG9jIGFkb3B0aW9uIGluIEhhd2FpaTxicj4NCi0gd2UgYXJlIGxvb2tp bmcgZm9yIGFuIGFnZ3Jlc3NpdmUgc2NoZWR1bGUgdG8gbGltaXQgdGhlIGltcGFjdCBvbiB0aGUg cHVibGljYXRpb24gb2YgdGhlIG1pbmltYWwgUkZDPGJyPg0KPGJyPg0KNlRpU0NIIG1heSBob3N0 IHRoZSA2bG8gZGlzY3Vzc2lvbiBzbyBhcyB0bzo8YnI+DQotIGJlbmVmaXQgZnJvbSB0aGUgZWFy bHkgbW9ybmluZyBzY2hlZHVsZTxicj4NCi0gYXR0cmFjdCBtb3JlIDZUaVNDSCBwZW9wbGUgdG8g dGhlIGRpc2N1c3Npb248YnI+DQo8YnI+DQpNb3JlIHRoZSBwdWJsaXNoZWQgbWludXRlczo8YnI+ DQotIFdlYmV4IHJlY29yZGluZzogPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lz Y29zYWxlcy9sc3IucGhwP1JDSUQ9MzZhM2I3ZGYwNjY5NDI1OGEzYWM2NWJmYzUxOTIxMmYiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBo cD9SQ0lEPTM2YTNiN2RmMDY2OTQyNThhM2FjNjViZmM1MTkyMTJmPC9hPjxicj4NCi0gV2lraTog PGEgaHJlZj0iaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy93aWtpLzE0MTAx MF93ZWJleCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9t ZWV0aW5ncy93aWtpLzE0MTAxMF93ZWJleDwvYT48YnI+DQotIFNsaWRlczogPGEgaHJlZj0iaHR0 cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy9zcmMvbWFzdGVyLzE0MTAxMF93ZWJl eC9zbGlkZXNfMTQxMDEwX3dlYmV4LnBwdCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9iaXRi dWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy9zcmMvbWFzdGVyLzE0MTAxMF93ZWJleC9zbGlkZXNf MTQxMDEwX3dlYmV4LnBwdDwvYT48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJyPg0KUGFzY2Fs PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+Um9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJv bGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2ViZGlu Z3M7Y29sb3I6Z3JlZW4iPlA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpncmVlbiI+IFBMRUFTRSBDT05TSURFUiBPVVIgRU5WSVJPTk1FTlQgQkVGT1JFIFBSSU5U SU5HIFRISVMgRU1BSUwuDQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUgbGVnYWxseSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQgb3IgYW4gYXV0aG9yaXplZCByZXByZXNl bnRhdGl2ZSBvZiBhbiBpbnRlbmRlZA0KIHJlY2lwaWVudCwgeW91IGFyZSBwcm9oaWJpdGVkIGZy b20gdXNpbmcsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW5nIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGlz IGUtbWFpbCBvciBpdHMgYXR0YWNobWVudHMuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgcmV0 dXJuIGUtbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlIGFuZA0KIGFu eSBhdHRhY2htZW50cy4gVGhhbmsgeW91LiA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpncmVlbiI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KNnRpc2NoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5v cmciPjZ0aXNjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjZsbyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIj42bG9AaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG8i Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BCD258A0974444F2A215DA6AB55C2FBBlandisgyrcom_-- From nobody Sat Oct 25 00:36: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 4223A1A6FFC; Sat, 25 Oct 2014 00:36:05 -0700 (PDT) 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 QtiEl2xediiU; Sat, 25 Oct 2014 00:35:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5981A86E5; Sat, 25 Oct 2014 00:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3416; q=dns/txt; s=iport; t=1414222556; x=1415432156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JYhis4ewxgs8P7QfLmn29kQrsX1/51GjRpLv+y4d2EA=; b=ZSHJcENl8S8RKjm6eVC93lX1P6HmDUaxWFsMUnAnKoP/OL3XBFDkURjR qxTYHlbb/y5Zl7qHdNuKSZXgR49rbg9Ap/Oo+P/Y1mRk98k8x0sIioenH TGM17CQcOUVSsumJrUt9TlVAbivl13YlLoPxCJo+PTeTRiokdM5N8YgIs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAABSS1StJA2G/2dsb2JhbABcgw5UUwUEgwLKOodNAhttFgFyC4QCAQEBBB0GEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYg4CAW0a5RrAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EsjnsxBwaCcTaBHgWSBYRGiEM8gw2NMoQAg3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,785,1406592000"; d="scan'208";a="90237728" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 25 Oct 2014 07:35:56 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9P7ZuMh012459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 07:35:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 02:35:55 -0500 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt Thread-Index: AQHP8CIgD51vBwmfZ0CvTQvGW8iUy5xAan8g Date: Sat, 25 Oct 2014 07:35:55 +0000 Deferred-Delivery: Sat, 25 Oct 2014 07:35:00 +0000 Message-ID: References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> In-Reply-To: <20141025070548.825.87046.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.61.212.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/q_IK_s4b1g5m8Jc_f9SqqZzN4YM Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: [Roll] 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: Sat, 25 Oct 2014 07:36:05 -0000 RGVhciBhbGw6DQoNCldlIGhhdmUgY29udmVyZ2VkIGZvciBtb3N0IG9mIHRoZSBkZXNpZ24gb2Yg dGhlIDZsbyBjb21wcmVzc2lvbiBmb3IgdGhlIFJQTCBwYWNrZXQgaW5mb3JtYXRpb24gYW5kIHJl cHVibGlzaGVkLiANCkEgbWFqb3IgcXVlc3Rpb24gaXMgbGVmdCBvbiB0aGUgdGFibGUgZm9yIHRo ZSB3b3JraW5nIGdyb3VwLCBhbmQgaXNvbGF0ZWQgaW4gc2VjdGlvbiA0LjMsIHdpdGggMyBhcHBy b2FjaGVzIHByb3Bvc2VkLg0KDQogICAgIDQuMy4gIFRoZSBSUElfTkhDIGVuY29kaW5nICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgICA0LjMuMS4gIFRoZSBH cmVlZHkgQXBwcm9hY2ggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KICAg ICAgIDQuMy4yLiAgVGhlIENvbnNlcnZhdGl2ZSBBcHByb2FjaCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA3DQogICAgICAgNC4zLjMuICBUaGUgRWZmaWNpZW50IEFwcHJvYWNoICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCg0KWW91ciByZXZpZXcgcHJpb3IgdG8gdGhl IElFVEYgbWVldGluZyB3aWxsIGJlIGFwcHJlY2lhdGVkIG1vcmUgdGhhbiBldmVyLg0KQXQgdGhl IDZsbyBtZWV0aW5nLCB3ZSBleHBlY3QgdG8gaGF2ZSBhIHNsb3QgYW5kIG9idGFpbiBhIHJvdWdo IGNvbnNlbnN1cyBvZiB0aGUgcm9vbSBvbiB0aGF0IHBhcnRpY3VsYXIgcXVlc3Rpb24uDQpXZSB3 aWxsIGFsc28gY2FsbCBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIHRoZXJlIHNlZW1zIHRvIGJl IGEgd2lsbCB0byBwcm9wb3NlIGEgY29tcHJlc3Npb24gZm9yIHRoZSBSb3V0aW5nIEhlYWRlciBh cyB1c2VzIGluIFJQTCBub24tc3RvcmluZyBtb2RlLCBhbmQgaG9wZWZ1bGx5IHdlIHdpbGwgc2Vl IHByb3Bvc2FscyBzb29uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogc2FtZWRpIDI1IG9jdG9icmUgMjAxNCAwOTow Ng0KVG86IENhcnN0ZW4gQm9ybWFubjsgRHIuIENhcnN0ZW4gQm9ybWFubjsgUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LTZsby1ycGwtbmhjLTAyLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LTZsby1ycGwtbmhjLTAyLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXRodWJlcnQtNmxv LXJwbC1uaGMNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlBIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBm b3IgdGhlIFJQTCBvcHRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjQNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEzDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC02bG8tcnBsLW5oYy0wMi50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10aHViZXJ0LTZsby1ycGwtbmhjLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtNmxvLXJwbC1uaGMtMDINCkRpZmY6ICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10aHViZXJ0LTZsby1ycGwtbmhj LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIFJQTCBQ YWNrZXQgSW5mb3JtYXRpb24gKFJQSSkgTkhDDQogICBjb21wcmVzc2lvbiwgYSBtZXRob2QgdG8g Y29tcHJlc3MgUlBMIE9wdGlvbiAoUkZDNjU1MykgaW5mb3JtYXRpb24NCiAgIHdpdGhpbiA2TG9X UEFOLXN0eWxlICgiNmxvIikgYWRhcHRhdGlvbiBsYXllcnMuICBUaGlzIGV4dGVuZHMgNkxvV1BB Tg0KICAgSGVhZGVyIENvbXByZXNzaW9uIChSRkM2MjgyKSwgc2F2aW5nIHVwIHRvIDQ4IGJpdHMg aW4gZWFjaCBmcmFtZQ0KICAgY29tcGFyZWQgdG8gdGhlIHVuY29tcHJlc3NlZCBmb3JtIGluIFJG QyA2NTUzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sun Oct 26 22:54: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 773511A6F61 for ; Sun, 26 Oct 2014 22:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 gflhDzKkmI-A for ; Sun, 26 Oct 2014 22:54:13 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1001A00FC for ; Sun, 26 Oct 2014 22:54:12 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so5130783lab.6 for ; Sun, 26 Oct 2014 22:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cCZpsY7Ud6OEPnE/3cpL8m96LxaRSwqnqUTr462eYeI=; b=z5o8nimbHVFylXFz7aRmGZqb4HYfnvAujLD0CE/9ov3FRrkruxfDjAN25VSqUpHipo D73izrFe92r6c3zqpLb2OuGD5mdleqXm9jhq4XRz+YFqGhPrWyN/5IOdV/H1jBbxlaZJ QXPZxtEQKPpl1FfJsfCLi3TrAkMS5OxceTZ4waFarGNIgftD3GvJu1BH2z0eXrbRgvUw +L6xO+M7/48SvPs7ByjA9zlhwrtzF9ae5cWA0Vk5jf6cV3I+/S5oFAK2yfuKqDgEgawk nbs4hQgMpWY2b8x9P/Rzefq1H70zadNXIc8+rmAAG5+6oDhO2oYa21xRg99R6dqbNkVe xzGA== MIME-Version: 1.0 X-Received: by 10.112.156.168 with SMTP id wf8mr21089871lbb.28.1414389251101; Sun, 26 Oct 2014 22:54:11 -0700 (PDT) Received: by 10.25.24.193 with HTTP; Sun, 26 Oct 2014 22:54:11 -0700 (PDT) Date: Mon, 27 Oct 2014 07:54:11 +0200 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c33f6ee2da540506612807 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5QlUJjcUNdhMIIk8rQvBCUZP9UY Cc: Michael Richardson Subject: [Roll] WGLC for draft-ietf-roll-admin-local-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: Mon, 27 Oct 2014 05:54:14 -0000 --001a11c33f6ee2da540506612807 Content-Type: text/plain; charset=UTF-8 Dear all, To the authors, thanks for this new version of the draft. A Working Group Last call (WGLC) starts today (10/27) until 11/17/2014 for draft-ietf-roll-admin-local-policy The draft is available here: *https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ * *http://tools.ietf.org/html/draft-ietf-roll-admin-local-policy-01 * Please review this draft to see if you think it is ready for publication and send comments to the list stating your view. Thank you very much in advance, Michael and Ines. 2014-10-22 12:50 GMT+03:00 peter van der Stok : > Dear wg, > > I submitted a new version of draft-ietf-roll-admin-local-policy. > Given the remarks I received, the following changes were done with respect > to the former version. > > > o Default parameter values declared > > o Security section extended > > o scope 5 of higher messages specified > > o messages with address ALL_MPL_FORWARDERS are not allowed from > outside zone > > Looking forward to your comments, > > Peter > > ____________________________________________________________ --001a11c33f6ee2da540506612807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,


To the authors, thanks for this new version of the dr= aft.


A Working Group Las= t call (WGLC) starts today (10/27) until 11/17/2014 for draft-ietf-roll-adm= in-local-policy


The draf= t is available here:

https://= datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/=

http://tools.ietf.org/html/dr= aft-ietf-roll-admin-local-policy-01


<= span style=3D"font-family:Arial;vertical-align:baseline;white-space:pre-wra= p;background-color:transparent">Please review this draft to see if you thin= k it is ready for publication and send comments to the list stating your vi= ew.


Thank you very much = in advance,


Michael and Ines.

2014-10-22 12:50 GMT+03:00 peter van de= r Stok <stokcons@xs4all.nl>:
Dear wg,

I submitted a new version of draft-ietf-roll-admin-local-policy.
Given the remarks I received, the following changes were done with respect = to the former version.


=C2=A0 =C2=A0o=C2=A0 Default parameter values declared

=C2=A0 =C2=A0o=C2=A0 Security section extended

=C2=A0 =C2=A0o=C2=A0 scope 5 of higher messages specified

=C2=A0 =C2=A0o=C2=A0 messages with address ALL_MPL_FORWARDERS are not allow= ed from
=C2=A0 =C2=A0 =C2=A0 outside zone

Looking forward to your comments,

Peter

____________________________________________________________
--001a11c33f6ee2da540506612807--