From mcr@sandelman.ca Fri Nov 1 16:33:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695DE21E80B0 for ; Fri, 1 Nov 2013 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q97ujF++TmfO for ; Fri, 1 Nov 2013 16:33:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2509C21E808A for ; Fri, 1 Nov 2013 16:33:01 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 5D8FF22078; Fri, 1 Nov 2013 19:33:01 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9C39ECA0DA; Fri, 1 Nov 2013 16:51:39 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-reply-to: <641a5c59776214374984816097e08d9a@xs4all.nl> References: <524E7734.1010604@toshiba.co.jp> <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> <524EA0B9.4090908@toshiba.co.jp> <641a5c59776214374984816097e08d9a@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Fri, 04 Oct 2013 14:02:29 +0200." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Message-Id: <20131101205139.9C39ECA0DA@sandelman.ca> Date: Fri, 1 Nov 2013 16:51:39 -0400 (EDT) Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 23:33:23 -0000 : signature: ~/.signature.ietf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 16:51:39 -0400 Message-ID: <14038.1383339099@sandelman.ca> Sender: mcr@sandelman.ca --=-=-= Content-Transfer-Encoding: quoted-printable peter van der Stok wrote: > Hi Yusuke, >=20 > For the moment the parameters are general for al interfaces, seeds and > messages. > In the case of changing per message, the parameter sets need to be > attached to each message entry. (for me that is a large change) I don't think he wants to do it per message He wants to use some out-of-scope management interface to tweak the values as the network grows, changes, or as performance data is gathered. The question could be restated as: What is the affect on MPL stability is nodes differ on Imin, etc. by up= to 10% while data transmission is active.=20=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdBRbAAoJEKD0KQ7Gj3P2kj8H/ike9DqI9tR228HfVcDliJ6b YztcVjUVDM/LokYO3YXh/dcWDZi0CPo72iDLqGULxNxgTDG87qdLT/EQuRFjNqmS faBPxGVj+gjVWiOEgEwA9ZouO50mLQJnZ9gbZeeE/W9XS/MXmLCeawihS0FUo4u2 Anh4mvtb+8d2tq9rb8fN84uLzR0gmtXRr/FIFrQck36OOLRrxN5Ck9DR2PmAAQW4 Zn+72zsJkIUBeVLKprDXqTpzWqCWNrDlP2aIz7icJU1uN/0ySA81alYiSeTUyV1T 7b4J4XWPv0CL8gkbz6AhTISvYw87c9m57635woWilxw1Iwu1ZoGTwjQ3Ls+AedA= =oYtQ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 1 16:33:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ECA21E8091 for ; Fri, 1 Nov 2013 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l75F+qaLiBRn for ; Fri, 1 Nov 2013 16:33:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0D21E8088 for ; Fri, 1 Nov 2013 16:33:01 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 45D2C2207A for ; Fri, 1 Nov 2013 19:33:01 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D00DDCA0D8 for ; Fri, 1 Nov 2013 16:41:55 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <525BFA61.4040104@gridmerge.com> References: <20131010221713.891.32620.idtracker@ietfa.amsl.com> <525BFA61.4040104@gridmerge.com> Comments: In-reply-to Robert Cragie message dated "Mon, 14 Oct 2013 15:06:25 +0100." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Message-Id: <20131101204155.D00DDCA0D8@sandelman.ca> Date: Fri, 1 Nov 2013 16:41:55 -0400 (EDT) Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 23:33:23 -0000 : signature: ~/.signature.ietf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 16:41:55 -0400 Message-ID: <13680.1383338515@sandelman.ca> Sender: mcr@sandelman.ca --=-=-= Robert Cragie wrote: > I would propose adding the language to > draft-ietf-roll-trickle-mcast. There doesn't seem much point to doing > another "world's shortest RFC". I agree. Michael Richardson -on the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdBITAAoJEKD0KQ7Gj3P2mMsH/0RBCt48FehldyXNryh8C0wx I9crBvCbWwsfGQRCnEXwXBurwiKZVTumWtbw4OKj2t5if3yzCoESfyi7tvWwhfDv rtK2J6i7WTtTW8eXQHWqa3/jKdjcAxb/BfFHPBxMypeazf+Lj/6oddVCkAYtK9x4 b/+Oco5yjPMYeQPtasZFRgyLm2fWgTh31cWEYls5Id7GOoiEdhorFn4rQOmNJ1sW nFxBPpMS1URIMg2FE+ZsrOXyUZJnZW5FRIjaMq/QV232bO1CtIFR1QXJzUuKL7dW wTTuz0PwTTWizkTkSt9BwrYrspctbY/OufWsYVDQeRzw5RmPd2de95jhFOYTP1U= =PNdR -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 1 16:43:05 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B507611E817E for ; Fri, 1 Nov 2013 16:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClAjacU2N95I for ; Fri, 1 Nov 2013 16:43:01 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id D798711E817B for ; Fri, 1 Nov 2013 16:43:00 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 367FE2207C; Fri, 1 Nov 2013 19:33:05 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9FC79CA0DF; Fri, 1 Nov 2013 17:46:25 -0400 (EDT) From: Michael Richardson to: roll@ietf.org In-reply-to: <13799.1383338682@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Fri, 01 Nov 2013 16:44:42 -0400." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 17:46:25 -0400 Message-ID: <16160.1383342385@sandelman.ca> Sender: mcr@sandelman.ca Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 23:43:05 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > I would like to ask the WG to speak now if you object to this=20 > solution, specifically with the the text going into mcast-05. Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday). =2D- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdCEsAAoJEKD0KQ7Gj3P2SlYH/0X2ND1dN+LAR0OZ7j0V0yHo 3VslfkrpOaA0nDxGCn5NRB3vTiUT046nXdsxauYYRyjNQKFlSa2hNt/bQF8e0XIq R6lQnErJ14xWN4Ib/XBI47Q4MCBSFpPyUYpe1oBFVxsIF7lKwIPZBSBUy7lSmKwB hJbtNu4l/W5Vk/5omo0qwQw5ViJrrZTBIFExkc3ZBkv3BcOusn7qu/1dLAAGc+W5 g3hhGnItGGYKfueYIIN/xES9ASzJYK/a9NaFgVCe1ML4rFiDjHTiuyvCoLU4fCVQ uQ6a/zhPL36J+pWy4ASrKSfCn28ZRaXnuOyhWOX03TENBKujh42aWqNQpIf3dzA= =6n4E -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 1 16:43:05 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA42511E8181 for ; Fri, 1 Nov 2013 16:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Saj5m66pKKH for ; Fri, 1 Nov 2013 16:43:01 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id D3AD211E8136 for ; Fri, 1 Nov 2013 16:43:00 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 735932207D; Fri, 1 Nov 2013 19:32:58 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A1F8ECA0D9; Fri, 1 Nov 2013 16:44:42 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-reply-to: <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> Comments: In-reply-to "roll issue tracker" message dated "Fri, 11 Oct 2013 20:17:55 -0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 16:44:42 -0400 Message-ID: <13799.1383338682@sandelman.ca> Sender: mcr@sandelman.ca Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2013 23:43:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I would like to ask the WG to speak now if you object to this=20 solution, specifically with the the text going into mcast-05. Ralph wrote: > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > draft-ietf-6man-multicast-scopes-00 or published separately in yet > another "world's shortest RFC". >=20 > Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: >=20 > When used with MPL, Realm-local scope is defined according to the > underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. >=20 > As a further refinement, I suggest text be added to > draft-ietf-roll-trickle-mcast-05 to the effect of: >=20 > "scop 4" can also be used with MPL to cover deployments that use > administratively defined scopes that cover, for example, subnets > based on different underlying network technologies. >=20 > - Ralph =2D- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdBK6AAoJEKD0KQ7Gj3P2/iIH/2LrYADJPoOxp2op//+bbYGq Heyc/YQzPimNLgr0v8UlUjx80969EHgH9zLlJSPrPhnEwJI8AiTOWV79d0F/y7K9 BCxj9InG322wdYAK+xfSHNvKJ6qld83Psg3YldnFdfg+Ia/Bjo2+K/XL1/V8m6XC Ie5mcoQ2cJHEic/47e7koYVvgQezMLB3MfjL6X5NjD2k3VBhY4uax2Xw/3UTB+vb c8z6dtSBYybNWU6hJjbbsoImGO4knBIE24WeFmu7A0225Sfi5nMV1/gKgZvboTQB kF0OpbAm3wMX/lXC1AybAOUCZUz3YJtQofnmyrH3f+44MfNpi7GRLrf5Sk4TXeE= =5llP -----END PGP SIGNATURE----- --=-=-=-- From kerlyn2001@gmail.com Sat Nov 2 08:54:14 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A5D11E8162 for ; Sat, 2 Nov 2013 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTVkpDghFABm for ; Sat, 2 Nov 2013 08:54:13 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8787D11E817C for ; Sat, 2 Nov 2013 08:54:13 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo20so5729639obc.11 for ; Sat, 02 Nov 2013 08:54:13 -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=N4OS9oLH7Wrb1YVfw2GxYisLt/DdR3gIjy/YKrMyNVY=; b=mM5/Wc5cGl5MrvrkXyFjzPjWDwbMEIpu+KyIZW6Cv3sMTeXsV79DxPfmfcmoLAYPjY Im0+IO2sFKDDHYJN8HRyMyNEQui0Vu4QGPXSDz1tUPhEj7V82Kti8ipFfxwL/hHRHrYr lk4jAqMQDfe1kQnYHdwOslPsihMfzLoaj9VK2P+CHcayHD/bqWox7SBsg+skdI5NgpJ+ sw/NEQFc5kvl66q+ZVFP11XhHNrvXCJkAbwssi1WyRVXrh1FwTelkmB93kA/TsVcAwMI pKcSmPBrSvyOQaC/sinAEah+44e0XMZBFUv5uszB+qNSXRYH08I9mszYm2GmU9L2V/iU hGgw== MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr218319oeb.57.1383407652959; Sat, 02 Nov 2013 08:54:12 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Sat, 2 Nov 2013 08:54:12 -0700 (PDT) In-Reply-To: <13799.1383338682@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> Date: Sat, 2 Nov 2013 11:54:12 -0400 X-Google-Sender-Auth: VHe-DcfJEkzsfXI7f0MHFG_tUec Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b5d474abbfaef04ea33b155 Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 15:54:14 -0000 --047d7b5d474abbfaef04ea33b155 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 1, 2013 at 4:44 PM, Michael Richardson wrote: > > I would like to ask the WG to speak now if you object to this > solution, specifically with the the text going into mcast-05. > > Ralph wrote: > > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > > draft-ietf-6man-multicast-scopes-00 or published separately in yet > > another "world's shortest RFC". > > > > Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: > > > > When used with MPL, Realm-local scope is defined according to the > > underlying network technology; for example, [cite the > > IP-over-IEEE802.15.4 definition]. > > > > As a further refinement, I suggest text be added to > > draft-ietf-roll-trickle-mcast-05 to the effect of: > > > > "scop 4" can also be used with MPL to cover deployments that use > > administratively defined scopes that cover, for example, subnets > > based on different underlying network technologies. > > > > - Ralph > > Here's a summary the situation: - draft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast transport protocol. It refers to scop 3 which has up to now been reserved. - draft-ietf-6man-multicast-scopes ("Scopes draft") defines scop 3 and states it must be automatically determined by data link connectivitiy. It recommends the proper place to define how the scope zone boundary is determined is in the "IP-over-Foo" draft for each data link that defines scop 3. - The MPL draft *must* reference the Scopes draft in order to utilize scop 3. It must also agree with the Scopes draft on the issue of whether the scop 3 boundary is automatically determined. This is included in issue #132 and REMAINS OPEN. - Another open question is where to locate the definition of scop 3 for 802.15.4 networks? Going by the recommendation in the Scopes draft, one solution for the latter is to issue a short update to RFC 4944. However, this is not the most expedient solution from the standpoint of finishing the MPL draft. The next best solution in my opinion is to place the 802.15.4 definition of scop 3 into the Scopes draft. Future data links that define scop 3 in their IP-over-Foo RFCs will then only need to reference the Scopes document for the precedent and not the MPL document as well. Since the MPL draft must already reference the Scopes draft anyway, this also solves one open issue for MPL. I personally think it's a bad idea to bury the definition of an automatically determined scope boundary for a particular data link within a transport protocol specification. Regards, -K- -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7b5d474abbfaef04ea33b155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 1, 2013 at 4:44 PM, Michael Richardson <m= cr+ietf@sandelman.ca> wrote:

I would like to ask the WG to speak now if you object to this
solution, specifically with the the text going into mcast-05.

Ralph wrote:
> =A0This text could be added to draft-ietf-roll-trickle-mcast-05, or to=
> =A0draft-ietf-6man-multicast-scopes-00 or published separately in yet<= br> > =A0another "world's shortest RFC".
>
> =A0Second, draft-ietf-roll-trickle-mcast-05 should be changed to read:=
>
> =A0 =A0 When used with MPL, Realm-local scope is defined according to = the
> =A0 =A0 underlying network technology; for example, [cite the
> =A0 =A0 IP-over-IEEE802.15.4 definition].
>
> =A0As a further refinement, I suggest text be added to
> =A0draft-ietf-roll-trickle-mcast-05 to the effect of:
>
> =A0 =A0 "scop 4" can also be used with MPL to cover deployme= nts that use
> =A0 =A0 administratively defined scopes that cover, for example, subne= ts
> =A0 =A0 based on different underlying network technologies.
>
> =A0- Ralph

Here's a summary the situation:
- d= raft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast tr= ansport
=A0 protocol.=A0 It refers to scop 3 which has up to = now been reserved.
- draft-ietf-6man-multicast-scopes ("Scopes draft") de= fines scop 3 and
=A0 states it must be automatically determined by data = link connectivitiy.
=A0 It recommends the proper place to define how the= scope zone boundary
=A0 is determined is in the "IP-over-Foo" draft for each data lin= k that defines
=A0 scop 3.
- The MPL draft *must* referenc= e the Scopes draft in order to utilize
=A0 scop 3.=A0 It must= also agree with the Scopes draft on the issue of whether
=A0 the scop 3 boundary is automatically determined.=A0 This is included in=
=A0 issue #132 and REMAINS OPEN.
- Another open question = is where to locate the definition of scop 3 for
=A0 802.15.4 networks?
Going by the recommendation in the Scopes draft, one solution fo= r the
latter is to issue a short update to RFC 4944.=A0 However, this is= not the
most expedient solution from the standpoint of finishing the MP= L draft.

The next best solution in my opinion is to place the 802.15.= 4 definition of
scop 3 into the Scopes draft.=A0 Future data = links that define scop 3 in their
IP-over-Foo RFCs will then only need t= o reference the Scopes document
for the precedent and not the MPL document as well.=A0 Since the= MPL draft
must already reference the Scopes draft anyway, this also sol= ves one
open issue for MPL.

I personally th= ink it's a bad idea to bury the definition of an automatically
determined scope boundary for a particular data link within a tr= ansport
protocol specification.

Regards, -K-
=


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



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


--047d7b5d474abbfaef04ea33b155-- From kerlyn2001@gmail.com Sat Nov 2 10:14:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9890F21F9B9F for ; Sat, 2 Nov 2013 10:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsiEFohQ1ieG for ; Sat, 2 Nov 2013 10:14:39 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C451311E8219 for ; Sat, 2 Nov 2013 10:14:38 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so5746955obc.30 for ; Sat, 02 Nov 2013 10:14: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:date:message-id:subject :from:to:content-type; bh=3eiKlbuR6IfUEIgv1ZOqdKBIbjLdxNtppbeuIJYMOUs=; b=wqg59VmuirXbsnAZlMlwZBfMMcUQfv+SNfFBoUXShgUJJm+NB/5dPJ/uvu3ViP6ul9 fhEbOYL3Q5obZTvmSZjpThag8aKoc20o+FIozF4+kp5t7mZQg9iHi+sHT7R+WZJvRkze 2I0SZZPGOOT74veNsvDpw2UDTJfTDvO31pCSHMWYLLTIT/iBBUCTKeRE4MyG62eZlX95 qh/3MOnvwwsgo6tCRhYCqkfrFLM61kDTeLEzgAzjblIq9UYOZINIchHNCFGD1DyB0mij 1KO//+J6RD1kG49vuSUmVGlGrCQcFz5t1UZMPpzfNRHgA9MDoceWUQeWT3Vy2mypaQgN oqOw== MIME-Version: 1.0 X-Received: by 10.182.22.18 with SMTP id z18mr6799059obe.42.1383412478191; Sat, 02 Nov 2013 10:14:38 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Sat, 2 Nov 2013 10:14:38 -0700 (PDT) In-Reply-To: <20131101204155.D00DDCA0D8@sandelman.ca> References: <20131010221713.891.32620.idtracker@ietfa.amsl.com> <525BFA61.4040104@gridmerge.com> <20131101204155.D00DDCA0D8@sandelman.ca> Date: Sat, 2 Nov 2013 13:14:38 -0400 X-Google-Sender-Auth: 1YDXNtsZGJYNfEEdEP6v4474oK8 Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11332d16572d3e04ea34d19a Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 17:14:39 -0000 --001a11332d16572d3e04ea34d19a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 1, 2013 at 4:41 PM, Michael Richardson wrote: > : signature: ~/.signature.ietf > MIME-Version: 1.0 > Content-Type: multipart/signed; boundary="=-=-="; > micalg=pgp-sha1; protocol="application/pgp-signature" > Date: Fri, 01 Nov 2013 16:41:55 -0400 > Message-ID: <13680.1383338515@sandelman.ca> > Sender: mcr@sandelman.ca > > --=-=-= > > > Robert Cragie wrote: > > > I would propose adding the language to > > draft-ietf-roll-trickle-mcast. There doesn't seem much point to doing > > another "world's shortest RFC". > > I agree. > > Michael Richardson > -on the road- > > I disagree, and think the text should be placed in draft-ietf-6man-multicast-scopes for reasons stated in the Issue #132 thread. -K- > > > --=-=-= > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAABAgAGBQJSdBITAAoJEKD0KQ7Gj3P2mMsH/0RBCt48FehldyXNryh8C0wx > I9crBvCbWwsfGQRCnEXwXBurwiKZVTumWtbw4OKj2t5if3yzCoESfyi7tvWwhfDv > rtK2J6i7WTtTW8eXQHWqa3/jKdjcAxb/BfFHPBxMypeazf+Lj/6oddVCkAYtK9x4 > b/+Oco5yjPMYeQPtasZFRgyLm2fWgTh31cWEYls5Id7GOoiEdhorFn4rQOmNJ1sW > nFxBPpMS1URIMg2FE+ZsrOXyUZJnZW5FRIjaMq/QV232bO1CtIFR1QXJzUuKL7dW > wTTuz0PwTTWizkTkSt9BwrYrspctbY/OufWsYVDQeRzw5RmPd2de95jhFOYTP1U= > =PNdR > -----END PGP SIGNATURE----- > --=-=-=-- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11332d16572d3e04ea34d19a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 1, 2013 at 4:41 PM, Michael Richardson <m= cr+ietf@sandelman.ca> wrote:
: signature: ~/.signature.ietf
MIME-Version: 1.0
Content-Type: multipart/signed; boundary=3D"=3D-=3D-=3D";
=A0 =A0 =A0 =A0 micalg=3Dpgp-sha1; protocol=3D"application/pgp-signatu= re"
Date: Fri, 01 Nov 2013 16:41:55 -0400
Message-ID: <13680.1383= 338515@sandelman.ca>
Sender: mcr@sandelman.ca

--=3D-=3D-=3D


Robert Cragie <robert.cra= gie@gridmerge.com> wrote:

> I would propose adding the language to
> draft-ietf-roll-trickle-mcast. There doesn't seem much point to do= ing
> another "world's shortest RFC".

I agree.

Michael Richardson
-on the road-

I disagree, and think the text should be placed in dr= aft-ietf-6man-multicast-scopes
for reasons stated in the Issue #132 thre= ad.

-K-


--=3D-=3D-=3D
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJSdBITAAoJEKD0KQ7Gj3P2mMsH/0RBCt48FehldyXNryh8C0wx
I9crBvCbWwsfGQRCnEXwXBurwiKZVTumWtbw4OKj2t5if3yzCoESfyi7tvWwhfDv
rtK2J6i7WTtTW8eXQHWqa3/jKdjcAxb/BfFHPBxMypeazf+Lj/6oddVCkAYtK9x4
b/+Oco5yjPMYeQPtasZFRgyLm2fWgTh31cWEYls5Id7GOoiEdhorFn4rQOmNJ1sW
nFxBPpMS1URIMg2FE+ZsrOXyUZJnZW5FRIjaMq/QV232bO1CtIFR1QXJzUuKL7dW
wTTuz0PwTTWizkTkSt9BwrYrspctbY/OufWsYVDQeRzw5RmPd2de95jhFOYTP1U=3D
=3DPNdR
-----END PGP SIGNATURE-----
--=3D-=3D-=3D--
___________________________________= ____________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--001a11332d16572d3e04ea34d19a-- From yoshihiro.ohba@toshiba.co.jp Sun Nov 3 01:09:27 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A161411E81B8 for ; Sun, 3 Nov 2013 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me6Qz6pfC+5J for ; Sun, 3 Nov 2013 01:09:21 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE7B11E81BA for ; Sun, 3 Nov 2013 01:09:18 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id rA389AOB008974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 17:09:10 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA389AiL009572; Sun, 3 Nov 2013 17:09:10 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 32; Sun, 3 Nov 2013 17:09:10 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA389A28009569; Sun, 3 Nov 2013 17:09:10 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id rA389AWE022878; Sun, 3 Nov 2013 17:09:10 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id TAA22877; Sun, 3 Nov 2013 17:09:10 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id rA38998s017197; Sun, 3 Nov 2013 17:09:09 +0900 (JST) Received: from tgxml345.toshiba.local by toshiba.co.jp id rA3899pb001326; Sun, 3 Nov 2013 17:09:09 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.201]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0158.001; Sun, 3 Nov 2013 17:09:09 +0900 From: To: Thread-Topic: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHO11wkInPumryEmEql3T+C/ZlDXpoTKBeA Date: Sun, 3 Nov 2013 08:09:09 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> In-Reply-To: <13799.1383338682@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.75.175] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 08:09:27 -0000 I prefer describing 802.15.4-specific realm-local scope boundary definition= in another RFC so that both trickle-mcast and multicast-scopes drafts are = fully independent of any link-layer. =20 Regards, Yoshihiro Ohba -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Saturday, November 02, 2013 5:45 AM To: roll@ietf.org Cc: mariainesrobles@gmail.com; johui@cisco.com; rdroms@cisco.com Subject: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-tric= kle-mcast-04 - Clarify scope value of 3 - subnet-local I would like to ask the WG to speak now if you object to this solution, spe= cifically with the the text going into mcast-05. Ralph wrote: > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > draft-ietf-6man-multicast-scopes-00 or published separately in yet =20 > another "world's shortest RFC". >=20 > Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: >=20 > When used with MPL, Realm-local scope is defined according to the > underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. >=20 > As a further refinement, I suggest text be added to > draft-ietf-roll-trickle-mcast-05 to the effect of: >=20 > "scop 4" can also be used with MPL to cover deployments that use > administratively defined scopes that cover, for example, subnets > based on different underlying network technologies. >=20 > - Ralph -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From yusuke.doi@toshiba.co.jp Sun Nov 3 01:54:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBF811E817F for ; Sun, 3 Nov 2013 01:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCYvanAuNPaG for ; Sun, 3 Nov 2013 01:54:11 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0B11E80D9 for ; Sun, 3 Nov 2013 01:54:10 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id rA38s9nt028669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Nov 2013 17:54:09 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA38s9Vk022179 for ; Sun, 3 Nov 2013 17:54:09 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 410 for ; Sun, 3 Nov 2013 17:54:09 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA38s933021920 for ; Sun, 3 Nov 2013 17:54:09 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id rA38s96S002084 for roll@ietf.org; Sun, 3 Nov 2013 17:54:09 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id TAA02081; Sun, 3 Nov 2013 17:54:08 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id rA38s8uD005678 for ; Sun, 3 Nov 2013 17:54:08 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id rA38s8fZ024579; Sun, 3 Nov 2013 17:54:08 +0900 (JST) Received: from [133.199.17.115] (ivpn-2-115.mobile.toshiba.co.jp [133.199.17.115]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 13C2597D6E; Sun, 3 Nov 2013 17:54:08 +0900 (JST) Message-ID: <52760F2D.5000209@toshiba.co.jp> Date: Sun, 03 Nov 2013 17:54:05 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Richardson References: <524E7734.1010604@toshiba.co.jp> <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> <524EA0B9.4090908@toshiba.co.jp> <641a5c59776214374984816097e08d9a@xs4all.nl> <20131101205139.9C39ECA0DA@sandelman.ca> In-Reply-To: <20131101205139.9C39ECA0DA@sandelman.ca> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 08:54:16 -0000 (2013-11-02 5:51), Michael Richardson wrote: > peter van der Stok wrote: >> Hi Yusuke, >> >> For the moment the parameters are general for al interfaces, seeds and >> messages. >> In the case of changing per message, the parameter sets need to be >> attached to each message entry. (for me that is a large change) > > I don't think he wants to do it per message > He wants to use some out-of-scope management interface to tweak the values > as the network grows, changes, or as performance data is gathered. > > The question could be restated as: > What is the affect on MPL stability is nodes differ on Imin, etc. by up > to > 10% while data transmission is active. Michael, thank you for question clarification. Yes, we expect changing large-scale mesh network with low traffic (somewhat around 1,000 node or even more). I think carefully-selected 'default parameter set' should work good enough for 95% of deployment. However we need some 'knob' to control MPL parameters for the last 5% (or even more). The parameter update shall be moderate and 10% is a good threashold. (c.f. http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03 is intended to make this happen) I personally don't expect parameter update should happen frequently (say, once a day or so). I'd like to analyze deeper on this topic soon, but no clear result for this IETF meeting yet. (also depends on the implementations -- if the code does not expect parameters update, I also have interestingly read draft-roux-roll-mpl-eval-00. I'm trying to follow their method (by my own code. I need to build it up from scratch). If there are good codebase to start with, I really appreciate it. Thanks, Yusuke From mcr@sandelman.ca Sun Nov 3 10:30:21 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C311E82CD for ; Sun, 3 Nov 2013 10:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHeBLtVgw27T for ; Sun, 3 Nov 2013 10:30:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1811E8222 for ; Sun, 3 Nov 2013 10:30:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C7AC2016D; Sun, 3 Nov 2013 14:41:50 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A756C63B88; Sun, 3 Nov 2013 13:30:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 978A763AED; Sun, 3 Nov 2013 13:30:16 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> 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 Cc: Routing Over Low power and Lossy networks , mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:30:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > I prefer describing 802.15.4-specific realm-local scope boundary > definition in another RFC so that both trickle-mcast and > multicast-scopes drafts are fully independent of any link-layer. Are you willing to write this document? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnaWNYqHRg3pndX9AQK05QP+KONv0wnQYVcpuBPBih8mwOqqltHrdCHt dKxFu9Mbja31fuEJ5PHEZfiwARunbEL8yB7yIW9tdWiWxIJ9RuGSXT/aCTSAVs83 uktgcw1C4cSaYfki4xc18ej+6CKf4v05vLpkGMtubA2R9Gf+CBHB2YMLdm5pTXX7 aSIrQAch/hY= =Lchs -----END PGP SIGNATURE----- --=-=-=-- From kerlyn2001@gmail.com Sun Nov 3 14:30:44 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E290221E80B7 for ; Sun, 3 Nov 2013 14:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BidZ3P2GlZi for ; Sun, 3 Nov 2013 14:30:44 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD121E80ED for ; Sun, 3 Nov 2013 14:30:41 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wm4so6548477obc.9 for ; Sun, 03 Nov 2013 14:30:41 -0800 (PST) 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=yliddDBkTAtVctTgUE2B+mvPcE1yrqy0R3Ffg54//Ck=; b=Dzcjmigt/v4hNgaAdbobm85JNFp/7N/SsHkVql/YhVnFvnWcvfNnRdZDHE9MJZUrsN OK776NEeqiTBWHG1q76PXtwPjbTJSudnv/sbcuu2PkSWBmaUUSVT/OuKu/hfZliBD6MI N+GYlVsjttSOEiU3rdRM1Mo0PClzMcHzoaqy/tTvyC69j9F18hI+qtqgT7VVokFo/tWV ZlyWvPYLkVG4woRqWH7WWGIeGwhEnN9FBCfkn01PGR39vMdb0OwIog/hM05rFPS56ihw dlmSukeaGBYtF5A4MKSBmnIBNbKfH4eJ6ebZy7KV+KryNlOzwEwQXgSk0QAGhWdlwgvi Rorw== MIME-Version: 1.0 X-Received: by 10.60.142.8 with SMTP id rs8mr3220218oeb.34.1383517841216; Sun, 03 Nov 2013 14:30:41 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Sun, 3 Nov 2013 14:30:41 -0800 (PST) In-Reply-To: <4887.1383503416@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> <4887.1383503416@sandelman.ca> Date: Sun, 3 Nov 2013 17:30:41 -0500 X-Google-Sender-Auth: HRnUNSNpw8NTGZYLvmehJtod6NU Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b33cd74775ce804ea4d5953 Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:30:45 -0000 --047d7b33cd74775ce804ea4d5953 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 3, 2013 at 1:30 PM, Michael Richardson wrote: > > wrote: > > I prefer describing 802.15.4-specific realm-local scope boundary > > definition in another RFC so that both trickle-mcast and > > multicast-scopes drafts are fully independent of any link-layer. > > Are you willing to write this document? > > Let's scope the effort this week. Ralph predicts it will be the World's shortest RFC; maybe we can get it right the first time. -K- > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7b33cd74775ce804ea4d5953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 3, 2013 at 1:30 PM, Michael Richardson <m= cr+ietf@sandelman.ca> wrote:

<yoshihiro.ohba@toshiba.= co.jp> wrote:
=A0 =A0 > I prefer describing 802.15.4-specific realm-local scope bounda= ry
=A0 =A0 > definition in another RFC so that both trickle-mcast and
=A0 =A0 > multicast-scopes drafts are fully independent of any link-laye= r.

Are you willing to write this document?

L= et's scope the effort this week.=A0 Ralph predicts it will be the World= 's
shortest RFC; maybe we can get it right the first time= .

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



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


--047d7b33cd74775ce804ea4d5953-- From rdroms@cisco.com Sun Nov 3 15:16:46 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6100421F9BC2 for ; Sun, 3 Nov 2013 15:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTSNDiKhdCOt for ; Sun, 3 Nov 2013 15:16:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D699821F9B07 for ; Sun, 3 Nov 2013 15:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3192; q=dns/txt; s=iport; t=1383520594; x=1384730194; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tmjVDitb97MCN43bc98obI7xdoo6nY8EYdcY1mwLcL0=; b=QTvlrHEkueo71zZvJg8LItT5coiLnuRtZ4kWQgwQAYQeH2MwBD0UFm7h qddMPNWgQkZuhqRJLRM567eWs43tKXhSWd1d8dBUlljnAT/1J6AArX2IM EnGt1acr6d0lznepHYecBj04EfDRQTObDi4potU8D77Ta4JJMvvHhBjJ3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAM/YdlKtJV2Z/2dsb2JhbABYgkNEwFqBGhZ0giYBAQR5EAIBCAQ3BAcyFBECBA4FiAG9XI9YB4MggQ4DmAqSCYFogT4 X-IronPort-AV: E=Sophos;i="4.93,628,1378857600"; d="scan'208,217";a="280172321" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2013 23:16:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA3NGXWv029720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 23:16:33 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.227]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 17:16:32 -0600 From: "Ralph Droms (rdroms)" To: Michael Richardson Thread-Topic: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHO2MLB6q/7EA0AAk2/5DY+O9XmRZoUI/Ag Date: Sun, 3 Nov 2013 23:16:31 +0000 Message-ID: References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local>, <4887.1383503416@sandelman.ca> In-Reply-To: <4887.1383503416@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B87A1A82632C4B94A0535C4D6A613964ciscocom_" MIME-Version: 1.0 Cc: Routing Over Low power and Lossy networks , "Jonathan Hui \(johui\)" , "mariainesrobles@gmail.com" Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:16:46 -0000 --_000_B87A1A82632C4B94A0535C4D6A613964ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Nov 3, 2013, at 10:30 AM, "Michael Richardson" > wrote: > wrote: I prefer describing 802.15.4-specific realm-local scope boundary definition in another RFC so that both trickle-mcast and multicast-scopes drafts are fully independent of any link-layer. Are you willing to write this document? In my opinion, the roll WG gets to answer the question "should realm-specif= ic scope for 802.15.4 be defined in draft-ietf-roll-trickle-mcast?" If the consensus is no (which would be my answer), then, in my opinion, it'= s up to 6nan to decide between putting the definition in the multicast scop= es doc or a separate RFC. - Ralph -- Michael Richardson >, S= andelman Software Works --_000_B87A1A82632C4B94A0535C4D6A613964ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


On Nov 3, 2013, at 10:30 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:<= br>

<yoshihiro.ohba@to= shiba.co.jp> wrote:
I prefer describing 802.15.4-specific realm= -local scope boundary
definition in another RFC so that both tric= kle-mcast and
multicast-scopes drafts are fully independe= nt of any link-layer.

Are you willing to write this document?

In my opinion, the roll WG gets to answer the question "should realm-s= pecific scope for 802.15.4 be defined in draft-ietf-roll-trickle-mcast?"

If the conse= nsus is no (which would be my answer), then, in my opinion, it's up to 6nan= to decide between putting the definition in the multicast scopes doc or a = separate RFC.

- Ralph


--
Michael Richardson <m= cr+IETF@sandelman.ca>, Sandelman Software Works


--_000_B87A1A82632C4B94A0535C4D6A613964ciscocom_-- From yoshihiro.ohba@toshiba.co.jp Sun Nov 3 16:32:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07421E8118 for ; Sun, 3 Nov 2013 16:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=-1.326, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tc9o3FYqVxy for ; Sun, 3 Nov 2013 16:32:06 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCD621E80C3 for ; Sun, 3 Nov 2013 16:32:03 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id rA40VuQs012149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 09:31:56 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA40VuVf012089; Mon, 4 Nov 2013 09:31:56 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 3; Mon, 4 Nov 2013 09:31:56 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id rA40VuWR012083; Mon, 4 Nov 2013 09:31:56 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id rA40VuLW014129; Mon, 4 Nov 2013 09:31:56 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA14128; Mon, 4 Nov 2013 09:31:56 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id rA40VtAm006631; Mon, 4 Nov 2013 09:31:55 +0900 (JST) Received: from tgxml345.toshiba.local by toshiba.co.jp id rA40VtMF000616; Mon, 4 Nov 2013 09:31:55 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.201]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 09:31:55 +0900 From: To: Thread-Topic: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHO2MLGiI9BQZ2vo0mMY9rjgtpzc5oUN0ZQ Date: Mon, 4 Nov 2013 00:31:54 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B188864E5@tgxml338.toshiba.local> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> <4887.1383503416@sandelman.ca> In-Reply-To: <4887.1383503416@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.18.241] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org, mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:32:14 -0000 If we choose to write another RFC, yes I can contribute to it. Regards, Yoshihiro Ohba -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Richa= rdson Sent: Monday, November 04, 2013 3:30 AM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: Routing Over Low power and Lossy networks; mariainesrobles@gmail.com; j= ohui@cisco.com; rdroms@cisco.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-= trickle-mcast-04 - Clarify scope value of 3 - subnet-local wrote: > I prefer describing 802.15.4-specific realm-local scope boundary > definition in another RFC so that both trickle-mcast and > multicast-scopes drafts are fully independent of any link-layer. Are you willing to write this document? --=20 Michael Richardson , Sandelman Software Works=20 From Daniel.Popa@itron.com Mon Nov 4 02:10:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87521E80CE for ; Mon, 4 Nov 2013 02:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTrpGrfMg2Zh for ; Mon, 4 Nov 2013 02:10:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id A7ACC11E82F7 for ; Mon, 4 Nov 2013 02:03:25 -0800 (PST) Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB348.namprd04.prod.outlook.com (10.141.52.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 4 Nov 2013 10:03:22 +0000 Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.47]) with mapi id 15.00.0785.001; Mon, 4 Nov 2013 10:03:21 +0000 From: "Popa, Daniel" To: Routing Over Low power and Lossy networks , "mcr+ietf@sandelman.ca" Thread-Topic: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHO2PWJkIKe8VRKuUWgXyUo4iDNKZoU1iLQ Date: Mon, 4 Nov 2013 10:03:20 +0000 Message-ID: <52e7febd52b040ecbf0d560190c4ed91@CO1PR04MB346.namprd04.prod.outlook.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local> <4887.1383503416@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B188864E5@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B188864E5@tgxml338.toshiba.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(13464003)(24454002)(55784002)(53754006)(377454003)(77096001)(33646001)(83072001)(15975445006)(85306002)(81816001)(81686001)(80976001)(56816003)(19580395003)(2656002)(85806002)(76796001)(83322001)(19580405001)(87266001)(76786001)(76576001)(81542001)(63696002)(74366001)(81342001)(69226001)(56776001)(54316002)(50986001)(74706001)(31966008)(76482001)(47976001)(74876001)(47736001)(79102001)(74662001)(74502001)(66066001)(77982001)(47446002)(74316001)(4396001)(49866001)(59766001)(51856001)(54356001)(53806001)(46102001)(65816001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB348; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:3; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "mariainesrobles@gmail.com" , Cisco-Johnathan Hui , "rdroms@cisco.com" Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:10:49 -0000 SGVsbG8gYWxsLCANCg0KSSBzdXBwb3J0IHRoZSBpZGVhIG9mIGhhdmluZyB0aGUgZGVmaW5pdGlv biBvZiBtdWx0aWNhc3Qgc2NvcGUgYm91bmRhcnkgaW4gYW5vdGhlciBSRkMgc28gdGhhdCB0cmlj a2xlLW1jYXN0IGFuZCBtdWx0aWNhc3Qtc2NvcGVzIGRyYWZ0cyBzcGVjaWZ5IHN1Y2ggSVAgZmVh dHVyZXMgaW5kZXBlbmRlbnQgb2YgdGhlIGxpbmstbGF5ZXIuIA0KDQpBbmQgSSBhbSB3aWxsaW5n IHRvICBjb250cmlidXRlIGFuZCBoZWxwIHdyaXRpbmcgc3VjaCBSRkMuIA0KDQpJIHdpbGwgdW5m b3J0dW5hdGVseSBub3QgYmUgYWJsZSB0byBhdHRlbmQgdGhpcyBJRVRGIG1lZXRpbmcsIGJ1dCBJ IHdpbGwgYmUgYXZhaWxhYmxlIHZpYSBlbWFpbC4NCg0KUmVnYXJkcywNCkRhbmllbA0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSB5b3NoaWhpcm8ub2hiYUB0 b3NoaWJhLmNvLmpwDQpFbnZvecOpwqA6IGx1bmRpIDQgbm92ZW1icmUgMjAxMyAwMTozMg0Kw4DC oDogbWNyK2lldGZAc2FuZGVsbWFuLmNhDQpDY8KgOiByb2xsQGlldGYub3JnOyBtYXJpYWluZXNy b2JsZXNAZ21haWwuY29tOyBDaXNjby1Kb2huYXRoYW4gSHVpOyByZHJvbXNAY2lzY28uY29tDQpP YmpldMKgOiBSZTogW1JvbGxdIENvbnNlbnN1cyBDYWxsIC0tIHJlc29sdXRpb24gZm9yICMxMzI6 IGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTA0IC0gQ2xhcmlmeSBzY29wZSB2YWx1ZSBv ZiAzIC0gc3VibmV0LWxvY2FsDQoNCklmIHdlIGNob29zZSB0byB3cml0ZSBhbm90aGVyIFJGQywg eWVzIEkgY2FuIGNvbnRyaWJ1dGUgdG8gaXQuDQoNClJlZ2FyZHMsDQpZb3NoaWhpcm8gT2hiYQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWNyQHNhbmRlbG1hbi5jYSBbbWFp bHRvOm1jckBzYW5kZWxtYW4uY2FdIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NClNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgMzozMCBBTQ0KVG86IG9oYmEgeW9zaGloaXJv KOWkp+WgtCDnvqnmtIsg4peL77yy77yk77yj4pah77yu77yz77ysKQ0KQ2M6IFJvdXRpbmcgT3Zl ciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzOyBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29t OyBqb2h1aUBjaXNjby5jb207IHJkcm9tc0BjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbUm9sbF0g Q29uc2Vuc3VzIENhbGwgLS0gcmVzb2x1dGlvbiBmb3IgIzEzMjogZHJhZnQtaWV0Zi1yb2xsLXRy aWNrbGUtbWNhc3QtMDQgLSBDbGFyaWZ5IHNjb3BlIHZhbHVlIG9mIDMgLSBzdWJuZXQtbG9jYWwN Cg0KDQo8eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4gd3JvdGU6DQogICAgPiBJIHByZWZl ciBkZXNjcmliaW5nIDgwMi4xNS40LXNwZWNpZmljIHJlYWxtLWxvY2FsIHNjb3BlIGJvdW5kYXJ5 DQogICAgPiBkZWZpbml0aW9uIGluIGFub3RoZXIgUkZDIHNvIHRoYXQgYm90aCB0cmlja2xlLW1j YXN0IGFuZA0KICAgID4gbXVsdGljYXN0LXNjb3BlcyBkcmFmdHMgYXJlIGZ1bGx5IGluZGVwZW5k ZW50IG9mIGFueSBsaW5rLWxheWVyLg0KDQpBcmUgeW91IHdpbGxpbmcgdG8gd3JpdGUgdGhpcyBk b2N1bWVudD8NCg0KLS0gDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyANCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From sob@sobco.com Thu Oct 3 04:57:36 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBDC21F9D2C; Thu, 3 Oct 2013 04:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5egTvrfWq0TX; Thu, 3 Oct 2013 04:57:11 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 19EA621F856A; Thu, 3 Oct 2013 04:49:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id C047F309FC2; Thu, 3 Oct 2013 07:49:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHy2v5bErEy0; Thu, 3 Oct 2013 07:49:50 -0400 (EDT) Received: from dhcp3.sobco.com (unknown [136.248.127.173]) by sobco.sobco.com (Postfix) with ESMTPSA id 44F3C309F36; Thu, 3 Oct 2013 07:49:50 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Scott O Bradner In-Reply-To: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: , Date: Thu, 03 Oct 2013 11:57:36 -0000 X-Original-Date: Thu, 3 Oct 2013 07:49:49 -0400 X-List-Received-Date: Thu, 03 Oct 2013 11:57:36 -0000 On Oct 3, 2013, at 6:34 AM, The IESG wrote: >=20 > The IESG has received a request from the Routing Over Low power and = Lossy > networks WG (roll) to consider the following document: > - 'Terms used in Ruting for Low power And Lossy Networks' > as Informational RFC "Ruting" - "R=FCting is a municipality in the Nordwestmecklenburg = district, in Mecklenburg-Vorpommern, Germany" the first sentence in the abstract says "routing" - maybe the title is = in need of Vana White? Scott From dave@cridland.net Thu Oct 3 05:06:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A521F9D87 for ; Thu, 3 Oct 2013 05:06:01 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWtuEeS9aihG for ; Thu, 3 Oct 2013 05:05:53 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8129421F9635 for ; Thu, 3 Oct 2013 05:00:50 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so1848246lab.11 for ; Thu, 03 Oct 2013 05:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4YABXTf+Jw3T8xpuBo67zEd7xBdtgvGLh1uHHMEfbz4=; b=V8OWk9ZqB3kwJZuIXtXZLdQqpGR9L4V5OjiJ060Rr0sSbHlUyFxjsB9jSXjjlYPqSH Q70m/wyhGQbZ0zrsHh4+X+vxWbPvUDV7Oy+F6gvwnYdQnHQtcvs5A5IIcpwz1Y3A7DlF liBBgEs8QAHGLgOjELGDaLZ03Pa/jXjtAjDcc= 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=4YABXTf+Jw3T8xpuBo67zEd7xBdtgvGLh1uHHMEfbz4=; b=ePwMLnoey0tPJhqntIFIx07vA7wSi7lgkeNoRQf75m85c/nhcm7qvRipeM9cPAA7tq liW7ITrbYRp+MsRjoSMQHbRVxeUt4DDpWPUhjYgxwc+v1GI8fMcC2OZUJ5T3GyADQ5pv yKHZ89iBeyfVAyeCVRgCdAdrsWstflAqrS5ZYehnuu7zO7OV96LNT92ApDnlV63oky22 4KR4B/g5e+q9P52MdHhz3xS1bGBsNAI+P+Fz0BNlncQ06Gx4/qTCZEFybdtynoNTK/F5 xMZBiLIIBHzHxXyPDR1jNEKyKvZfrvQLtbfWK+TBAXIfevNsrR27r4v15uCSKkS1sNnJ FVjg== X-Gm-Message-State: ALoCoQnq+85ERkE45xXXuTYAn7flaglRTAq1xT95+fotFyDfqK5Hp5qh56NC6BoW+uQwFsUQ55BG MIME-Version: 1.0 X-Received: by 10.152.30.74 with SMTP id q10mr6671707lah.27.1380801648254; Thu, 03 Oct 2013 05:00:48 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Thu, 3 Oct 2013 05:00:48 -0700 (PDT) In-Reply-To: References: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> Message-ID: From: Dave Cridland To: Scott O Bradner Content-Type: multipart/alternative; boundary=089e0158c410bff78704e7d4ef15 X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: roll@ietf.org, "ietf@ietf.org Discussion" Subject: Re: [Roll] Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: , Date: Thu, 03 Oct 2013 12:06:01 -0000 X-Original-Date: Thu, 3 Oct 2013 13:00:48 +0100 X-List-Received-Date: Thu, 03 Oct 2013 12:06:01 -0000 --089e0158c410bff78704e7d4ef15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner wrote: > > On Oct 3, 2013, at 6:34 AM, The IESG wrote: > > > > > The IESG has received a request from the Routing Over Low power and Los= sy > > networks WG (roll) to consider the following document: > > - 'Terms used in Ruting for Low power And Lossy Networks' > > as Informational RFC > > "Ruting" - "R=FCting is a municipality in the Nordwestmecklenburg distric= t, > in Mecklenburg-Vorpommern, Germany" > > the first sentence in the abstract says "routing" - maybe the title is in > need of Vana White? > > I'd assumed that they'd misspelt "rutting", and was quite disappointed in the document as a result. Dave. --089e0158c410bff78704e7d4ef15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner <sob@sobco.c= om> wrote:

On Oct 3, 2013, at 6:34 AM, The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the Routing Over Low power and Lo= ssy
> networks WG (roll) to consider the following document:
> - 'Terms used in Ruting for Low power And Lossy Networks'
> =A0<draft-ietf-roll-terminology-13.txt> as Informational RFC

"Ruting" - "R=FCting is a municipality in the Nordwestmeckle= nburg district, in Mecklenburg-Vorpommern, Germany"

the first sentence in the abstract says "routing" - maybe the tit= le is in need of Vana White?


I'd assumed that they'd misspelt "rutti= ng", and was quite disappointed in the document as a result.

Dave.
--089e0158c410bff78704e7d4ef15-- From sob@sobco.com Thu Oct 3 05:15:20 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A29821F9B86; Thu, 3 Oct 2013 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez8pOd6T366D; Thu, 3 Oct 2013 05:15:06 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id B205811E80EA; Thu, 3 Oct 2013 05:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 1344830A0BC; Thu, 3 Oct 2013 08:10:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03qMdpeTsacR; Thu, 3 Oct 2013 08:10:08 -0400 (EDT) Received: from dhcp3.sobco.com (unknown [136.248.127.173]) by sobco.sobco.com (Postfix) with ESMTPSA id 2D46C30A0AE; Thu, 3 Oct 2013 08:10:08 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Scott O Bradner In-Reply-To: Content-Transfer-Encoding: quoted-printable Message-Id: <033EBCD9-8D72-4264-B260-22F4207C9F0D@sobco.com> References: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> To: Dave Cridland X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: roll@ietf.org, "ietf@ietf.org Discussion" Subject: Re: [Roll] Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: , Date: Thu, 03 Oct 2013 12:15:20 -0000 X-Original-Date: Thu, 3 Oct 2013 08:10:07 -0400 X-List-Received-Date: Thu, 03 Oct 2013 12:15:20 -0000 that is what I thought at first which caused me to quickly take a look since the topic seemed to be a bit out of scope, even for the quite = broad=20 IETF official scope (though I'm not sure what SDO would be a an = appropriate=20 venue for standardization in this field) Scott On Oct 3, 2013, at 8:00 AM, Dave Cridland wrote: > On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner = wrote: >=20 > On Oct 3, 2013, at 6:34 AM, The IESG wrote: >=20 > > > > The IESG has received a request from the Routing Over Low power and = Lossy > > networks WG (roll) to consider the following document: > > - 'Terms used in Ruting for Low power And Lossy Networks' > > as Informational RFC >=20 > "Ruting" - "R=FCting is a municipality in the Nordwestmecklenburg = district, in Mecklenburg-Vorpommern, Germany" >=20 > the first sentence in the abstract says "routing" - maybe the title is = in need of Vana White? >=20 >=20 > I'd assumed that they'd misspelt "rutting", and was quite disappointed = in the document as a result. >=20 > Dave. From jinmei.tatuya@gmail.com Mon Oct 21 12:03:00 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09211E86C2; Mon, 21 Oct 2013 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SNh1Aemf9WA; Mon, 21 Oct 2013 12:02:58 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7011E865C; Mon, 21 Oct 2013 12:00:10 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so7184706wgg.32 for ; Mon, 21 Oct 2013 12:00:08 -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=rS4fzCbJ4FWr9XlBmJlk+cjXUNHZnVlmo58XAAHEy2U=; b=ug4Agz6M12eN2WCB+DaUlCLqmoofQyGsH9lAhv5n/YGefak81q1YaSOX80EdMNUvaG FTWh4ZRmaqZFfMH9tm4vpyfJgnIjaToowGFR5v9mMWZob7MeQe6b3AW4Tr3UmZnKlIi0 mDjvZjMdsRSlfRLD2+6GND68blUuSMej7A5UQBCYSeMY/sxJ96rLdOnOhKc+9WPDUVq3 fcBEAJrXuSmaHf5XwwTRVQC2/0VAXXq6rzaRtHRDi2T8FWDbecO0LYXIRFJx/njs98Qz q52Q8u78PsixQXBz8RFdaDCbhHDY6oxlBnvOca7AZS0dbiVjMi+80iJMHUzEDlT7LN2l b7kg== MIME-Version: 1.0 X-Received: by 10.180.86.230 with SMTP id s6mr11149204wiz.64.1382382008857; Mon, 21 Oct 2013 12:00:08 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Mon, 21 Oct 2013 12:00:08 -0700 (PDT) In-Reply-To: <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> Date: Mon, 21 Oct 2013 12:00:08 -0700 X-Google-Sender-Auth: 6BZ1xqZg8blT5QbcDoVKDbjh0QU Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:03:00 -0000 At Thu, 17 Oct 2013 09:10:50 -0700, Ralph Droms wrote: > Noting this conflict, I propose adding a bit of text to > draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency > with RFC 4291: I think making these consistent is a good idea. > OLD: > > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. > > NEW: > > o Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. I'm okay with the proposed text, but on a closer look I've noticed a couple of subtle points you may want to consider: - I see a slight difference between the OLD (RFC 4007) and NEW (RFC 4291) even after fixing the obvious inconsistency, in that the NEW version does not necessarily say how the scopes larger than admin-local scope is configured; technically it only states interface-local and link-local (and "Realm-Local" if assigned) would not be automatically configured. In fact, the global scope shouldn't be "administratively" configured, which is crystal clear from the OLD version, but not necessarily in the NEW version. - should we worry about possible future updates to the addressing architecture and scope architecture documents? If we keep these documents separately and have a copy of the text in both, we may need to update both copies when we need to make a change on this point as more "currently reserved" scopes are assigned. These are probably too minor and maybe we can simply ignore the subtlety. If that's our consensus I'm okay with that. But if we want to address these points, maybe: OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. NEW: o The boundaries of zones of an interface-local, link-local, or global scope automatically derived from physical connectivity. For zones of other types of scopes, the IPv6 addressing architecture specification defines how their boundaries must be determined, whether automatically derived or administratively configured. -- JINMEI, Tatuya From jinmei.tatuya@gmail.com Wed Oct 23 14:21:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6301A11E8241; Wed, 23 Oct 2013 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQL4SoUvRKmo; Wed, 23 Oct 2013 14:21:18 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9312711E821A; Wed, 23 Oct 2013 14:21:17 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id c11so1459355wgh.14 for ; Wed, 23 Oct 2013 14:21:16 -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=QkZvQBlQAyOoTKz/4ac6WYSVeH/tIOr56sH8bz9Wpf8=; b=f4TsX/CVAuMqRVMSGDSp2YJ68hbkzCtUqbCNAmw7aUnPIaZtHMJvqUkmpwdL5RLAcI aj0iaOFQyVtOPBdk6NUvWrUJuD2MJNKTbyP4i4QeM6Toc++VV2eIHmO2Dfy8jmzn+6Vq mJkelwVnwtUtFLBPE1WiQDQnPDy21td5vQbH3MuJ2iW5FXCC0njL/sYFD3LEBQGpxu9m KO9HII5U376vNPdc6uSCQJv/HGzBZRW6ch8dayOStskc4kr3WhkgwOssQBN3hCgKKPNy Jup63nPwVbs0q2/88gm+f39ATb6ZW+aGggPLqabL2Wl6x2enRmRoheoGaXGBeP0tT2GL L00A== MIME-Version: 1.0 X-Received: by 10.194.175.66 with SMTP id by2mr3319478wjc.59.1382563276700; Wed, 23 Oct 2013 14:21:16 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 23 Oct 2013 14:21:16 -0700 (PDT) In-Reply-To: <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> Date: Wed, 23 Oct 2013 14:21:16 -0700 X-Google-Sender-Auth: 9r766Kso1DOa8mTJr0OgNTJrxjI Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 21:21:18 -0000 At Wed, 23 Oct 2013 15:56:46 -0400, Ralph Droms wrote: > Perhaps we want to go a step farther and take the zone boundary text > out of RFC 4007 altogether? Basically works for me. > OLD: > > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators > > NEW: > > o The boundaries of zones of a scope are defined by the IPv6 > addressing architecture. With a reference (it's currently RFC 4291)? I'd also note that not all points described in the RFC 4007 text are described in RFC 4291 (at least not very clearly). So, not just remove the text from RFC 4007, I'd like to unify it in the address architecture, e.g. update the following part of RFC 4291: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. as follows: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. For all non-reserved scopes except the global scope, the zone boundaries must also be administratively configured. -- JINMEI, Tatuya From jinmei.tatuya@gmail.com Thu Oct 24 09:33:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3811E8349; Thu, 24 Oct 2013 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQxKRHf65PRT; Thu, 24 Oct 2013 09:33:41 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AF34011E8354; Thu, 24 Oct 2013 09:33:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ez12so9296169wid.11 for ; Thu, 24 Oct 2013 09:33:26 -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=/Xsure6EPP6ZaggnBUeSTccXjIxk5/V7EsZX2JzgeNo=; b=uwaxIZ9LrKyPp720wcXBMBj5Z32gG0QNbLB4lEcotZBB/z0c148rFgKr07JoU1H6n6 VUKuBv7pR00KuVXB4ysvTrkR5b+i0TuCxOS9CXNwuSuPGlejTojZS/AZOeJ1C6gFv4UQ IjWk6I3W+hxDe2enPAitdlJ2S1YGe6awrGKFlQzEbwV3QsXlLRXFbKk6zaj21szyLWIQ inaCen39jSfPri8a8iIuOHLN7yguvEWS8qBf3UuTyM3cN7nAUgkYgWy+apCpB6Kr59/N 0ccVNRhCxDziIPvbdA+cozsnK5zK7FLQ8+vAoBj16uUboO73lLknsvJJvt5K4X6MvbvT RVww== MIME-Version: 1.0 X-Received: by 10.180.37.134 with SMTP id y6mr2980128wij.48.1382632406615; Thu, 24 Oct 2013 09:33:26 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 24 Oct 2013 09:33:26 -0700 (PDT) In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> Date: Thu, 24 Oct 2013 09:33:26 -0700 X-Google-Sender-Auth: uLHtGhqykNJixU7pWi_AetJMmPY Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kerry Lynn Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 16:33:41 -0000 At Wed, 23 Oct 2013 17:38:07 -0400, Kerry Lynn wrote: > > as follows: > > > > Admin-Local scope is the smallest scope that must be > > administratively configured, i.e., not automatically derived > > from physical connectivity or other, non-multicast-related > > configuration. For all non-reserved scopes except the global > > scope, the zone boundaries must also be administratively > > configured. > > > > I think this statement is self-contradictory. When automatic > configuration is > discussed, it is in relation to zone boundaries. Here's an attempt to I'm not sure how it's self contradictory, but there was one clear error: I meant "For all non-reserved scopes larger than admin-local scope except the global scope". But in any case, > explain > this without negations: > > Interface-Local, Link-Local, and Realm-Local scope boundaries are > automatically > derived from physical connectivity or other, non-multicast related > configuration. > Global scope has no boundary. The boundaries of all other non-reserved > scopes > are administratively configured. This one works for me, and, I actually don't have a strong opinion of the wording or where to state it. -- JINMEI, Tatuya From dthaler@microsoft.com Fri Oct 25 13:39:07 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81DB11E8208; Fri, 25 Oct 2013 13:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.63 X-Spam-Level: X-Spam-Status: No, score=-103.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdEMBgvehcYt; Fri, 25 Oct 2013 13:39:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3411711E8190; Fri, 25 Oct 2013 13:38:46 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 25 Oct 2013 20:38:44 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.31]) with mapi id 15.00.0800.005; Fri, 25 Oct 2013 20:38:44 +0000 From: Dave Thaler To: "Ralph Droms (rdroms)" , "6man@ietf.org" <6man@ietf.org> Thread-Topic: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) Thread-Index: AQHO0b/UxrZjYDMCZkmp4wiEoc30O5oF4HVA Date: Fri, 25 Oct 2013 20:38:43 +0000 Message-ID: <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(377454003)(13464003)(189002)(199002)(51704005)(24454002)(31966008)(74502001)(69226001)(51856001)(59766001)(46102001)(77982001)(74316001)(76482001)(54316002)(56776001)(47976001)(79102001)(74662001)(47446002)(54356001)(4396001)(63696002)(33646001)(76576001)(76786001)(77096001)(76796001)(56816003)(49866001)(53806001)(47736001)(50986001)(81542001)(81342001)(65816001)(80022001)(15975445006)(74876001)(19580395003)(19580405001)(83322001)(81816001)(74706001)(81686001)(80976001)(74366001)(85306002)(83072001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 20:39:07 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ralph Droms (rdroms) > Sent: Friday, October 25, 2013 1:21 PM > To: 6man@ietf.org > Cc: Routing Over Low power and Lossy networks > Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: > [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope valu= e of 3 - > subnet-local) >=20 > I think I read consensus from the WG to make the following changes to dra= ft- > ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": >=20 > *** Add as a new last paragraph in section 2: >=20 > The following change is applied to section 2.7 of RFC 4291: >=20 > OLD: >=20 > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. >=20 > NEW: >=20 > Interface-Local, Link-Local, and Realm-Local scope boundaries > are automatically derived from physical connectivity or > other, non-multicast related configuration. Global scope has > no boundary. The boundaries of all other non-reserved scopes > are administratively configured. I disagree with the last sentence above. Specifically "non-reserved" should be removed. That is, we should not start precluding admin configuration of reserved scopes, given we didn't before. They just didn't have defined names or uses, but they could have been used within private environments. -Dave >=20 > *** Add section 3 (and renumber current section 3-5): >=20 > 3. Updates to RFC 4007, section 5 >=20 > Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > way in which multicast scope 3 is configured. To resolve that disagre= ement, > change the last bullet in the list in section 5 of RFC 4007 as follows= : >=20 > OLD: >=20 > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. >=20 > NEW: >=20 > o The boundaries of zones of a scope are defined by the IPv6 > addressing architecture [RFC4291]. >=20 > I haven't seen any discussion of changing Realm-Local to Multilink-Local > beyond Kerry's initial suggestion and Robert's support of the change. >=20 > - Ralph >=20 > On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms > wrote: >=20 > > Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict > regarding the way in which multicast scope 3 is defined: > > > > RFC 4007, section 5: > > > > o The boundaries of zones of a scope other than interface-local, > > link-local, and global must be defined and configured by network > > administrators. > > > > RFC 4291, section 2.7: > > > > Admin-Local scope is the smallest scope that must be > > administratively configured, i.e., not automatically derived > > from physical connectivity or other, non-multicast-related > > configuration. > > > > Noting this conflict, I propose adding a bit of text to draft-ietf-6man= - > multicast-scopes to update RFC 4007 for consistency with RFC 4291: > > > > Add section 3 (and renumber current section 3-5): > > > > 3. Updates to RFC 4007, section 5 > > > > Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > > way in which multicast scope 3 is configured. To resolve that > disagreement, > > change the last bullet in the list in section 5 of RFC 4007 as follow= s: > > > > OLD: > > > > o The boundaries of zones of a scope other than interface-local, > > link-local, and global must be defined and configured by network > > administrators. > > > > NEW: > > > > o Admin-Local scope is the smallest scope that must be > > administratively configured, i.e., not automatically derived > > from physical connectivity or other, non-multicast-related > > configuration. > > > > Looking for consensus in the 6man WG before I make this change... > > > > - Ralph > > > > On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn > wrote: > > > >> [...] > > > >> I think Ralph's approach is the correct one. His > >> draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a > >> reserved code point in the IPv6 addressing architecture. It > >> nominally updates RFC 4291 but should probably also update RFC 4007 as > these RFCs are in conflict regarding the automatic definition of scope 0x= 03. > > [...] > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dthaler@microsoft.com Fri Oct 25 13:49:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB3D11E8204; Fri, 25 Oct 2013 13:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.629 X-Spam-Level: X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2vDunxy9LZ3; Fri, 25 Oct 2013 13:49:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id A47EC11E81DC; Fri, 25 Oct 2013 13:49:16 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 25 Oct 2013 20:49:14 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.31]) with mapi id 15.00.0800.005; Fri, 25 Oct 2013 20:49:14 +0000 From: Dave Thaler To: "Ralph Droms (rdroms)" Thread-Topic: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) Thread-Index: AQHO0cMU/XWHe3FPLUK0axFdo1U6Q5oF46Ew Date: Fri, 25 Oct 2013 20:49:14 +0000 Message-ID: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(51704005)(199002)(80022001)(83322001)(74876001)(81542001)(81342001)(65816001)(85306002)(74366001)(83072001)(81816001)(74706001)(80976001)(81686001)(56776001)(54316002)(76482001)(47976001)(59766001)(77982001)(46102001)(51856001)(74316001)(54356001)(79102001)(74662001)(47446002)(74502001)(31966008)(69226001)(76796001)(56816003)(76576001)(76786001)(33646001)(77096001)(53806001)(49866001)(47736001)(50986001)(4396001)(63696002)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 20:49:41 -0000 Ralph wrote: [...] > >> NEW: > >> > >> Interface-Local, Link-Local, and Realm-Local scope boundaries > >> are automatically derived from physical connectivity or > >> other, non-multicast related configuration. Global scope has > >> no boundary. The boundaries of all other non-reserved scopes > >> are administratively configured. > > > > I disagree with the last sentence above. Specifically "non-reserved" > > should be removed. That is, we should not start precluding admin > > configuration of reserved scopes, given we didn't before. They just > > didn't have defined names or uses, but they could have been used > > within private environments. >=20 > Good catch. So the last sentence should read: >=20 > The boundaries of all other scopes are administratively configured. >=20 > ? Yes. -Dave From jinmei.tatuya@gmail.com Mon Oct 28 09:46:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FDF11E814C; Mon, 28 Oct 2013 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdWl+qb4APO1; Mon, 28 Oct 2013 09:46:53 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A153111E8260; Mon, 28 Oct 2013 09:46:49 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so6752092wes.38 for ; Mon, 28 Oct 2013 09:46:48 -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=TQylOX+RjV8qapGkBxtbp59ua6uTc10LbFEI6ta389c=; b=AaHdt1RwIa6jFqNbP+QfCAXGBJwqe6A40j3x2mGHIKxc684EL9qawnhcoEUn35WEom 86M+3eggxTx9KZXxMwUmW7udnv4Ty8WmYo24oJv2khWg9Tql2eeSb2qQ396r+P7OZ/sU dqHyIKg0Rl8ys6ZyPw+ccJWL9s//2oqvgL7rYLDOHzeZf13cJoqbVfD9R0QAObCFnCQf aD6b3T/CrGV336JRPPpU8tEM8Tgdd7871ySUpqKY0iW9lne/rmw3GdNTUYqt78Jzo8TG nr/B1GrQX/GraXTaumYqYl1hhRb5DtPfVh3ECcbyibszKAKsCxXgBkwQHcd111y5HulZ 22gQ== MIME-Version: 1.0 X-Received: by 10.194.77.41 with SMTP id p9mr2287263wjw.66.1382978808625; Mon, 28 Oct 2013 09:46:48 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Mon, 28 Oct 2013 09:46:48 -0700 (PDT) In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> Date: Mon, 28 Oct 2013 09:46:48 -0700 X-Google-Sender-Auth: MgmCN6IzTKBpROM0ljIkjsISEaQ Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Ralph Droms (rdroms)" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org>, Dave Thaler Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 16:46:54 -0000 At Fri, 25 Oct 2013 20:44:57 +0000, "Ralph Droms (rdroms)" wrote: > >> NEW: > >> > >> Interface-Local, Link-Local, and Realm-Local scope boundaries > >> are automatically derived from physical connectivity or > >> other, non-multicast related configuration. Global scope has > >> no boundary. The boundaries of all other non-reserved scopes > >> are administratively configured. > > > > I disagree with the last sentence above. Specifically > > "non-reserved" should be removed. That is, we should not start > > precluding admin configuration of reserved scopes, given we didn't > > before. They just didn't have defined names or uses, but they could > > have been used within private environments. > > Good catch. So the last sentence should read: > > The boundaries of all other scopes are administratively configured. First off, whether we include "non-reserved" or not, we should clarify this only applies to admin-local or larger. So, e.g. The boundaries of all other scopes of Admin-Local or larger are administratively configured. Secondly, I don't think the "NEW" text (necessarily) precludes admin configuration of reserved scopes (in this context it specifically means scope 15). With "non-reserved", I meant it specifically means scopes # 5-13. It intended to not say about scope #15, rather than preclude admin configuration for it. On the other hand, the suggested revised version explicitly states that the boundaries of scope #15 are administratively configured. I don't know if that's what this scope was supposed to be. If it was, then this version is okay. If not, and if the "NEW" version was confusing, I suggest: The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured. For reserved scopes, the way of configuring their boundaries will be defined when the semantics of the scope is defined. -- JINMEI, Tatuya From stig@venaas.com Mon Oct 28 12:49:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58B111E80E7; Mon, 28 Oct 2013 12:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrn8xtyuh9Dl; Mon, 28 Oct 2013 12:49:47 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 9958C11E8153; Mon, 28 Oct 2013 12:49:46 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 54307802A; Mon, 28 Oct 2013 20:49:44 +0100 (CET) Message-ID: <526EBFD2.50806@venaas.com> Date: Mon, 28 Oct 2013 12:49:38 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Ralph Droms (rdroms)" References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 04 Nov 2013 06:19:38 -0800 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org>, Dave Thaler Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 19:49:48 -0000 Hi On 10/28/2013 9:46 AM, 神明達哉 wrote: > At Fri, 25 Oct 2013 20:44:57 +0000, > "Ralph Droms (rdroms)" wrote: > >>>> NEW: >>>> >>>> Interface-Local, Link-Local, and Realm-Local scope boundaries >>>> are automatically derived from physical connectivity or >>>> other, non-multicast related configuration. Global scope has >>>> no boundary. The boundaries of all other non-reserved scopes >>>> are administratively configured. >>> >>> I disagree with the last sentence above. Specifically >>> "non-reserved" should be removed. That is, we should not start >>> precluding admin configuration of reserved scopes, given we didn't >>> before. They just didn't have defined names or uses, but they could >>> have been used within private environments. >> >> Good catch. So the last sentence should read: >> >> The boundaries of all other scopes are administratively configured. > > First off, whether we include "non-reserved" or not, we should clarify > this only applies to admin-local or larger. So, e.g. > > The boundaries of all other scopes of Admin-Local or larger are > administratively configured. > > Secondly, I don't think the "NEW" text (necessarily) precludes admin > configuration of reserved scopes (in this context it specifically > means scope 15). With "non-reserved", I meant it specifically means > scopes # 5-13. It intended to not say about scope #15, rather than > preclude admin configuration for it. On the other hand, the suggested > revised version explicitly states that the boundaries of scope #15 > are administratively configured. I don't know if that's what this > scope was supposed to be. If it was, then this version is okay. If > not, and if the "NEW" version was confusing, I suggest: > > The boundaries of all other non-reserved scopes of Admin-Local or > larger are administratively configured. For reserved scopes, the > way of configuring their boundaries will be defined when the > semantics of the scope is defined. I think this text might be fine. The main thing I want to say is that manual configuration of unassigned scopes is fine (as long as not reserved). But I don't think we want anyone to use reserved scopes in any way. Scope #14 is global and I don't think we have a meaningful way of using #15. Stig > -- > JINMEI, Tatuya > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From robert.cragie@gridmerge.com Mon Nov 4 07:22:11 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92311E81FA for ; Mon, 4 Nov 2013 07:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IegE2+81eUxD for ; Mon, 4 Nov 2013 07:22:06 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6DD11E829B for ; Mon, 4 Nov 2013 07:22:03 -0800 (PST) Received: from [94.116.147.9] (helo=[10.38.241.215]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VdLyP-0001Kl-KA for roll@ietf.org; Mon, 04 Nov 2013 15:21:49 +0000 Message-ID: <5277BB92.2060806@gridmerge.com> Date: Mon, 04 Nov 2013 15:21:54 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: roll@ietf.org References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B1888633B@tgxml338.toshiba.local>, <4887.1383503416@sandelman.ca> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090403080604050304010200" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:22:11 -0000 This is a cryptographically signed message in MIME format. --------------ms090403080604050304010200 Content-Type: multipart/alternative; boundary="------------000807060409050708030908" This is a multi-part message in MIME format. --------------000807060409050708030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/11/2013 23:16, Ralph Droms (rdroms) wrote: > > > On Nov 3, 2013, at 10:30 AM, "Michael Richardson"=20 > > wrote: > >> >> >=20 >> wrote: >>> I prefer describing 802.15.4-specific realm-local scope boundary >>> definition in another RFC so that both trickle-mcast and >>> multicast-scopes drafts are fully independent of any link-layer. >> >> Are you willing to write this document? > > In my opinion, the roll WG gets to answer the question "should=20 > realm-specific scope for 802.15.4 be defined in=20 > draft-ietf-roll-trickle-mcast?" > > If the consensus is no (which would be my answer), then, in my=20 > opinion, it's up to 6nan to decide between putting the definition in=20 > the multicast scopes doc or a separate RFC. +1 - my answer would also be no. I guess that should be 6man as well. > > - Ralph > >> >> --=20 >> Michael Richardson > >, Sandelman Software Works >> >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------000807060409050708030908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 03/11/2013 23:16, Ralph Droms (rdroms) wrote:


On Nov 3, 2013, at 10:30 AM, "Michael Richardson" <= mcr+ietf@sandelman.ca> wrote:


<yoshihiro.ohba= @toshiba.co.jp> wrote:
I prefer describing 802.15.4-specific realm-local scope boundary
definition in another RFC so that both trickle-mcast and
multicast-scopes drafts are fully independent of any link-layer.

Are you willing to write this document?

In my opinion, the roll WG gets to answer the question "should realm-specific scope for 802.15.4 be defined in draft-ietf-rol= l-trickle-mcast?"

=
If t= he consensus is no (which would be my answer), then, in my opinion, it's up to 6nan to decide between putting the definition in the multicast scopes doc or a separate RFC.
+1 - my answer would also be no. I guess tha= t should be 6man as well.

- Ralph


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




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

--------------000807060409050708030908-- --------------ms090403080604050304010200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzExMDQxNTIxNTRaMCMGCSqGSIb3DQEJBDEWBBTPvr992ShUJWmunrkB5eb4zXloUjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAA7wt/ShKGfIdpxLGo5kCh8GSfrKc4VWczFNZXcEqXqYmF0r XF2LWg/XYhI1o0+9uEfTbY4V3bC182RsbSiQDPsGFu/2dYREMcW2YMth4+OXs+aqEVfCV8vU OXqhkwS3571FMVXkjVf8th0AVadJc41faNGDYOaSpmqLUDHfvg4ktLU/yvz+ySKO0kltyJDi 4z6EajZUR5RUX+7LWycKUJbRsJYPYvgsOhQEbOBPR6f67zJeOjLS4bOtVfSRshcBqxb+bAZW UgC/8rXnqA2J0Aqa1ho2FMXeZGa/6x6JweGZ5avRVoHDnrM6JPtKioouh1u5+0ga9IOuexDL b1fxpzAAAAAAAAA= --------------ms090403080604050304010200-- From mcr@sandelman.ca Mon Nov 4 13:47:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03721E816D for ; Mon, 4 Nov 2013 13:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_MARKET=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXIGEHrWasAO for ; Mon, 4 Nov 2013 13:47:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4BF11E8163 for ; Mon, 4 Nov 2013 13:47:22 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D0F9E0B7 for ; Mon, 4 Nov 2013 17:58:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5FD6C63B88; Mon, 4 Nov 2013 16:47:17 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52D6163AED for ; Mon, 4 Nov 2013 16:47:17 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks References: <23764.1375904475 at sandelman.ca> 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 Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:47:26 -0000 -------- --=-=-= Content-Transfer-Encoding: quoted-printable {I deleted this email by mistake from my inbox, so I had to go back to the archive to get a copy of it} The original thread is here: http://www.ietf.org/mail-archive/web/roll/current/msg08082.html I asked about: >> As a result, different AMI deployments can vary significantly in ter= ms >> of memory size, computation power and communication capabilities. F= or >> this reason, the use of RPL storing or non-storing mode SHOULD be >> deployment specific. When meters are memory mcr> a manufacturer that wishes to make meters for more than one mcr> market/RFP would nee d to put in enough memory for the worst case mcr> storing situation. So the advice here is empty. And how many mcr> routes is enough? Daniel gave a well written overview of the considerations about how much ram to use, and I can't disagree with any of it. The thing is, one of the purpose of the applicability document it to make it clear how to use RFC6550 in a particular situation. There are very very very real needs for a document (specificallly, a "performance specification" to use language from trade agreements) that can be used to procure product. This is what we are here for: to write specifications. It seems to me that the AMI applicability statement is still overbroad in scope if it is not possible to answer the question of storing or non-storin= g. As such, in order to progress here, I think that we need to define clearly what kind of network we are talking about here. If that excludes some network that someone cares about, then we need another document.=20=20 Let me suggest some constraints. 1) lets deal with powered electric meters only as routers (unpowered meters -- water -- which operate on batteries may be leaf nod= es only) 2) lets deal with (sub-)urban housing densities. (so this rules out 47 story apartment buildings in Manhatten until someone either writes another document, or shows that the numbers we picked will work) 3) let's decide on storing mode and decide upon 64 route entries,=20 and see what happens for the 1000 nodes described in the Cisco experienc= e document http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01 (I'll bet somehow has simulator published results that support or update th= is analysis): - 51% of nodes were 1 hop away - 30% of nodes were 2 hops away, etc... 100-51% of 1000 =3D 490 nodes need to be reached by a 1st rank node. There are 510 first rank nodes, so on average each 1st rank node needs to have 1 route entry for one of the 490 downstream nodes. That's << 64! (I assume that the root node is special, and has more capacity) Based upon another diagram I saw about how meters might mesh down a street = in a linear fashion, and taking my street as an example (my meter is smart, but not IPv6), there are approx 12 houses on my side of the street on my side of the block. So, the house nearest the root needs 12 routes, and the depth of the three is 12. I assume that the ETX across the street or onto next blo= ck is too poor to bother. I'm not claiming that my numbers are sane, I'm just saying that we absolute= ly need to have a number here. Daniel> memory resources, and so on. As an example, although an AMI Daniel> platform for US mar ket is sharing some in common with an AMI Daniel> platform for EU market, their requirem ents/constraints, Daniel> functionalities and applications can be significantly differen = t. Then, let's please write two documents. I also want to point out, if one has power, then number of bits on the wire might not matter as much, and non-storing mode may be good. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUngV4oqHRg3pndX9AQK+gQQAh5/kSVyTpTjA5P5ddUZ5Pq/Dqg0Yr449 2/3ZIHPgd3WqlNtyILFVZNyvODRHTY6geinmuQAxis3Z8X56XPGFIdAGrveQ5t7W NXH554Ri3ykgbGWq8xSiz5AYie1gcQwSCQ2m1bMSBYUYViIpWwofY2x1sGesI3Eo 5YNBHHt/9EY= =/JDu -----END PGP SIGNATURE----- --=-=-=-- From Daniel.Popa@itron.com Tue Nov 5 02:00:12 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EA011E81AD for ; Tue, 5 Nov 2013 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl9TUgTISasf for ; Tue, 5 Nov 2013 02:00:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7677E21E8141 for ; Tue, 5 Nov 2013 01:59:21 -0800 (PST) Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB348.namprd04.prod.outlook.com (10.141.52.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 5 Nov 2013 09:59:18 +0000 Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.47]) with mapi id 15.00.0785.001; Tue, 5 Nov 2013 09:59:18 +0000 From: "Popa, Daniel" To: "'Michael Richardson (mcr+ietf@sandelman.ca)'" , Routing Over Low power and Lossy networks Thread-Topic: [Roll] AMI applicability: storing/non-storing. Thread-Index: AQHO2aeGDwcpLds380GbimRdLX4yv5oWX9CQ Date: Tue, 5 Nov 2013 09:59:17 +0000 Message-ID: <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.com> References: <23764.1375904475 at sandelman.ca> <13540.1383601637@sandelman.ca> In-Reply-To: <13540.1383601637@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(55784002)(51444003)(199002)(189002)(54316002)(56776001)(15202345003)(74876001)(47736001)(79102001)(47976001)(76482001)(50986001)(31966008)(74706001)(63696002)(81342001)(69226001)(74366001)(53806001)(54356001)(51856001)(65816001)(46102001)(80022001)(77982001)(74316001)(66066001)(47446002)(74502001)(59766001)(74662001)(49866001)(4396001)(83072001)(33646001)(77096001)(15975445006)(85306002)(76786001)(81542001)(76576001)(56816003)(81816001)(80976001)(81686001)(76796001)(87266001)(83322001)(19580405001)(85806002)(19580395003)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB348; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 10:00:12 -0000 Hi Michael, all,=20 Thank you for useful thoughts and feedback.=20 A few thoughts here + additional inputs within your lines.=20 I understand and ACK the challenge of making an AMI applicability statement= document for RPL storing mode of operation because one should take into ac= count - among others constraints - the neighborhood densities when designi= ng the product. And as you mentioned this may lead to providing an applica= bility statement as a function of specific field characteristics (street an= d building topology, building/meter densities, terrain topology, etc.), whi= ch eventually results into different applicability documents. However, my point is that these challenges are mostly related to RPL storin= g mode of operation. As a consequence, I am OK to narrow down the scope of = the applicability statement for AMI to only RPL non-storing mode of operati= on, as I stated in my previous email. As for having different specs for dif= ferent use cases, I expect that by focusing only on RPL non-storing mode a = single AMI applicability statement will be able to cover efficiently "all" = the reasonable requirements, for "all" use cases. =20 Regards, Daniel -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de M= ichael Richardson Envoy=E9=A0: lundi 4 novembre 2013 22:47 =C0=A0: Routing Over Low power and Lossy networks Objet=A0: Re: [Roll] AMI applicability: storing/non-storing. {I deleted this email by mistake from my inbox, so I had to go back to the = archive to get a copy of it} The original thread is here: http://www.ietf.org/mail-archive/web/roll/current/msg08082.html I asked about: >> As a result, different AMI deployments can vary significantly in ter= ms >> of memory size, computation power and communication capabilities. F= or >> this reason, the use of RPL storing or non-storing mode SHOULD be >> deployment specific. When meters are memory mcr> a manufacturer that wishes to make meters for more than one mcr> market/RFP would nee d to put in enough memory for the worst case mcr> storing situation. So the advice here is empty. And how many mcr> routes is enough? Daniel gave a well written overview of the considerations about how much ra= m to use, and I can't disagree with any of it. The thing is, one of the pu= rpose of the applicability document it to make it clear how to use RFC6550 = in a particular situation. There are very very very real needs for a docum= ent (specificallly, a "performance specification" to use language from trad= e agreements) that can be used to procure product. This is what we are her= e for: to write specifications. It seems to me that the AMI applicability statement is still overbroad in s= cope if it is not possible to answer the question of storing or non-storing= . DP> As previously suggested, let's do an incremental applicability statemen= t and narrow down the scope of this document to RPL non-storing mode only. = Eventually, explanation of this choice can be provided to the designers/imp= lementers at the beginning of the document (in the section describing out o= f scope topics) As such, in order to progress here, I think that we need to define clearly = what kind of network we are talking about here. If that excludes some netw= ork that someone cares about, then we need another document. =20 Let me suggest some constraints. 1) lets deal with powered electric meters only as routers (unpowered meters -- water -- which operate on batteries may be leaf nod= es only) DP> No objection to take this approach for this (1st) applicability stateme= nt for AMI. 2) lets deal with (sub-)urban housing densities. (so this rules out 47 stor= y apartment buildings in Manhatten until someone either writes another document, or shows that the numbers we picked will work) 3) let's decide on storing mode and decide upon 64 route entries,=20 and see what happens for the 1000 nodes described in the Cisco experienc= e document http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01 (I'll bet somehow has simulator published results that support or update th= is analysis): - 51% of nodes were 1 hop away - 30% of nodes were 2 hops away, etc... 100-51% of 1000 =3D 490 nodes need to be reached by a 1st rank node. There are 510 first rank nodes, so on average each 1st rank node needs to h= ave 1 route entry for one of the 490 downstream nodes. That's << 64! (I assume that the root node is special, and has more capacity) Based upon another diagram I saw about how meters might mesh down a street = in a linear fashion, and taking my street as an example (my meter is smart,= but not IPv6), there are approx 12 houses on my side of the street on my s= ide of the block. So, the house nearest the root needs 12 routes, and the = depth of the three is 12. I assume that the ETX across the street or onto next blo= ck is too poor to bother. I'm not claiming that my numbers are sane, I'm just saying that we absolute= ly need to have a number here. Daniel> memory resources, and so on. As an example, although an AMI Daniel> platform for US mar ket is sharing some in common with an AMI Daniel> platform for EU market, their requirem ents/constraints, Daniel> functionalities and applications can be significantly differen = t. Then, let's please write two documents. DP> I think we agree that the challenge is to provide the applicability for= the RPL storing mode of operation, because one may need to provide differe= nt specification for each such use cases. But if we focus only on applicabi= lity for AMI only for the RPL non-storing mode of operation, the above ment= ioned issues become almost irrelevant, irrespective of the market that is t= argeted, of the network/field characteristics, of traffic characteristics, = etc. I also want to point out, if one has power, then number of bits on the wire= might not matter as much, and non-storing mode may be good. --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From trac+roll@trac.tools.ietf.org Tue Nov 5 04:32:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FE811E8277 for ; Tue, 5 Nov 2013 04:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIaN86QSrHZq for ; Tue, 5 Nov 2013 04:32:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0801C11E8195 for ; Tue, 5 Nov 2013 04:32:45 -0800 (PST) Received: from localhost ([127.0.0.1]:44675 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdfoF-0002iK-Lx; Tue, 05 Nov 2013 13:32:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Tue, 05 Nov 2013 12:32:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/132#comment:13 Message-ID: <082.21b52332c9a507a483b4d61257fbbd47@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 12:32:47 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08321.html From: JINMEI, Tatuya Date: Mon, 28 Oct 2013 09:46:48 -0700 At Fri, 25 Oct 2013 20:44:57 +0000, "Ralph Droms (rdroms)" wrote: > >> NEW: > >> > >> Interface-Local, Link-Local, and Realm-Local scope boundaries > >> are automatically derived from physical connectivity or > >> other, non-multicast related configuration. Global scope has > >> no boundary. The boundaries of all other non-reserved scopes > >> are administratively configured. > > > > I disagree with the last sentence above. Specifically > > "non-reserved" should be removed. That is, we should not start > > precluding admin configuration of reserved scopes, given we didn't > > before. They just didn't have defined names or uses, but they could > > have been used within private environments. > > Good catch. So the last sentence should read: > > The boundaries of all other scopes are administratively configured. First off, whether we include "non-reserved" or not, we should clarify this only applies to admin-local or larger. So, e.g. The boundaries of all other scopes of Admin-Local or larger are administratively configured. Secondly, I don't think the "NEW" text (necessarily) precludes admin configuration of reserved scopes (in this context it specifically means scope 15). With "non-reserved", I meant it specifically means scopes # 5-13. It intended to not say about scope #15, rather than preclude admin configuration for it. On the other hand, the suggested revised version explicitly states that the boundaries of scope #15 are administratively configured. I don't know if that's what this scope was supposed to be. If it was, then this version is okay. If not, and if the "NEW" version was confusing, I suggest: The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured. For reserved scopes, the way of configuring their boundaries will be defined when the semantics of the scope is defined. -- JINMEI, Tatuya Source: http://www.ietf.org/mail- archive/web/roll/current/msg08322.htm I think this text might be fine. The main thing I want to say is that manual configuration of unassigned scopes is fine (as long as not reserved). But I don't think we want anyone to use reserved scopes in any way. Scope #14 is global and I don't think we have a meaningful way of using #15. ------------------------------------------------------------------------------------------------------------------- Source: From: Michael Richardson Date: Fri, 1 Nov 2013 16:41:55 -0400 (EDT) Robert Cragie wrote: > I would propose adding the language to > draft-ietf-roll-trickle-mcast. There doesn't seem much point to doing > another "world's shortest RFC". I agree. Michael Richardson Source: http://www.ietf.org/mail- archive/web/roll/current/msg08305.html I disagree, and think the text should be placed in draft-ietf-6man- multicast-scopes for reasons stated in the Issue #132 thread. -K- -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Tue Nov 5 04:44:15 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3611E8277 for ; Tue, 5 Nov 2013 04:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxMts+PfefU7 for ; Tue, 5 Nov 2013 04:44:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A294311E828C for ; Tue, 5 Nov 2013 04:44:07 -0800 (PST) Received: from localhost ([127.0.0.1]:45897 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdfzH-0008GP-6I; Tue, 05 Nov 2013 13:44:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Tue, 05 Nov 2013 12:44:03 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/132#comment:14 Message-ID: <082.c49a7b1ff9fc985c22e71855f2f9890a@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 12:44:15 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): '''CONSENSUS CALL''' -- resolution for #132: draft-ietf-roll-trickle- mcast-04 - Clarify scope value of 3 - subnet-local Source: http://www.ietf.org/mail-archive/web/roll/current/msg08303.html From: Michael Richardson Date: Fri, 01 Nov 2013 16:44:42 -0400 I would like to ask the WG to speak now if you object to this solution, specifically with the the text going into mcast-05. Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday). Ralph wrote: > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > draft-ietf-6man-multicast-scopes-00 or published separately in yet > another "world's shortest RFC". > > Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: > > When used with MPL, Realm-local scope is defined according to the > underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. > > As a further refinement, I suggest text be added to > draft-ietf-roll-trickle-mcast-05 to the effect of: > > "scop 4" can also be used with MPL to cover deployments that use > administratively defined scopes that cover, for example, subnets > based on different underlying network technologies. > > - Ralph -- Michael Richardson , Sandelman Software Works Source: http://www.ietf.org/mail- archive/web/roll/current/msg08304.html Here's a summary the situation: - draft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast transport protocol. It refers to scop 3 which has up to now been reserved. - draft-ietf-6man-multicast-scopes ("Scopes draft") defines scop 3 and states it must be automatically determined by data link connectivitiy. It recommends the proper place to define how the scope zone boundary is determined is in the "IP-over-Foo" draft for each data link that defines scop 3. - The MPL draft *must* reference the Scopes draft in order to utilize scop 3. It must also agree with the Scopes draft on the issue of whether the scop 3 boundary is automatically determined. This is included in issue #132 and REMAINS OPEN. - Another open question is where to locate the definition of scop 3 for 802.15.4 networks? Going by the recommendation in the Scopes draft, one solution for the latter is to issue a short update to RFC 4944. However, this is not the most expedient solution from the standpoint of finishing the MPL draft. The next best solution in my opinion is to place the 802.15.4 definition of scop 3 into the Scopes draft. Future data links that define scop 3 in their IP-over-Foo RFCs will then only need to reference the Scopes document for the precedent and not the MPL document as well. Since the MPL draft must already reference the Scopes draft anyway, this also solves one open issue for MPL. I personally think it's a bad idea to bury the definition of an automatically determined scope boundary for a particular data link within a transport protocol specification. Regards, -K- Source: http://www.ietf.org/mail- archive/web/roll/current/msg08306.html I prefer describing 802.15.4-specific realm-local scope boundary definition in another RFC so that both trickle-mcast and multicast-scopes drafts are fully independent of any link-layer. Regards, Yoshihiro Ohba Source: http://www.ietf.org/mail- archive/web/roll/current/msg08308.html Are you willing to write this document? Source: http://www.ietf.org/mail- archive/web/roll/current/msg08311.html If we choose to write another RFC, yes I can contribute to it. Regards, Yoshihiro Ohba Source: http://www.ietf.org/mail- archive/web/roll/current/msg08309.html Let's scope the effort this week. Ralph predicts it will be the World's shortest RFC; maybe we can get it right the first time. -K- Source: http://www.ietf.org/mail- archive/web/roll/current/msg08310.html In my opinion, the roll WG gets to answer the question "should realm- specific scope for 802.15.4 be defined in draft-ietf-roll-trickle- mcast?" If the consensus is no (which would be my answer), then, in my opinion, it's up to 6nan to decide between putting the definition in the multicast scopes doc or a separate RFC. Ralph Source: http://www.ietf.org/mail- archive/web/roll/current/msg08323.html +1 - my answer would also be no. I guess that should be 6man as well. Source: http://www.ietf.org/mail- archive/web/roll/current/msg08312.html Hello all, I support the idea of having the definition of multicast scope boundary in another RFC so that trickle-mcast and multicast-scopes drafts specify such IP features independent of the link-layer. And I am willing to contribute and help writing such RFC. I will unfortunately not be able to attend this IETF meeting, but I will be available via email. Regards, Daniel -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From iesg-secretary@ietf.org Tue Nov 5 10:49:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE711E8254; Tue, 5 Nov 2013 10:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLqoIE1gjgeW; Tue, 5 Nov 2013 10:48:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E511A21E80BE; Tue, 5 Nov 2013 10:47:22 -0800 (PST) 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: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131105184722.29536.20794.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 10:47:22 -0800 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'Terms used in Ruting for Low power And Lossy Networks' to Informational RFC (draft-ietf-roll-terminology-13.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 18:49:03 -0000 The IESG has approved the following document: - 'Terms used in Ruting for Low power And Lossy Networks' (draft-ietf-roll-terminology-13.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 Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ Technical Summary This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. Working Group Summary No concerns, the document had good support. Document Quality There was good support in the working group towards getting the definitions precise enough to be useful, but not overly specific. This Informational document contains only terminology so cannot be implemented, but the WG is actively using this document as a base reference in other work. There is no formal language in this document. Personnel Document Shepherd: Michael Richardson Responsible AD: Adrian Farrel RFC Editor Note Document Title s/Ruting/Routing/ Section 2 Directed Acyclic Graph: s/edge v again/vertex v again/ Section 2 OLD HVAC: Heating, Ventilation and Air Conditioning. A term applied to the comfort level of an internal space. NEW HVAC: Heating, Ventilation and Air Conditioning. A term applied to mechanisms used to maintain the comfort level of an internal space. END Section 2 Sleepy Node s/When no in/When not in/ From mcr@sandelman.ca Tue Nov 5 10:52:11 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D8521E818C for ; Tue, 5 Nov 2013 10:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQeXzcP1r0i9 for ; Tue, 5 Nov 2013 10:52:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 29BED21F969F for ; Tue, 5 Nov 2013 10:50:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E6202027E; Tue, 5 Nov 2013 15:01:41 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id F0C5A63B88; Tue, 5 Nov 2013 13:49:59 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DC38963AED; Tue, 5 Nov 2013 13:49:59 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.com> References: <23764.1375904475 at sandelman.ca> <13540.1383601637@sandelman.ca> <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.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 Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 18:52:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Popa, Daniel wrote: Daniel> However, my point is that these challenges are mostly related to Daniel> RPL storing mode of operation. As a consequence, I am OK to Daniel> narrow down the scope of the applicability statement for AMI to Daniel> only RPL non-storing mode of operation, as I stated in my Daniel> previous email. As for having different specs for different use Daniel> cases, I expect that by focusing only on RPL non-storing mode a Daniel> single AMI applicability statement will be able to cover Daniel> efficiently "all" the reasonable requirements, for "all" use Daniel> cases.=20=20=20 Ah, I did not understand that from your previous email. Yes, please. Pick non-storing, and lets' proceed!!! =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnk91YqHRg3pndX9AQJZZwP+JCVJ2RXscUkV/wQ2BUsXKDl/0yoqtv0Z 5ewftRFINcLY0NTxurhgWAY6oKcnJCaBuIOEEBfOF/05G7dzCjDbJ7ufMsfSuGRu Vt5sYhNkO5PZimlLOBVz+d7KP/f/t99jsZ5vCh58VFrAw6YDYjZyOUTY7X6LOeSv PVgXsRjNDKA= =V63K -----END PGP SIGNATURE----- --=-=-=-- From Randy.Turner@landisgyr.com Tue Nov 5 10:59:22 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D521E812E for ; Tue, 5 Nov 2013 10:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul2OdsilWFmE for ; Tue, 5 Nov 2013 10:59:17 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) by ietfa.amsl.com (Postfix) with ESMTP id 34E9721E8085 for ; Tue, 5 Nov 2013 10:59:13 -0800 (PST) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB016.eurprd01.prod.exchangelabs.com (10.255.176.38) with Microsoft SMTP Server (TLS) id 15.0.815.6; Tue, 5 Nov 2013 18:59:10 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.119]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.119]) with mapi id 15.00.0815.000; Tue, 5 Nov 2013 18:59:10 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] AMI applicability: storing/non-storing. Thread-Index: AQHO2aeOElTiGDu4skinht2fNlWkvJoWaBGAgACUR4CAAAFZMA== Date: Tue, 5 Nov 2013 18:59:09 +0000 Message-ID: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <23764.1375904475 at sandelman.ca> <13540.1383601637@sandelman.ca> <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.com> <7933.1383677399@sandelman.ca> In-Reply-To: <7933.1383677399@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(24454002)(377454003)(189002)(199002)(19580405001)(83322001)(54316002)(74876001)(19580395003)(80976001)(74706001)(50986001)(46102001)(83072001)(2656002)(51856001)(74316001)(53806001)(56816003)(81686001)(54356001)(77096001)(69226001)(81816001)(81342001)(80022001)(66066001)(59766001)(65816001)(76786001)(76796001)(85306002)(76482001)(87266001)(47976001)(47736001)(49866001)(56776001)(81542001)(33646001)(47446002)(15202345003)(15975445006)(4396001)(74502001)(31966008)(74366001)(77982001)(63696002)(79102001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB016; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 18:59:22 -0000 I agree that non-storing mode addresses the primary AMI use-case where endp= oints push data up and through the DODAG root. Could there be a "hybrid-storing" mode that doesn't use as much RAM to cont= ain routes to all nodes in a sub-tree? Instead of traditional storing mode,= could a node store just multicast memberships in all nodes "below" a parti= cular mote ? Assuming there would much fewer multicast memberships than wo= uld be required for RFC 6550 storing mode ? It's a variant of storing+mult= icast, without the traditional storing mode RAM usage. I'm still looking at the MPL document, so apologies if that's already discu= ssed. Randy -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Tuesday, November 05, 2013 1:50 PM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] AMI applicability: storing/non-storing. Popa, Daniel wrote: Daniel> However, my point is that these challenges are mostly related t= o Daniel> RPL storing mode of operation. As a consequence, I am OK to Daniel> narrow down the scope of the applicability statement for AMI to Daniel> only RPL non-storing mode of operation, as I stated in my Daniel> previous email. As for having different specs for different use Daniel> cases, I expect that by focusing only on RPL non-storing mode a Daniel> single AMI applicability statement will be able to cover Daniel> efficiently "all" the reasonable requirements, for "all" use Daniel> cases. Ah, I did not understand that from your previous email. Yes, please. Pick non-storing, and lets' proceed!!! -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ 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 mcr@sandelman.ca Tue Nov 5 13:50:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ADD21F9FBE for ; Tue, 5 Nov 2013 13:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNt5E73IwXOe for ; Tue, 5 Nov 2013 13:50:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 494A221F9F99 for ; Tue, 5 Nov 2013 13:50:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A0A02026C for ; Tue, 5 Nov 2013 18:02:04 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 219D463B88; Tue, 5 Nov 2013 16:50:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FE1D63AED for ; Tue, 5 Nov 2013 16:50:21 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <23764.1375904475 at sandelman.ca> <13540.1383601637@sandelman.ca> <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.com> <7933.1383677399@sandelman.ca> <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.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 Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 21:50:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Turner, Randy wrote: > Could there be a "hybrid-storing" mode that doesn't use as much RAM to > contain routes to all nodes in a sub-tree? Instead of traditional > storing mode, could a node store just multicast memberships in all > nodes "below" a particular mote ? Assuming there would much fewer > multicast memberships than would be required for RFC 6550 storing mode > ? It's a variant of storing+multicast, without the traditional stori= ng > mode RAM usage.=20 Yes there could be, but it needs more research.=20=20 There was at least one ID in the past year discussion how this could be supported.=20=20=20 The problem is not generally deep in the DODAG, as the fan out means that there are few children, thus they fit into ram. The problem is closer to the top, where there are more children than fit. There was significant discussion on the list and at meetings a few years ag= o; look 6 months before the publication date of 6550.=20=20 As I recall, one can not just keep some routes and not others due to how parents might change. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnloGIqHRg3pndX9AQIWoAQAxXFkMtumVXbHD1iWMb5fAz3e61GUlf6r 2SvkHElKXHLfcC306Z8PimVGOWbzL+woIcJL0UomatdlyhfmpvXLDoJDDXuvvyZ1 aJH6jvNZzTQZN5iITTolyXHKzyQhUgv66VHy06FlBO3ze789EpUIiDTI+NV8JvF2 uS1zC6onS6Y= =fyl+ -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Tue Nov 5 14:02:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331821E8166 for ; Tue, 5 Nov 2013 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9GhYjgADBJR for ; Tue, 5 Nov 2013 14:02:08 -0800 (PST) Received: from nm25-vm7.access.bullet.mail.bf1.yahoo.com (nm25-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.198]) by ietfa.amsl.com (Postfix) with ESMTP id 238B821E8122 for ; Tue, 5 Nov 2013 14:02:08 -0800 (PST) Received: from [66.196.81.166] by nm25.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 22:02:07 -0000 Received: from [98.138.104.98] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 22:02:07 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 05 Nov 2013 22:02:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1383688927; bh=zvXUvlvGu4viZuv2ONyzGxlDzr6AwiXrZ9Mlx9vt91A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=cjxQMyuHyrjt3MfNwffrR5lAIPa7ruehb7yN8GWDVz18v6BiTIGUIfbKHrXk839j/AiY7Z6KhJ1LOGtZQt+ze2mZkkL7M4wPvU4tPmEIyflcifa2zgzeQu6hf1P2GbmPS+DAQOVEgcBGcZaRjlABjdk5N/qC9Jn3Ohf8oaGmmfE= X-Yahoo-Newman-Id: 469425.4729.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0bad7.EVM1nnJCBi8wKbmIFHW9Ad2niEst50rQ8js88B4tB 41S1GniX_w7t4umKicWJweo3F1PU4Iu76EmqjyHRR_Z3.I6Mwjp5YWt1ymom FbzkU5s_j9MZuDu8EYvuJkj3yKwwntPAD0jJP7OhdfsCwrZNIdjoraznbDm0 wKPcwIYJrWmQmBK2rZSV3GQv2IWHn39MdFJj4pbh18cxkINg6TcSoKrXNIWb _pkb.wAwjTpNfB19G.ATBYOy1q905bSpbqbg2sKxXVdOWcanPMEg7tBj5_Wk YZ9IA3O3T_kLoA6z65V4.B8jlfjoRl_ARwL651XJ2aoY2h_nJ30x0U5d0WnZ Zru7sDRh.ZbtrU1cOkeVzwOjK4yz31LTj6KYAaFk_J6Nuxf96Op9afAzoaFi hxcYKfxH6T4ZNa0pTSDuUfqTAh1FWC6fVHV.g.KWyOuZFDwXkdPn14SjflSU vm7Jhrr0yzJoILtFqIFzTN8zLEB1gU39xTA71pio9ZlvcbVskZHcIb5VFZ.t ifCtoalM_xvUUXB8oIQ0iEfdIrjRgh4bD2NVvpt9aTaP1LeU- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [31.133.164.70] (d.sturek@31.133.164.70 with ) by smtp118.sbc.mail.ne1.yahoo.com with SMTP; 05 Nov 2013 22:02:07 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 05 Nov 2013 11:16:01 -0800 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] AMI applicability: storing/non-storing. In-Reply-To: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 22:02:13 -0000 Hi Randy, "Hybrid storing" modes were looked into awhile ago in ROLL and abandoned due to complexity. Currently, only storing and non-storing is supported in a specific DODAG instance. I think the topic of multicast support is a bit separate. I think you forwarded me a research paper that used storing mode to analyze multicast group member reachability. That is an interesting topic when considering multicast forwarding approaches that don't use flooding (although, I would expect that storing mode would be used with the approach since you need all of that routing information, plus multicast group membership, to make forwarding decisions) Don On 11/5/13 10:59 AM, "Turner, Randy" wrote: >I agree that non-storing mode addresses the primary AMI use-case where >endpoints push data up and through the DODAG root. > >Could there be a "hybrid-storing" mode that doesn't use as much RAM to >contain routes to all nodes in a sub-tree? Instead of traditional storing >mode, could a node store just multicast memberships in all nodes "below" >a particular mote ? Assuming there would much fewer multicast >memberships than would be required for RFC 6550 storing mode ? It's a >variant of storing+multicast, without the traditional storing mode RAM >usage. > >I'm still looking at the MPL document, so apologies if that's already >discussed. > >Randy > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Michael Richardson >Sent: Tuesday, November 05, 2013 1:50 PM >To: Routing Over Low power and Lossy networks >Subject: Re: [Roll] AMI applicability: storing/non-storing. > > >Popa, Daniel wrote: > Daniel> However, my point is that these challenges are mostly related >to > Daniel> RPL storing mode of operation. As a consequence, I am OK to > Daniel> narrow down the scope of the applicability statement for AMI >to > Daniel> only RPL non-storing mode of operation, as I stated in my > Daniel> previous email. As for having different specs for different >use > Daniel> cases, I expect that by focusing only on RPL non-storing mode >a > Daniel> single AMI applicability statement will be able to cover > Daniel> efficiently "all" the reasonable requirements, for "all" use > Daniel> cases. > >Ah, I did not understand that from your previous email. >Yes, please. Pick non-storing, and lets' proceed!!! > >-- >] Never tell me the odds! | ipv6 mesh >networks [ >] Michael Richardson, Sandelman Software Works | network >architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > >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 >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 any attachments. Thank you. >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From iesg-secretary@ietf.org Tue Nov 5 14:06:30 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71621F9E43; Tue, 5 Nov 2013 14:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUquwxB1Dk2c; Tue, 5 Nov 2013 14:06:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2253321E8171; Tue, 5 Nov 2013 14:06:06 -0800 (PST) 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: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131105220606.29590.68683.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 14:06:06 -0800 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'Terms used in Routing for Low power And Lossy Networks' to Informational RFC (draft-ietf-roll-terminology-13.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 22:06:30 -0000 The IESG has approved the following document: - 'Terms used in Routing for Low power And Lossy Networks' (draft-ietf-roll-terminology-13.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 Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ Technical Summary This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. Working Group Summary No concerns, the document had good support. Document Quality There was good support in the working group towards getting the definitions precise enough to be useful, but not overly specific. This Informational document contains only terminology so cannot be implemented, but the WG is actively using this document as a base reference in other work. There is no formal language in this document. Personnel Document Shepherd: Michael Richardson Responsible AD: Adrian Farrel RFC Editor Note Document Title s/Ruting/Routing/ Section 2 Directed Acyclic Graph: s/edge v again/vertex v again/ Section 2 OLD HVAC: Heating, Ventilation and Air Conditioning. A term applied to the comfort level of an internal space. NEW HVAC: Heating, Ventilation and Air Conditioning. A term applied to mechanisms used to maintain the comfort level of an internal space. END Section 2 Sleepy Node s/When no in/When not in/ From Daniel.Popa@itron.com Wed Nov 6 03:39:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811E21E80AD for ; Wed, 6 Nov 2013 03:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnKRV4ibJdcv for ; Wed, 6 Nov 2013 03:39:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id D30C521E8088 for ; Wed, 6 Nov 2013 03:39:15 -0800 (PST) Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB348.namprd04.prod.outlook.com (10.141.52.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 6 Nov 2013 11:39:13 +0000 Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.47]) with mapi id 15.00.0785.001; Wed, 6 Nov 2013 11:39:12 +0000 From: "Popa, Daniel" To: Don Sturek , Routing Over Low power and Lossy networks Thread-Topic: [Roll] AMI applicability: storing/non-storing. Thread-Index: AQHO2aeGDwcpLds380GbimRdLX4yv5oWX9CQgACciICAAAKQgIAABLaAgAENy7A= Date: Wed, 6 Nov 2013 11:39:12 +0000 Message-ID: <78e4248b6eae47149396ddfb04a7ae82@CO1PR04MB346.namprd04.prod.outlook.com> References: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(24454002)(55784002)(479174003)(377454003)(77096001)(83072001)(33646001)(85306002)(15975445006)(80976001)(81816001)(87266001)(76796001)(81686001)(56816003)(85806002)(19580395003)(2656002)(19580405001)(83322001)(76786001)(76576001)(81542001)(74366001)(81342001)(69226001)(15202345003)(56776001)(54316002)(74706001)(50986001)(76482001)(31966008)(47976001)(74876001)(47736001)(79102001)(74662001)(74502001)(59766001)(47446002)(74316001)(66066001)(63696002)(49866001)(4396001)(77982001)(51856001)(54356001)(53806001)(46102001)(65816001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB348; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 11:39:23 -0000 Hi Don, all, I agree that the support of (non-flooding) multicast forwarding topic can (= eventually should) be separated from the RPL mode of operations... IMHO, your statement about the need to use some flavor of RPL storing mode = for dealing with non-flooding multicast forwarding is right if your assumpt= ion is to use RPL messages for the multicast forwarding control plane (i.e.= , set-up/tear-down multicast tree, set-up/tear-down forwarding states in th= e nodes, etc.).=20 Ideally, it would be efficient to use a single control plane to manage unic= ast and multicast forwarding but - since this looks challenging in large sc= ale mesh networks- what should prevent one from actually using a DODAG (rou= ting) tree, built and maintained with a RPL non-storing mode, to build a no= n-flooding multicast forwarding tree (on top of that DODAG tree) by means = of a different control plane (by using, for example, MLDv2 protocol and ICM= Pv6 MLDv2 messages with the "right" modifications to fit LLN mesh constrain= ts & requirements)?=20 I would be interested in getting additional thoughts on this.=20 Regards, Daniel =20 -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de D= on Sturek Envoy=E9=A0: mardi 5 novembre 2013 20:16 =C0=A0: Routing Over Low power and Lossy networks Objet=A0: Re: [Roll] AMI applicability: storing/non-storing. Hi Randy, "Hybrid storing" modes were looked into awhile ago in ROLL and abandoned du= e to complexity. Currently, only storing and non-storing is supported in a= specific DODAG instance. I think the topic of multicast support is a bit separate. I think you forwarded me a research paper that used storing mode to analyze multicast group member reachability. That is an interesting topic when considering multicast forwarding approaches that don't use flooding (although, I would = expect that storing mode would be used with the approach since you need all= of that routing information, plus multicast group membership, to make forw= arding decisions) Don On 11/5/13 10:59 AM, "Turner, Randy" wrote: >I agree that non-storing mode addresses the primary AMI use-case where=20 >endpoints push data up and through the DODAG root. > >Could there be a "hybrid-storing" mode that doesn't use as much RAM to=20 >contain routes to all nodes in a sub-tree? Instead of traditional=20 >storing mode, could a node store just multicast memberships in all nodes "= below" >a particular mote ? Assuming there would much fewer multicast=20 >memberships than would be required for RFC 6550 storing mode ? It's a=20 >variant of storing+multicast, without the traditional storing mode RAM=20 >usage. > >I'm still looking at the MPL document, so apologies if that's already=20 >discussed. > >Randy > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 >Michael Richardson >Sent: Tuesday, November 05, 2013 1:50 PM >To: Routing Over Low power and Lossy networks >Subject: Re: [Roll] AMI applicability: storing/non-storing. > > >Popa, Daniel wrote: > Daniel> However, my point is that these challenges are mostly=20 >related to > Daniel> RPL storing mode of operation. As a consequence, I am OK to > Daniel> narrow down the scope of the applicability statement for=20 >AMI to > Daniel> only RPL non-storing mode of operation, as I stated in my > Daniel> previous email. As for having different specs for different=20 >use > Daniel> cases, I expect that by focusing only on RPL non-storing=20 >mode a > Daniel> single AMI applicability statement will be able to cover > Daniel> efficiently "all" the reasonable requirements, for "all" use > Daniel> cases. > >Ah, I did not understand that from your previous email. >Yes, please. Pick non-storing, and lets' proceed!!! > >-- >] Never tell me the odds! | ipv6 mesh >networks [ >] Michael Richardson, Sandelman Software Works | network >architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > >P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > >This e-mail (including any attachments) is confidential and may be=20 >legally privileged. If you are not an intended recipient or an=20 >authorized representative of an intended recipient, you are prohibited=20 >from using, copying or distributing the information in this e-mail or=20 >its attachments. If you have received this e-mail in error, please=20 >notify the sender immediately by return e-mail and delete all copies of=20 >this message and any 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 From mcr@sandelman.ca Fri Nov 8 12:24:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6437B11E8211; Fri, 8 Nov 2013 12:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDhX50Dmx4Wy; Fri, 8 Nov 2013 12:23:56 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id EA22911E8222; Fri, 8 Nov 2013 12:23:54 -0800 (PST) Received: from sandelman.ca (dhcp-a6d9.meeting.ietf.org [31.133.166.217]) by relay.sandelman.ca (Postfix) with ESMTPS id 0F42922077; Fri, 8 Nov 2013 15:23:52 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1296ACA0D7; Fri, 8 Nov 2013 15:23:55 -0500 (EST) From: "Michael Richardson" To: 6man@ietf.org, roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 08 Nov 2013 15:23:54 -0500 Message-ID: <4752.1383942234@sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] dinner consensus on trickle-mcast and multicast-scoopes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:24:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable (I didn't have time to write a shorter note) glossary for 6man readers: RPL =3D ROLL RFC6550 mesh-over routing protocol. MPL =3D ROLL draft-ietf-trickle-mcast multicast distribution protocol. This email is a bit long, but represents what I believe was the consensus that was arrived at by a number of ROLL WG ID authors, some Zigbee IP experts, and Ralph. This consensus was arrived at slowly over Tuesday night and Wednesday, and was brought to you by the letters B and I.=20=20 I will start with the executive summary: 1) there are some minor tweaks necessary to trickle-mcast to make it consistent with multicast-scopes, and to indicate that=20 encapsulation in scopes 4 and 5 are appropriate for some use cases 2) that the text in multicast-scopes that speaks of "administratively defined" is confusing to many, and a suggestion on different text will be posted in a reply to this email. =3D=3D=3D background and discussion Trickle-mcast must use/define scope 3 in order to get traffic to flow across the entire RPL LLN (mesh-over). The current multicast-scopes document makes scope 3 span all the interfaces of the nodes of a single instance of a technology. The intention was that IP-over-FOO documents would explain how this is defined, with the understanding that for 802.15.4 it would span all interfaces which are in a single PAN-ID. RPL, however, can and does run over many different link types, and there are existing deployed systems that have mixes of 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the technologies even alternating on a hop by hop basis. Both Zigbee IP, metering and home systems need to span multiple technologies for multicast, and Zigbee IP SEP 2 specifies using multicast to do service discovering using mDNS.=20=20 Many want to automatically configure a multicast scope to cover all of the interfaces which are part of an RPL DODAG and/or that an address in the same (multi-link subnet) prefix. There was many months of confusing discussion about having this be the definition of scope 3, but the alternate view was that MPL was not tied to RPL, and that neither the DODAG nor the prefix were inherent physical properties of the network in the way that a set of cables and a switch or a radio with a specific PANID. The origin of the second mis-understanding was that the text in multicast-scopes (and rfc 4291) says: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived The understanding of "administratively configured" for many people implies truck rolls, or ssh logins or router CLI commands. It was only when this assumption was clearly articulated that the origin of the conflict became clear to all parties. The new understanding is that "administratively configured" is not limited to the things that a human did it, but rather includes any processes or operations that a human (including an IETF document) might cause. The intent of multicast-scopes is not to limit ways that=20 scopes 4+ can be determined, but to clarify that scopes <=3D3 are *not* intended to be defined by a physical (or physical-like) topologies. To put it another way, a human, looking at some non-virtualized equipement likely can determine the extent of scope 1,2,3 even if there is no power connected. The conclusion was that the group reached was that scope 3 can be defined on a per-technology basis, and in wireless links such as the 802.15.4 PANID. Where exactly to define this is still an open question, but we did conclude that the place is *not* in trickle-mcast. We are undecided if we need another worlds-shortest-RFC on 805.15.4 (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but another RFC is preferred by most. (Perhaps; all)=20 In another place, to be determined, possibly in applicability statements, or possibly in an application specific document (e.g. something like "mdns-over-lln"), a process by which a scope 4 multicast boundary could be defined to be something like the set of all interfaces which are in at least one DODAG. It should fall to homenet to define scope 5 for use in the home to cover the set of interfaces which are in the inside of the homenet. This should be easy for homenet to articulate discover of the homenet boundary is already a work item. The LLN border router would be speaking homenet routing protocol on the interface that connects it to the homenet, and would include the LLN scope 4 zone as part of the scope 5 homenet. This implies that LLNs will be using scope 5 to do mDNS resolution, and that this packet will be carried through the LLNs various links encapsulated into a scope 3 packet. While it is likely that dnssd will not solve the multi-subnet problem using straight multicast, but rather using a proxy mechanism, use of scope 5 is agnostic to exactly how this would be done. A mote that wishes to resolve only within the LLN may use scope 3 or 4, while one that wants to possibly find things in any place of the home will use scope 5.=20=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSfUhaAAoJEKD0KQ7Gj3P2cCAH/3Ybx3ZgGr8zV0lk3TS5FMnY TRPkp/kkv6KoItC+4v1fpuHJm8spht97rWR0KzHcHZDPV2MoZDx3m2CbYRon78pP Dy+Cg4s5RLU7FnnzckCAvHaWfLn3OqvCHs3nhVi32/TCWt6qGIenxJsEeCNrUTMk ECUW8uiIOwEQH8k4Y/HwlY8MGY/ePa4z7APZzaEPPIXYcHgHig1KthukZ+gmywtC 0kedNqeyRmTBjEZR/sXx9okzSQsN9D330FOWvaaKgZtVwlXj+Y1dfPNJGR6yVl83 LHD7TXqhID5d15aptNWe6vzVx04fAVU+G5hRVy0tBsq7I6xv9Z5W/dTdMzUPytY= =wiSc -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 8 12:35:19 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72621F9DCB for ; Fri, 8 Nov 2013 12:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLQuLec80z8c for ; Fri, 8 Nov 2013 12:35:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8731721F8DA3 for ; Fri, 8 Nov 2013 12:35:13 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2393D2035D; Fri, 8 Nov 2013 16:47:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 46D4763B88; Fri, 8 Nov 2013 15:35:07 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 39D0863AED; Fri, 8 Nov 2013 15:35:07 -0500 (EST) From: Michael Richardson to: roll@ietf.org, johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com In-Reply-To: <13799.1383338682@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> <13799.1383338682@sandelman.ca> 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 Subject: Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:35:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: mcr> I would like to ask the WG to speak now if you object to this=20 mcr> solution, specifically with the the text going into mcast-05. mcr> Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday). The consensus call time is over this morning, thank you to all for the comments you made. The WG chairs found that there was sufficient disagreement early on that there was no consensus for the specific solution proposed below, nor was there consensus for the location suggested.=20 I started a new discussion today on the basis of an alternate set of text today.=20 mcr> Ralph wrote: >> This text could be added to draft-ietf-roll-trickle-mcast-05, or to >> draft-ietf-6man-multicast-scopes-00 or published separately in yet >> another "world's shortest RFC". >>=20 >> Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: >>=20 >> When used with MPL, Realm-local scope is defined according to the >> underlying network technology; for example, [cite the >> IP-over-IEEE802.15.4 definition]. >>=20 >> As a further refinement, I suggest text be added to >> draft-ietf-roll-trickle-mcast-05 to the effect of: >>=20 >> "scop 4" can also be used with MPL to cover deployments that use >> administratively defined scopes that cover, for example, subnets >> based on different underlying network technologies. >>=20 >> - Ralph mcr> -- mcr> Michael Richardson , Sandelman Software Wor= ks=20 mcr> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/char= ter/ =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUn1K+4qHRg3pndX9AQICJQP/bA9tQihTKpyuWtdv6++HFGbwL1qZr2Ak 54XidntDtFiFSKBPB4u9IdZ5nHQuIInk1Dbt6xIfoz4aP3yzqv8fUNBDOF3Ttyrr y4dLgBQLwu4Z5BCWOkft4HYF3r2kvjD2z5yjSKeyWSp/3H7UghW3+FDw/YwiDtoo sc6l2PaE3Gg= =ryIA -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 8 12:45:22 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB95311E80EC; Fri, 8 Nov 2013 12:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prnXUg3lo9pM; Fri, 8 Nov 2013 12:45:09 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66021E8082; Fri, 8 Nov 2013 12:44:50 -0800 (PST) Received: from sandelman.ca (dhcp-a6d9.meeting.ietf.org [31.133.166.217]) by relay.sandelman.ca (Postfix) with ESMTPS id F0BA122077; Fri, 8 Nov 2013 15:44:48 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A4F81CA0D7; Fri, 8 Nov 2013 15:44:52 -0500 (EST) To: ipv6@ietf.org, roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 08 Nov 2013 15:44:52 -0500 Message-ID: <5662.1383943492@sandelman.ca> From: Michael Richardson Subject: [Roll] dinner consensus on trickle-mcast and multicast-scoopes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:45:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable (I didn't have time to write a shorter note) (Resending because I got the 6man list address wrong. Wish there was an ali= as) glossary for 6man readers: RPL =3D ROLL RFC6550 mesh-over routing protocol. MPL =3D ROLL draft-ietf-trickle-mcast multicast distribution protocol. This email is a bit long, but represents what I believe was the consensus that was arrived at by a number of ROLL WG ID authors, some Zigbee IP experts, and Ralph. This consensus was arrived at slowly over Tuesday night and Wednesday, and was brought to you by the letters B and I.=20=20 I will start with the executive summary: 1) there are some minor tweaks necessary to trickle-mcast to make it consistent with multicast-scopes, and to indicate that=20 encapsulation in scopes 4 and 5 are appropriate for some use cases 2) that the text in multicast-scopes that speaks of "administratively defined" is confusing to many, and a suggestion on different text will be posted in a reply to this email. =3D=3D=3D background and discussion Trickle-mcast must use/define scope 3 in order to get traffic to flow across the entire RPL LLN (mesh-over). The current multicast-scopes document makes scope 3 span all the interfaces of the nodes of a single instance of a technology. The intention was that IP-over-FOO documents would explain how this is defined, with the understanding that for 802.15.4 it would span all interfaces which are in a single PAN-ID. RPL, however, can and does run over many different link types, and there are existing deployed systems that have mixes of 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the technologies even alternating on a hop by hop basis. Both Zigbee IP, metering and home systems need to span multiple technologies for multicast, and Zigbee IP SEP 2 specifies using multicast to do service discovering using mDNS.=20=20 Many want to automatically configure a multicast scope to cover all of the interfaces which are part of an RPL DODAG and/or that an address in the same (multi-link subnet) prefix. There was many months of confusing discussion about having this be the definition of scope 3, but the alternate view was that MPL was not tied to RPL, and that neither the DODAG nor the prefix were inherent physical properties of the network in the way that a set of cables and a switch or a radio with a specific PANID. The origin of the second mis-understanding was that the text in multicast-scopes (and rfc 4291) says: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived The understanding of "administratively configured" for many people implies truck rolls, or ssh logins or router CLI commands. It was only when this assumption was clearly articulated that the origin of the conflict became clear to all parties. The new understanding is that "administratively configured" is not limited to the things that a human did it, but rather includes any processes or operations that a human (including an IETF document) might cause. The intent of multicast-scopes is not to limit ways that=20 scopes 4+ can be determined, but to clarify that scopes <=3D3 are *not* intended to be defined by a physical (or physical-like) topologies. To put it another way, a human, looking at some non-virtualized equipement likely can determine the extent of scope 1,2,3 even if there is no power connected. The conclusion was that the group reached was that scope 3 can be defined on a per-technology basis, and in wireless links such as the 802.15.4 PANID. Where exactly to define this is still an open question, but we did conclude that the place is *not* in trickle-mcast. We are undecided if we need another worlds-shortest-RFC on 805.15.4 (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but another RFC is preferred by most. (Perhaps; all)=20 In another place, to be determined, possibly in applicability statements, or possibly in an application specific document (e.g. something like "mdns-over-lln"), a process by which a scope 4 multicast boundary could be defined to be something like the set of all interfaces which are in at least one DODAG. It should fall to homenet to define scope 5 for use in the home to cover the set of interfaces which are in the inside of the homenet. This should be easy for homenet to articulate discover of the homenet boundary is already a work item. The LLN border router would be speaking homenet routing protocol on the interface that connects it to the homenet, and would include the LLN scope 4 zone as part of the scope 5 homenet. This implies that LLNs will be using scope 5 to do mDNS resolution, and that this packet will be carried through the LLNs various links encapsulated into a scope 3 packet. While it is likely that dnssd will not solve the multi-subnet problem using straight multicast, but rather using a proxy mechanism, use of scope 5 is agnostic to exactly how this would be done. A mote that wishes to resolve only within the LLN may use scope 3 or 4, while one that wants to possibly find things in any place of the home will use scope 5.=20=20 =2D- Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSfU1EAAoJEKD0KQ7Gj3P2QEMIAIlfwa15fEgVCErMXVTUQvYG yvqLK8D78LNIBDkXKplaKRtxgR9A0RvZV02NguF9FN/LUYAmh0gCJEO5I3EEvBJj oaaLboIWtWZVDI+M1q0OmRK17JEo3xJonlV/Yf/VvzYpYiUBBBjackJ3ACn2MRke gijx0g8tmvCy2WAufTQo5qYE7w3d3lTtx+xJv4Ofq9Q2yg7yHBxEruXqI0Y9P7aj +DWse8YYh05dznZy3tM4fORTAGZfc5WKiQ5inbr+qkaxx4gIYuxNHAhPdYuyuoY1 Acz9BQBl3y9cbzFkqPg0QiMDg3FXg/djTQZrNQeO8zcEV9svvcRNrSICKG9ZvRo= =DHu0 -----END PGP SIGNATURE----- --=-=-=-- From trac+roll@trac.tools.ietf.org Fri Nov 8 12:56:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183011E80DC for ; Fri, 8 Nov 2013 12:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CalY2qHVK4h0 for ; Fri, 8 Nov 2013 12:56:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F0A7921E80B6 for ; Fri, 8 Nov 2013 12:56:21 -0800 (PST) Received: from localhost ([127.0.0.1]:39099 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vet68-0007sv-PJ; Fri, 08 Nov 2013 21:56:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 08 Nov 2013 20:56:08 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:15 Message-ID: <082.8c2d90e6ada51d6c62c55cd2331ed9d3@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:56:47 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08335.html Subject: [Roll] dinner consensus on trickle-mcast and multicast- scoopes[[BR]] From: "Michael Richardson" [[BR]] Date: Fri, 08 Nov 2013 15:23:54 -0500[[BR]] glossary for 6man readers: RPL = ROLL RFC6550 mesh-over routing protocol.[[BR]] MPL = ROLL draft-ietf-trickle-mcast multicast distribution protocol. This email is a bit long, but represents what I believe was the consensus that was arrived at by a number of ROLL WG ID authors, some Zigbee IP experts, and Ralph. This consensus was arrived at slowly over Tuesday night and Wednesday, and was brought to you by the letters B and I. I will start with the executive summary: 1) there are some minor tweaks necessary to trickle-mcast to make it consistent with multicast-scopes, and to indicate that encapsulation in scopes 4 and 5 are appropriate for some use cases 2) that the text in multicast-scopes that speaks of "administratively defined" is confusing to many, and a suggestion on different text will be posted in a reply to this email. ''' background and discussion''' Trickle-mcast must use/define scope 3 in order to get traffic to flow across the entire RPL LLN (mesh-over). The current multicast-scopes document makes scope 3 span all the interfaces of the nodes of a single instance of a technology. The intention was that IP-over-FOO documents would explain how this is defined, with the understanding that for 802.15.4 it would span all interfaces which are in a single PAN-ID. RPL, however, can and does run over many different link types, and there are existing deployed systems that have mixes of 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the technologies even alternating on a hop by hop basis. Both Zigbee IP, metering and home systems need to span multiple technologies for multicast, and Zigbee IP SEP 2 specifies using multicast to do service discovering using mDNS. Many want to automatically configure a multicast scope to cover all of the interfaces which are part of an RPL DODAG and/or that an address in the same (multi-link subnet) prefix. There was many months of confusing discussion about having this be the definition of scope 3, but the alternate view was that MPL was not tied to RPL, and that neither the DODAG nor the prefix were inherent physical properties of the network in the way that a set of cables and a switch or a radio with a specific PANID. The origin of the second mis-understanding was that the text in multicast-scopes (and rfc 4291) says: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived The understanding of "administratively configured" for many people implies truck rolls, or ssh logins or router CLI commands. It was only when this assumption was clearly articulated that the origin of the conflict became clear to all parties. The new understanding is that "administratively configured" is not limited to the things that a human did it, but rather includes any processes or operations that a human (including an IETF document) might cause. The intent of multicast-scopes is not to limit ways that scopes 4+ can be determined, but to clarify that scopes <=3 are *not* intended to be defined by a physical (or physical-like) topologies. To put it another way, a human, looking at some non-virtualized equipement likely can determine the extent of scope 1,2,3 even if there is no power connected. The conclusion was that the group reached was that scope 3 can be defined on a per-technology basis, and in wireless links such as the 802.15.4 PANID. Where exactly to define this is still an open question, but we did conclude that the place is *not* in trickle-mcast. We are undecided if we need another worlds-shortest-RFC on 805.15.4 (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but another RFC is preferred by most. (Perhaps; all) In another place, to be determined, possibly in applicability statements, or possibly in an application specific document (e.g. something like "mdns-over-lln"), a process by which a scope 4 multicast boundary could be defined to be something like the set of all interfaces which are in at least one DODAG. It should fall to homenet to define scope 5 for use in the home to cover the set of interfaces which are in the inside of the homenet. This should be easy for homenet to articulate discover of the homenet boundary is already a work item. The LLN border router would be speaking homenet routing protocol on the interface that connects it to the homenet, and would include the LLN scope 4 zone as part of the scope 5 homenet. This implies that LLNs will be using scope 5 to do mDNS resolution, and that this packet will be carried through the LLNs various links encapsulated into a scope 3 packet. While it is likely that dnssd will not solve the multi-subnet problem using straight multicast, but rather using a proxy mechanism, use of scope 5 is agnostic to exactly how this would be done. A mote that wishes to resolve only within the LLN may use scope 3 or 4, while one that wants to possibly find things in any place of the home will use scope 5. Michael Richardson -on the road- -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From kerlyn2001@gmail.com Fri Nov 8 18:25:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEBB11E80FB; Fri, 8 Nov 2013 18:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAtHxpBZCftg; Fri, 8 Nov 2013 18:25:09 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4437311E80E2; Fri, 8 Nov 2013 18:25:09 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id g12so1621100oah.0 for ; Fri, 08 Nov 2013 18:25:08 -0800 (PST) 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=vQ9+mJ1lzN5PnXaFNAgutzzrXZgejH0OxzoDPDIJ8JI=; b=SeK3e5vMT7hHQwCifW9ukUmpbxbwQ8bK6eGP1a8OkCRwm1EjK6DhB0usCD5KCR7PO5 y4k18ExuI0p8X4Nub2Q11KzfSgo+tk7xjUX41BSIqqqsCNgT0NZJyk7lxyjPG0QBdFEu ME/HJY9zV+ayB8djbYizyqxaGD7iBK/HKKMsCLyWjC+goIqeWoagSVWL1sXFVG1AR9mW ag5pwMnYm3ybVzDvI19w7Aj8seLoWZWGreuYo16OE+kkozt6QkImCEfiBcqOFNzQKzc6 dyfeH/meTdsCEyjmHnVGiwEvXFnHrjNbYfOJDCXPsOy3yxaxURd9LDNObipOu7XfRcg2 /FkA== MIME-Version: 1.0 X-Received: by 10.60.116.230 with SMTP id jz6mr14365541oeb.21.1383963908587; Fri, 08 Nov 2013 18:25:08 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Fri, 8 Nov 2013 18:25:08 -0800 (PST) In-Reply-To: <5662.1383943492@sandelman.ca> References: <5662.1383943492@sandelman.ca> Date: Fri, 8 Nov 2013 18:25:08 -0800 X-Google-Sender-Auth: nVPRjS_4ddOwCo8S6ulnN-9n20o Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0115e84a2748db04eab535b0 Cc: 6man 6man Subject: Re: [Roll] dinner consensus on trickle-mcast and multicast-scoopes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 09 Nov 2013 02:25:11 -0000 --089e0115e84a2748db04eab535b0 Content-Type: text/plain; charset=ISO-8859-1 Michael, Thank you for transcribing the Scopes Trial. I have added some comments below. On Fri, Nov 8, 2013 at 12:44 PM, Michael Richardson wrote: > > (I didn't have time to write a shorter note) > (Resending because I got the 6man list address wrong. Wish there was an > alias) > > glossary for 6man readers: > RPL = ROLL RFC6550 mesh-over routing protocol. > MPL = ROLL draft-ietf-trickle-mcast multicast distribution > protocol. > > This email is a bit long, but represents what I believe was the > consensus that was arrived at by a number of ROLL WG ID authors, some > Zigbee IP experts, and Ralph. This consensus was arrived at slowly > over Tuesday night and Wednesday, and was brought to you by the letters > B and I. > > I will start with the executive summary: > > 1) there are some minor tweaks necessary to trickle-mcast to make > it consistent with multicast-scopes, and to indicate that > encapsulation in scopes 4 and 5 are appropriate for some use cases > > Please also consider adding encapsulation of data in scope 2 messages so that MPL can be used in environments where scopes 3 - 5 are not defined. 2) that the text in multicast-scopes that speaks of "administratively > defined" is confusing to many, and a suggestion on different text > will be posted in a reply to this email. > > === background and discussion > > Trickle-mcast must use/define scope 3 in order to get traffic to flow > across the entire RPL LLN (mesh-over). Can we limit this to "must use"? It is for draft-ietf-6man-multicast-scopes to define scope 3. > The current multicast-scopes > document makes scope 3 span all the interfaces of the nodes of a single > instance of a technology. The intention was that IP-over-FOO documents > would explain how this is defined, with the understanding that for > 802.15.4 it would span all interfaces which are in a single PAN-ID. > > RPL, however, can and does run over many different link types, and there > are existing deployed systems that have mixes of > 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the > technologies even alternating on a hop by hop basis. Both Zigbee IP, > metering and home systems need to span multiple technologies for > multicast, and Zigbee IP SEP 2 specifies using multicast to do service > discovering using mDNS. > > SEP2.0 is now IEEE 2030.5 > Many want to automatically configure a multicast scope to cover all of > the interfaces which are part of an RPL DODAG and/or that an address in > the same (multi-link subnet) prefix. There was many months of > confusing discussion about having this be the definition of scope 3, but > the alternate view was that MPL was not tied to RPL, and that neither the > DODAG nor the prefix were inherent physical properties of the network in > the way that a set of cables and a switch or a radio with a specific > PANID. > > The origin of the second mis-understanding was that the text in > multicast-scopes (and rfc 4291) says: > > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > > The understanding of "administratively configured" for many people > implies truck rolls, or ssh logins or router CLI commands. It was > only when this assumption was clearly articulated that the origin of the > conflict became clear to all parties. > > The paragraph above from RFC 4291 continues: from physical connectivity or other, non-multicast-related configuration. So draft-ietf-6man-multicast-scopes may require some adjustments to *allow* automatic determination of boundaries of scope >= 4 based on non-multicast-related configuration. The new understanding is that "administratively configured" is not > limited to the things that a human did it, but rather includes any > processes or operations that a human (including an IETF document) might > cause. The intent of multicast-scopes is not to limit ways that > scopes 4+ can be determined, but to clarify that scopes <=3 are *not* > intended to be defined by a physical (or physical-like) topologies. > > I think you mean that boundaries for scopes <= 3 *are* automatically derived from some physical connectivity relation whereas for scopes >= 4 they are not? > To put it another way, a human, looking at some non-virtualized > equipement likely can determine the extent of scope 1,2,3 even if there > is no power connected. > > The conclusion was that the group reached was that scope 3 can be > defined on a per-technology basis, and in wireless links such as > the 802.15.4 PANID. Where exactly to define this is still an open > question, but we did conclude that the place is *not* in trickle-mcast. > We are undecided if we need another worlds-shortest-RFC on 805.15.4 > (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but > another RFC is preferred by most. (Perhaps; all) > > In another place, to be determined, possibly in applicability > statements, or possibly in an application specific document > (e.g. something like "mdns-over-lln"), a process by which a scope 4 > multicast boundary could be defined to be something like the set of all > interfaces which are in at least one DODAG. > > Just to summarize to this point, boundaries of scopes >= 4 may be determined by configuration under certain circumstances. However, the constraints imposed by RFC 4007 cannot be violated. So the definition example above is only applicable if the DODAG completely contains any and all scope 3 zones that fall within its borders. In situations where multiple DODAGs are defined over a connected topology satisfying the scope 3 definition, a scope 4 boundary cannot be determined by the DODAG definition. Also, once defined, the zone boundary is the same for all applications using that multicast scope. It should fall to homenet to define scope 5 for use in the home to cover > the set of interfaces which are in the inside of the homenet. This > should be easy for homenet to articulate discover of the homenet > boundary is already a work item. The LLN border router would be > speaking homenet routing protocol on the interface that connects it to > the homenet, and would include the LLN scope 4 zone as part of the scope > 5 homenet. > > This implies that LLNs will be using scope 5 to do mDNS resolution, and > that this packet will be carried through the LLNs various links > encapsulated into a scope 3 packet. This behavior has been specified by SEP2 based on an expired experimental draft. It is beyond unlikely that dnssd WG will adopt this approach. Note that homenet would have to adopt some multicast routing protocol in order to forward scope 5 multicast if there are multiple non-LLN links. While it is likely that dnssd will > not solve the multi-subnet problem using straight multicast, but rather > using a proxy mechanism, use of scope 5 is agnostic to exactly how this > would be done. > A mote that wishes to resolve only within the LLN may use scope 3 or 4, > while one that wants to possibly find things in any place of the home > will use scope 5. > > This raises an interesting question from the application perspective. As I mentioned at the mic today in dnssd, RFC 6762 says: Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). draft-lynn-homenet-site-mdns took the same approach and designated ".site." as a special domain to signal the application's intent that the query should be delivered to the site-local zone FF05::FB. This is the draft that helped precipitate the earlier gTLD discussion with ICANN that was referred to in dnssd today. We may need a more general mechanism for applications that use Variable Scope Multicast Addresses to signal the desired scope to the lower layer(s) (or perhaps always default to the largest locally defined scope?) -K- -- > Michael Richardson > -on the road- > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0115e84a2748db04eab535b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Michael,

Thank you for transcribing= the Scopes Trial.=A0 I have added some
comments below.=A0 <kel= />


On F= ri, Nov 8, 2013 at 12:44 PM, Michael Richardson <mcr@sandelman.ca> wrote:

(I didn't have time to write a shorter note)
(Resending because I got the 6man list address wrong. Wish there was an ali= as)

glossary for 6man readers:
=A0 =A0 =A0 RPL =3D ROLL RFC6550 mesh-over routing protocol.
=A0 =A0 =A0 MPL =3D ROLL draft-ietf-trickle-mcast multicast distribution =A0 =A0 =A0 =A0 =A0 =A0 protocol.

This email is a bit long, but represents what I believe was the
consensus that was arrived at by a number of ROLL WG ID authors, some
Zigbee IP experts, and Ralph. =A0This consensus was arrived at slowly
over Tuesday night and Wednesday, and was brought to you by the letters
B and I.

I will start with the executive summary:

1) there are some minor tweaks necessary to trickle-mcast to make
=A0 =A0it consistent with multicast-scopes, and to indicate that
=A0 =A0encapsulation in scopes 4 and 5 are appropriate for some use cases
Please also consider adding encapsulation of data in = scope 2 messages
so that MPL can be used in environments wher= e scopes 3 - 5 are not
defined.=A0 <kel/>

2) that the text in multicast-scopes that speaks of "administratively<= br> =A0 =A0defined" is confusing to many, and a suggestion on different te= xt
=A0 =A0will be posted in a reply to this email.

=3D=3D=3D background and discussion

Trickle-mcast must use/define scope 3 in order to get traffic to flow
across the entire RPL LLN (mesh-over).

Can= we limit this to "must use"?=A0 It is for draft-ietf-6man-multic= ast-scopes
to define scope 3.=A0 <kel/>
=A0
The current multicast-sco= pes
document makes scope 3 span all the interfaces of the nodes of a single
instance of a technology. =A0The intention was that IP-over-FOO documents would explain how this is defined, with the understanding that for
802.15.4 it would span all interfaces which are in a single PAN-ID.

RPL, however, can and does run over many different link types, and there are existing deployed systems that have mixes of
802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the
technologies even alternating on a hop by hop basis. =A0 Both Zigbee IP, metering and home systems need to span multiple technologies for
multicast, and Zigbee IP SEP 2 specifies using multicast to do service
discovering using mDNS.

SEP2.0 is now IEEE 2030.5=A0 <kel/>
=A0
<= /div>
Many want to automatically configure a multicast scope to cover all of
the interfaces which are part of an RPL DODAG and/or that an address in
the same (multi-link subnet) prefix. =A0 There was many months of
confusing discussion about having this be the definition of scope 3, but the alternate view was that MPL was not tied to RPL, and that neither the DODAG nor the prefix were inherent physical properties of the network in the way that a set of cables and a switch or a radio with a specific
PANID.

The origin of the second mis-understanding was that the text in
multicast-scopes (and rfc 4291) says:

=A0 =A0 =A0 =A0 =A0Admin-Local scope is the smallest scope that must be
=A0 =A0 =A0 =A0 =A0administratively configured, i.e., not automatically der= ived

The understanding of "administratively configured" for many peopl= e
implies truck rolls, or ssh logins or router CLI commands. =A0It was
only when this assumption was clearly articulated that the origin of the conflict became clear to all parties.

The paragraph above from RFC 4291 continues:

<= /div>
=A0=A0=A0=A0 from physical connectivity or other, non-multicast-r= elated
=A0=A0=A0=A0 configuration.

So draft= -ietf-6man-multicast-scopes may require some adjustments
to *allow* automatic determination of boundaries of scope >= =3D 4
based on non-multicast-related configuration.=A0 <ke= l/>

The new understanding is that "administratively configured" is no= t
limited to the things that a human did it, but rather includes any
processes or operations that a human (including an IETF document) might
cause. =A0 The intent of multicast-scopes is not to limit ways that
scopes 4+ can be determined, but to clarify that scopes <=3D3 are *not*<= br> intended to be defined by a physical (or physical-like) topologies.

I think you mean that boundaries for scopes <=3D 3= *are* automatically
derived from some physical connectivity = relation whereas for scopes
>=3D 4 they are not?=A0 <kel/>
= =A0
To put it another way, a human, looking at some non-virtualized
equipement likely can determine the extent of scope 1,2,3 even if there
is no power connected.

The conclusion was that the group reached was that scope 3 can be
defined on a per-technology basis, and in wireless links such as
the 802.15.4 PANID. =A0 Where exactly to define this is still an open
question, but we did conclude that the place is *not* in trickle-mcast.
We are undecided if we need another worlds-shortest-RFC on 805.15.4
(effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but
another RFC is preferred by most. (Perhaps; all)

In another place, to be determined, possibly in applicability
statements, or possibly in an application specific document
(e.g. something like "mdns-over-lln"), a process by which a scope= 4
multicast boundary could be defined to be something like the set of all
interfaces which are in at least one DODAG.

Just to summarize to this point, boundaries of scopes= >=3D 4 may be
determined by configuration under certain c= ircumstances.=A0 However, the
constraints imposed by RFC 4007 cannot be = violated.=A0 So the definition
example above is only applicable if the DODAG completely contain= s
any and all scope 3 zones that fall within its borders.=A0 = In situations where
multiple DODAGs are defined over a connec= ted topology satisfying the
scope 3 definition, a scope 4 boundary cannot be determined by t= he
DODAG definition.=A0 Also, once defined, the zone boundary= is the same
for all applications using that multicast scope.=A0 <kel= />

It should fall to homenet to define scope 5 for use in the home to cover the set of interfaces which are in the inside of the homenet. =A0This
should be easy for homenet to articulate discover of the homenet
boundary is already a work item. =A0 =A0The LLN border router would be
speaking homenet routing protocol on the interface that connects it to
the homenet, and would include the LLN scope 4 zone as part of the scope 5 homenet.

This implies that LLNs will be using scope 5 to do mDNS resolution, and
that this packet will be carried through the LLNs various links
encapsulated into a scope 3 packet. =A0

Th= is behavior has been specified by SEP2 based on an expired experimental
=
draft.=A0 It is beyond unlikely that dnssd WG will adopt this ap= proach. Note
that homenet would have to adopt some multicast routing protocol= in order
to forward scope 5 multicast if there are multiple non-LLN lin= ks.=A0 <kel/>

While it is likely that dnssd will
not solve the multi-subnet problem using straight multicast, but rather
using a proxy mechanism, use of scope 5 is agnostic to exactly how this
would be done.
A mote that wishes to resolve only within the LLN may use scope 3 or 4,
while one that wants to possibly find things in any place of the home
will use scope 5.

This raises an interesting question from the applicat= ion perspective.
As I mentioned at the mic today in dnssd, RF= C 6762 says:

=A0=A0=A0=A0 Any DNS query for a name ending= with ".local." MUST be sent to the
=A0=A0=A0=A0 mDNS IPv4 link-local multicast address 224.0.0.251 = (or its IPv6
=A0=A0=A0=A0 equivalent FF02::FB).

draft-= lynn-homenet-site-mdns took the same approach and designated
= ".site." as a special domain to signal the application's inte= nt that the
query should be delivered to the site-local zone FF05::FB.=A0 Th= is is the
draft that helped precipitate the earlier gTLD disc= ussion with ICANN
that was referred to in dnssd today.=A0 We = may need a more general
mechanism for applications that use Variable Scope Multicast
= Addresses to signal the desired scope to the lower layer(s) (or perhaps
= always default to the largest locally defined scope?)

-K-

--
Michael Richardson
-on the road-



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


--089e0115e84a2748db04eab535b0-- From rdroms.ietf@gmail.com Sun Nov 10 07:02:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA1021E80C3; Sun, 10 Nov 2013 07:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndf-6WW9J+xP; Sun, 10 Nov 2013 07:02:29 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 36DEE21E80BB; Sun, 10 Nov 2013 07:02:29 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id cm18so1094886qab.9 for ; Sun, 10 Nov 2013 07:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=xv1fEVXVEm0uRQWwCdcVbvnlECjWxOPqW8GKu0p3lic=; b=ByrNvAyPPhYQPGBdyUKkkHtFunC4yg6GtbQnvtrHOQNvrV3FeV6ddNdXQ1qaRlaPj5 2TNaX/97Kx62l2QbvXGhSPMepqSMsl/HNTqDj/knlmxJ+HJ0j7RHb93eIeEB4QcmFUwI qp19rNEzhLunYkfTpeKJi8tvzqjDeKOD6HrW7Cc1dYXg/JDm16VMkt2DhTuR1014P6xY 8Mr5ZjMPw3mz0Cow3maVYBY25OtzAibrU7kMcUVwYM7pEWoHCpVp45XpqFvG8UPO5Dhh tfWybfZrIdDNn82zN0IyX97sI/fufmiSu+Mhy7I4C0uCy0O24mnTAYNSTPENWrFzdadC /qtA== X-Received: by 10.224.87.198 with SMTP id x6mr41377351qal.61.1384095748748; Sun, 10 Nov 2013 07:02:28 -0800 (PST) Received: from [10.86.255.31] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id r5sm47032010qaj.13.2013.11.10.07.02.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 07:02:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <5662.1383943492@sandelman.ca> Date: Sun, 10 Nov 2013 09:02:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2BBDB8B6-FBF9-424E-AACD-6E96E9D54801@gmail.com> References: <5662.1383943492@sandelman.ca> To: Routing Over Low power and Lossy networks , "ipv6@ietf.org List IPv6" X-Mailer: Apple Mail (2.1510) Subject: Re: [Roll] dinner consensus on trickle-mcast and multicast-scopes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 15:02:30 -0000 On Nov 8, 2013, at 2:44 PM 11/8/13, Michael Richardson = wrote: >=20 > (I didn't have time to write a shorter note) > (Resending because I got the 6man list address wrong. Wish there was = an alias) >=20 > glossary for 6man readers: > RPL =3D ROLL RFC6550 mesh-over routing protocol. > MPL =3D ROLL draft-ietf-trickle-mcast multicast distribution > protocol. >=20 > This email is a bit long, but represents what I believe was the > consensus that was arrived at by a number of ROLL WG ID authors, some > Zigbee IP experts, and Ralph. This consensus was arrived at slowly > over Tuesday night and Wednesday, and was brought to you by the = letters > B and I. =20 >=20 > I will start with the executive summary: >=20 > 1) there are some minor tweaks necessary to trickle-mcast to make > it consistent with multicast-scopes, and to indicate that=20 > encapsulation in scopes 4 and 5 are appropriate for some use cases Thanks, Michael, for writing up the discussion that led to the = conclusions in your executive summary. Here is my summary of what needs to be changed in = draft-ietf-trickle-mcast: In section 4.1: OLD: By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW: By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.ietf-6man-multicast-scopes]. When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. Admin-Local scope (scop value 4) and Site-Local scope (scop value 5) can also be used with MPL in deployments that use administratively defined scopes that cover, for example, multiple subnets based on different underlying network technologies. where "the IP-over-IEEE802.15.4 definition" is text to be published = elsewhere (as determined by the 6man WG) as an update to RFC 4291 that = defines scop 3 for IEEE802.15.4 mesh networks. > 2) that the text in multicast-scopes that speaks of "administratively > defined" is confusing to many, and a suggestion on different text > will be posted in a reply to this email. To be precise, RFC 4291 and (in updating RFC 4291) both refer to = "administratively configured" rather than "administratively defined". = RFC 4007 refers to "zones [...] defined and configured by network = administrators". If there is consensus in the 6man WG that = "administratively configured" and the text from RFC 4007 needs to be = clarified, the clarification should apply to RFC 4291 and RFC 4007. = That clarification could be included in = draft-ietf-6man-multicast-scopes, as part of that document's updates to = RFC 4291 and RFC 4007. > [...] > -- > Michael Richardson > -on the road- - Ralph From trac+roll@trac.tools.ietf.org Sun Nov 10 08:04:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDD11E810D for ; Sun, 10 Nov 2013 08:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI99n0bqhS3K for ; Sun, 10 Nov 2013 08:04:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AC46611E8109 for ; Sun, 10 Nov 2013 08:04:39 -0800 (PST) Received: from localhost ([127.0.0.1]:56410 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VfXUy-0003jr-SE; Sun, 10 Nov 2013 17:04:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 10 Nov 2013 16:04:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/132#comment:16 Message-ID: <082.5862b1f760749ce855993f0e39d94111@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:04:41 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08339.html From: Kerry Lynn Date: Fri, 8 Nov 2013 18:25:08 -0800 Michael, Thank you for transcribing the Scopes Trial. I have added some comments below. On Fri, Nov 8, 2013 at 12:44 PM, Michael Richardson wrote: > …. > 1) there are some minor tweaks necessary to trickle-mcast to make > it consistent with multicast-scopes, and to indicate that > encapsulation in scopes 4 and 5 are appropriate for some use cases > Please also consider adding encapsulation of data in scope 2 messages so that MPL can be used in environments where scopes 3 - 5 are not defined. >... > Trickle-mcast must use/define scope 3 in order to get traffic to flow > across the entire RPL LLN (mesh-over). Can we limit this to "must use"? It is for draft-ietf-6man-multicast- scopes to define scope 3. > ... > RPL, however, can and does run over many different link types, and there > are existing deployed systems that have mixes of > 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the > technologies even alternating on a hop by hop basis. Both Zigbee IP, > metering and home systems need to span multiple technologies for > multicast, and Zigbee IP SEP 2 specifies using multicast to do service > discovering using mDNS. SEP2.0 is now IEEE 2030.5 >... > The understanding of "administratively configured" for many people > implies truck rolls, or ssh logins or router CLI commands. It was > only when this assumption was clearly articulated that the origin of the > conflict became clear to all parties. > The paragraph above from RFC 4291 continues: from physical connectivity or other, non-multicast-related configuration. So draft-ietf-6man-multicast-scopes may require some adjustments to *allow* automatic determination of boundaries of scope >= 4 based on non-multicast-related configuration. >The new understanding is that "administratively configured" is not > limited to the things that a human did it, but rather includes any > processes or operations that a human (including an IETF document) might > cause. The intent of multicast-scopes is not to limit ways that > scopes 4+ can be determined, but to clarify that scopes <=3 are *not* > intended to be defined by a physical (or physical-like) topologies. I think you mean that boundaries for scopes <= 3 *are* automatically derived from some physical connectivity relation whereas for scopes >= 4 they are not? > To put it another way, a human, looking at some non-virtualized > equipement likely can determine the extent of scope 1,2,3 even if there > is no power connected. > > The conclusion was that the group reached was that scope 3 can be > defined on a per-technology basis, and in wireless links such as > the 802.15.4 PANID. Where exactly to define this is still an open > question, but we did conclude that the place is *not* in trickle-mcast. > We are undecided if we need another worlds-shortest-RFC on 805.15.4 > (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but > another RFC is preferred by most. (Perhaps; all) > > In another place, to be determined, possibly in applicability > statements, or possibly in an application specific document > (e.g. something like "mdns-over-lln"), a process by which a scope 4 > multicast boundary could be defined to be something like the set of all > interfaces which are in at least one DODAG. > Just to summarize to this point, boundaries of scopes >= 4 may be determined by configuration under certain circumstances. However, the constraints imposed by RFC 4007 cannot be violated. So the definition example above is only applicable if the DODAG completely contains any and all scope 3 zones that fall within its borders. In situations where multiple DODAGs are defined over a connected topology satisfying the scope 3 definition, a scope 4 boundary cannot be determined by the DODAG definition. Also, once defined, the zone boundary is the same for all applications using that multicast scope. >... > This implies that LLNs will be using scope 5 to do mDNS resolution, and > that this packet will be carried through the LLNs various links > encapsulated into a scope 3 packet. This behavior has been specified by SEP2 based on an expired experimental draft. It is beyond unlikely that dnssd WG will adopt this approach. Note that homenet would have to adopt some multicast routing protocol in order to forward scope 5 multicast if there are multiple non-LLN links. >While it is likely that dnssd will > not solve the multi-subnet problem using straight multicast, but rather > using a proxy mechanism, use of scope 5 is agnostic to exactly how this > would be done. > A mote that wishes to resolve only within the LLN may use scope 3 or 4, > while one that wants to possibly find things in any place of the home > will use scope 5. This raises an interesting question from the application perspective. As I mentioned at the mic today in dnssd, RFC 6762 says: Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). draft-lynn-homenet-site-mdns took the same approach and designated ".site." as a special domain to signal the application's intent that the query should be delivered to the site-local zone FF05::FB. This is the draft that helped precipitate the earlier gTLD discussion with ICANN that was referred to in dnssd today. We may need a more general mechanism for applications that use Variable Scope Multicast Addresses to signal the desired scope to the lower layer(s) (or perhaps always default to the largest locally defined scope?) -K- ------------------------------------------------------------------------------------------------------------------- Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08340.html From: Ralph Droms Date: Sun, 10 Nov 2013 09:02:26 -0600 On Nov 8, 2013, at 2:44 PM 11/8/13, Michael Richardson wrote: > > ... > I will start with the executive summary: > > 1) there are some minor tweaks necessary to trickle-mcast to make > it consistent with multicast-scopes, and to indicate that > encapsulation in scopes 4 and 5 are appropriate for some use cases Thanks, Michael, for writing up the discussion that led to the conclusions in your executive summary. Here is my summary of what needs to be changed in draft-ietf-trickle- mcast: In section 4.1: OLD: By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW: By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.ietf-6man-multicast-scopes]. When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. Admin-Local scope (scop value 4) and Site-Local scope (scop value 5) can also be used with MPL in deployments that use administratively defined scopes that cover, for example, multiple subnets based on different underlying network technologies. where "the IP-over-IEEE802.15.4 definition" is text to be published elsewhere (as determined by the 6man WG) as an update to RFC 4291 that defines scop 3 for IEEE802.15.4 mesh networks. > 2) that the text in multicast-scopes that speaks of "administratively > defined" is confusing to many, and a suggestion on different text > will be posted in a reply to this email. To be precise, RFC 4291 and (in updating RFC 4291) both refer to "administratively configured" rather than "administratively defined". RFC 4007 refers to "zones [...] defined and configured by network administrators". If there is consensus in the 6man WG that "administratively configured" and the text from RFC 4007 needs to be clarified, the clarification should apply to RFC 4291 and RFC 4007. That clarification could be included in draft-ietf-6man-multicast-scopes, as part of that document's updates to RFC 4291 and RFC 4007. > [...] - Ralph -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From rdroms@cisco.com Tue Nov 12 06:33:07 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B7411E8178; Tue, 12 Nov 2013 06:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8-hbxWyztmC; Tue, 12 Nov 2013 06:33:02 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 502D011E815C; Tue, 12 Nov 2013 06:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1384266779; x=1385476379; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=A46QiSZP420ddItdQ9EDUeAuKSoQyJsp6IhPI3VGwaY=; b=ME5tTeo/ID8NVST+0ZYojvcE42wY/WOTP7i+kW1vZ4ibP0m0TJbcN1K6 StwEsiMBUCDL6KYiN+JL5X53zuQyuqWPp/Xrgvu+J5zX1v6I71CRY9Phx G3SRoI+3WdHFp9aXdqtC+MCVaC8JavMMqBDZcxmTsOxD3pmpXmR3bKACn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAEA7glKtJV2a/2dsb2JhbABZgwc4TQa/G4EnFnSCJQEBAQMBOj0CBQsCARkDAQIfEDIbAggCBA4FCYdyBggFviWPXw2DGoERA5gPgS+QW4Mmgio X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283693320" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 12 Nov 2013 14:32:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACEWwP3001753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 14:32:58 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.227]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 08:32:58 -0600 From: "Ralph Droms (rdroms)" To: "ipv6@ietf.org IPv6 List" Thread-Topic: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO36llWVU3mHovmE25ODDEakEb8g== Date: Tue, 12 Nov 2013 14:32:56 +0000 Message-ID: <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <5FA0A35C0A2B1547AA8EC354942CD507@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org> Subject: [Roll] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2013 14:33:07 -0000 This revision adds the definition of "scop 3" for IEEE 802.15.4 networks: 4. Definition of Realm-Local Scope for IEEE 802.15.4 When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. I've cross-posted to 6lo to get review and comment from that WG. - Ralph Begin forwarded message: > From: > Subject: New Version Notification for draft-ietf-6man-multicast-scopes-02= .txt > Date: November 12, 2013 8:16:26 AM EST > To: Ralph Droms >=20 >=20 > A new version of I-D, draft-ietf-6man-multicast-scopes-02.txt > has been successfully submitted by Ralph Droms and posted to the > IETF repository. >=20 > Filename: draft-ietf-6man-multicast-scopes > Revision: 02 > Title: IPv6 Multicast Address Scopes > Creation date: 2013-11-11 > Group: 6man > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-mult= icast-scopes-02.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-6man-multicas= t-scopes > Htmlized: http://tools.ietf.org/html/draft-ietf-6man-multicast-sco= pes-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-multi= cast-scopes-02 >=20 > Abstract: > This document updates the definitions of IPv6 multicast scopes. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From pthubert@cisco.com Tue Nov 12 14:01:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5976211E810B; Tue, 12 Nov 2013 14:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4cq1Pk5c4Op; Tue, 12 Nov 2013 14:00:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0D49E11E80E6; Tue, 12 Nov 2013 14:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2657; q=dns/txt; s=iport; t=1384293656; x=1385503256; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ImdI0lkcTaHCqmJ01BBOlowFIX4D5VbdbjjSuRIThuY=; b=OBWVAv7cQN+tleyVWnVOPiEevfPw3yaGpsMtAbhQ2NFJzzug2LioM2PS iMINXYrBL1Vf1MLsPw1DZtl8YJEHWxYKzZidz90wpqP6rQk4V6Jm6RlG0 FaU5dn1bXjsycmSFobaMsO5mXRwTN8yfcm/JNnCXikKE9LL897GTthO9G I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAL2jglKtJV2Y/2dsb2JhbABagwc4TQa/JIEqFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEDAQEBCxQJBycLFAkIAgQBDQUIAYdyBggFvzGOJ4EHMQcGgxqBEQOZPpBbgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="scan'208";a="284015442" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 12 Nov 2013 22:00:55 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACM0te5003374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 22:00:55 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 16:00:55 -0600 From: "Pascal Thubert (pthubert)" To: "Ralph Droms (rdroms)" , "ipv6@ietf.org IPv6 List" Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO36llWVU3mHovmE25ODDEakEb8poiEW4Q Date: Tue, 12 Nov 2013 22:00:54 +0000 Deferred-Delivery: Tue, 12 Nov 2013 21:32:00 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> In-Reply-To: <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2013 22:01:02 -0000 Hello Ralph: http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not se= em to contains the section you're inlining. The only diff I found was -spec= ific going -local. As we are at it, would we be ahead of ourselves if that the draft also spec= ifies that a collection of RPL DODAGs of a same instance federated over an = isolated backbone (such as a VLAN) in an 04 ?. If I may add, there is kind of an habit that scopes are nested. Seems that = we are going away from that assumption and maybe it would be good to have a= sentence saying that? Cheers, Pascal -----Original Message----- From: 6lo-bounces@ietf.org [mailto:6lo-bounces@ietf.org] On Behalf Of Ralph= Droms (rdroms) Sent: mardi 12 novembre 2013 08:33 To: ipv6@ietf.org IPv6 List Cc: Routing Lossy networks Over Low power and; 6lo@ietf.org Subject: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-= scopes-02.txt This revision adds the definition of "scop 3" for IEEE 802.15.4 networks: 4. Definition of Realm-Local Scope for IEEE 802.15.4 When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. I've cross-posted to 6lo to get review and comment from that WG. - Ralph Begin forwarded message: > From: > Subject: New Version Notification for=20 > draft-ietf-6man-multicast-scopes-02.txt > Date: November 12, 2013 8:16:26 AM EST > To: Ralph Droms >=20 >=20 > A new version of I-D, draft-ietf-6man-multicast-scopes-02.txt > has been successfully submitted by Ralph Droms and posted to the IETF=20 > repository. >=20 > Filename: draft-ietf-6man-multicast-scopes > Revision: 02 > Title: IPv6 Multicast Address Scopes > Creation date: 2013-11-11 > Group: 6man > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-mult= icast-scopes-02.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-6man-multicas= t-scopes > Htmlized: http://tools.ietf.org/html/draft-ietf-6man-multicast-sco= pes-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-multi= cast-scopes-02 >=20 > Abstract: > This document updates the definitions of IPv6 multicast scopes. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo From rdroms@cisco.com Tue Nov 12 14:04:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C321E8098; Tue, 12 Nov 2013 14:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ap8gRWWPZVs; Tue, 12 Nov 2013 14:04:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8268B11E810C; Tue, 12 Nov 2013 14:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3162; q=dns/txt; s=iport; t=1384293864; x=1385503464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KohhcpFOEN3ARb3kwlaA96ejNvAbM0vsJxcGVYOKyLU=; b=YxmWlEXdj4fEwlDIiYPGc6GWatzPnfuCdqKWb3xP6tjT8AMRYR/etLpt iFYZgLCtOS8QpbzY2KJCAXNv+Uhd2tmdBKgPgQdOpYKv2CI0tD1Ex7zaP qeIRvjYAotkcaiT3jvKl0qAWpUdMX47lFLLcA/AZzEMg3wNnvk4w6u7Pc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAK2kglKtJV2Y/2dsb2JhbABagwc4RwYGvySBKhZ0giUBAQEDAQEBATc0CQIFBwQCAQgRAwEBAR8JBycLFAkIAgQOBQmHcgYIBb82jieBBTMHBoMagREDmA+BL5BbgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="scan'208";a="284016763" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 12 Nov 2013 22:04:24 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACM4N7r007356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 22:04:23 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.227]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 16:04:23 -0600 From: "Ralph Droms (rdroms)" To: "Pascal Thubert (pthubert)" Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO36llWVU3mHovmE25ODDEakEb8poiEW4QgAB6HQA= Date: Tue, 12 Nov 2013 22:04:22 +0000 Message-ID: <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <68CD4485231E4E4B8B4F2A4E26E0B56E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "ipv6@ietf.org IPv6 List" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2013 22:04:29 -0000 The document has been accepted as a WG work item. Check out http://www.iet= f.org/internet-drafts/draft-ietf-6man-multicast-scopes-02.txt On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: > Hello Ralph: >=20 > http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not = seem to contains the section you're inlining. The only diff I found was -sp= ecific going -local. > As we are at it, would we be ahead of ourselves if that the draft also sp= ecifies that a collection of RPL DODAGs of a same instance federated over a= n isolated backbone (such as a VLAN) in an 04 ?. >=20 > If I may add, there is kind of an habit that scopes are nested. Seems tha= t we are going away from that assumption and maybe it would be good to have= a sentence saying that? >=20 > Cheers, > Pascal >=20 > -----Original Message----- > From: 6lo-bounces@ietf.org [mailto:6lo-bounces@ietf.org] On Behalf Of Ral= ph Droms (rdroms) > Sent: mardi 12 novembre 2013 08:33 > To: ipv6@ietf.org IPv6 List > Cc: Routing Lossy networks Over Low power and; 6lo@ietf.org > Subject: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicas= t-scopes-02.txt >=20 > This revision adds the definition of "scop 3" for IEEE 802.15.4 networks: >=20 > 4. Definition of Realm-Local Scope for IEEE 802.15.4 >=20 > When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to > include all interfaces sharing a PAN ID. >=20 > I've cross-posted to 6lo to get review and comment from that WG. >=20 > - Ralph >=20 >=20 > Begin forwarded message: >=20 >> From: >> Subject: New Version Notification for=20 >> draft-ietf-6man-multicast-scopes-02.txt >> Date: November 12, 2013 8:16:26 AM EST >> To: Ralph Droms >>=20 >>=20 >> A new version of I-D, draft-ietf-6man-multicast-scopes-02.txt >> has been successfully submitted by Ralph Droms and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-ietf-6man-multicast-scopes >> Revision: 02 >> Title: IPv6 Multicast Address Scopes >> Creation date: 2013-11-11 >> Group: 6man >> Number of pages: 5 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-mul= ticast-scopes-02.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-6man-multica= st-scopes >> Htmlized: http://tools.ietf.org/html/draft-ietf-6man-multicast-sc= opes-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-mult= icast-scopes-02 >>=20 >> Abstract: >> This document updates the definitions of IPv6 multicast scopes. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > 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 brian@innovationslab.net Wed Nov 13 05:21:55 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2284221E8135; Wed, 13 Nov 2013 05:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTyVPhKRqLlZ; Wed, 13 Nov 2013 05:21:43 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BEA5A21E8117; Wed, 13 Nov 2013 05:21:43 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 408C788108; Wed, 13 Nov 2013 05:21:43 -0800 (PST) Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 927B9136812E; Wed, 13 Nov 2013 05:21:40 -0800 (PST) Message-ID: <52837CE4.60304@innovationslab.net> Date: Wed, 13 Nov 2013 08:21:40 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> In-Reply-To: <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uBgo3DoqdwFTkShpEAgpPlmfCXRBXSnSL" Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" , "Ralph Droms \(rdroms\)" Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 13:21:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uBgo3DoqdwFTkShpEAgpPlmfCXRBXSnSL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: > The document has been accepted as a WG work item. Check out http://www= =2Eietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-02.txt >=20 >=20 > On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >=20 >> Hello Ralph: >> >> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does n= ot seem to contains the section you're inlining. The only diff I found wa= s -specific going -local. >> As we are at it, would we be ahead of ourselves if that the draft also= specifies that a collection of RPL DODAGs of a same instance federated o= ver an isolated backbone (such as a VLAN) in an 04 ?. >> >> If I may add, there is kind of an habit that scopes are nested. Seems = that we are going away from that assumption and maybe it would be good to= have a sentence saying that? >> Scopes are still nested. See RFC 4007. Are you saying that this document is changing that? Regards, Brian --uBgo3DoqdwFTkShpEAgpPlmfCXRBXSnSL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSg3zlAAoJEBOZRqCi7goq8L0H/3MG99QYPQ1U4uRdLgm7lW6H mystTk7HcZXJzrJIPKMEJQ5FGc7wYrd7FhC++651iCGT41TKJu0XeJqWNynadda4 4G5I2gol5Sj1YTvPg4PDZyRO/pX7nEsrTqcExlx6tA95PnkCyybetA6QDpBNFM6V S2jJVZXxsXuJSD7qDZh7pGY/Fz0XK41hDdYhhU3Sq8XFpQkfNfDxAR/0jN22wvSD 8OB9lgiyG7lXFHE02vp2V+wF0KKr+whuMSuix9jz/hp5/DtYKt/yDjMxypnaDx0s muuRF/k6dVDi7SPBZaff8aQfkDXaiV9xrbbxnGssKvB5so81lpmu0ZNNMh/Z4NI= =LsmR -----END PGP SIGNATURE----- --uBgo3DoqdwFTkShpEAgpPlmfCXRBXSnSL-- From pthubert@cisco.com Wed Nov 13 21:52:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC5121E81BC; Wed, 13 Nov 2013 21:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQzJn1gBW4Li; Wed, 13 Nov 2013 21:51:57 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E755221E81B5; Wed, 13 Nov 2013 21:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1802; q=dns/txt; s=iport; t=1384408317; x=1385617917; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r7NaOU4jtZLwDGWirI+gPZOzrxthk/oChNOmmBa/TFU=; b=TkNt6WxlACmaBnC1PdU5K90KzfA/hy4NVQZtmbDMwKqZqDUSTzke4Hd1 7jHCfLpJLcMWMRmh89KLIitnNsOYuokMLZ/z6mqnKvc17lD6krsZ/ehsO 1DloXX0JgZn0H0hb1JLQ4mDFnjVqAXznwf8opRJdY3WctVjhlCGkIeIUw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFABtkhFKtJXG//2dsb2JhbABZgwc4U78rgSkWdIIlAQEBBDo9AgwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIAYd4Db9OjieBBzEHBoMagREDmT+QXYFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,697,1378857600"; d="scan'208";a="284611990" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2013 05:51:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAE5pk99007358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 05:51:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 23:51:46 -0600 From: "Pascal Thubert (pthubert)" To: Brian Haberman Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO4HNJWVU3mHovmE25ODDEakEb8pokOE8Q Date: Thu, 14 Nov 2013 05:51:46 +0000 Deferred-Delivery: Thu, 14 Nov 2013 05:51:00 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> In-Reply-To: <52837CE4.60304@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" , "Ralph Droms \(rdroms\)" Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 05:52:02 -0000 Hello Brian: 03 seems to derive from autonomic behavior, whereas 04 derives from admin. = I do not see there a direct indication that 03 is contained in 04 though in= the deployments I have in mind it would certainly be the case. Whether we = want to enforce or on the contrary do not want to enforce the nesting is pr= obably something we want to clarify. Cheers Pascal -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: mercredi 13 novembre 2013 07:22 To: Pascal Thubert (pthubert) Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6@i= etf.org IPv6 List; 6lo@ietf.org Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multic= ast-scopes-02.txt Pascal, On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: > The document has been accepted as a WG work item. Check out=20 > http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 > 2.txt >=20 >=20 > On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >=20 >> Hello Ralph: >> >> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not= seem to contains the section you're inlining. The only diff I found was -s= pecific going -local. >> As we are at it, would we be ahead of ourselves if that the draft also s= pecifies that a collection of RPL DODAGs of a same instance federated over = an isolated backbone (such as a VLAN) in an 04 ?. >> >> If I may add, there is kind of an habit that scopes are nested. Seems th= at we are going away from that assumption and maybe it would be good to hav= e a sentence saying that? >> Scopes are still nested. See RFC 4007. Are you saying that this document = is changing that? Regards, Brian From tjc@ecs.soton.ac.uk Thu Nov 14 01:21:25 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E445821E812C; Thu, 14 Nov 2013 01:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6bVDH-kd7te; Thu, 14 Nov 2013 01:21:23 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0005E21F9D19; Thu, 14 Nov 2013 01:21:12 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAE9L7sX020089; Thu, 14 Nov 2013 09:21:07 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAE9L7sX020089 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1384420867; bh=kRMR4jxHbUqtHjEO9N4nWSCrlO8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=g0cLqsqkzYEAPK0hpVGg1EyzrPdcK5smmlEte8oTSsu+BqUGwWsst/lXlOlrsslY8 iIwv7vaAqY90G1wajHUYDYNp5xFKlADjzOZJY4vZJbZvcSNRo66XqSOPR9KO24/oY5 IY1YUbEYoxDwL37lC+hF35r1k9OGB876mxoxco+U= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pAD9L70959659825CR ret-id none; Thu, 14 Nov 2013 09:21:07 +0000 Received: from [192.168.0.26] (5ad35a35.bb.sky.com [90.211.90.53] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAE9KdkI017596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 09:20:40 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Tim Chown In-Reply-To: Date: Thu, 14 Nov 2013 09:20:39 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1822) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pAD9L7095965982500; tid=pAD9L70959659825CR; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rAE9L7sX020089 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Brian Haberman , "Ralph Droms \(rdroms\)" , "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 09:21:25 -0000 On 14 Nov 2013, at 05:51, Pascal Thubert (pthubert) = wrote: > Hello Brian: >=20 > 03 seems to derive from autonomic behavior, whereas 04 derives from = admin. I do not see there a direct indication that 03 is contained in 04 = though in the deployments I have in mind it would certainly be the case. = Whether we want to enforce or on the contrary do not want to enforce the = nesting is probably something we want to clarify. Are there use cases documented somewhere in a 6lo or 6lo-related draft? I'm interested as we're updating the homenet text about multicast = scopes. We have agreed some text in principle with Brian for that, but = it's interesting because we may, indeed are likely to, have 6lo networks = within future IPv6 home networks. Tim > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: mercredi 13 novembre 2013 07:22 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; = ipv6@ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for = draft-ietf-6man-multicast-scopes-02.txt >=20 > Pascal, >=20 > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >> The document has been accepted as a WG work item. Check out=20 >> = http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 >> 2.txt >>=20 >>=20 >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" = wrote: >>=20 >>> Hello Ralph: >>>=20 >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does = not seem to contains the section you're inlining. The only diff I found = was -specific going -local. >>> As we are at it, would we be ahead of ourselves if that the draft = also specifies that a collection of RPL DODAGs of a same instance = federated over an isolated backbone (such as a VLAN) in an 04 ?. >>>=20 >>> If I may add, there is kind of an habit that scopes are nested. = Seems that we are going away from that assumption and maybe it would be = good to have a sentence saying that? >>>=20 >=20 > Scopes are still nested. See RFC 4007. Are you saying that this = document is changing that? >=20 > Regards, > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian@innovationslab.net Thu Nov 14 05:22:51 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F721E80A9; Thu, 14 Nov 2013 05:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhCtJd2dTuPJ; Thu, 14 Nov 2013 05:22:46 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7A21E8090; Thu, 14 Nov 2013 05:22:46 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 480E68809F; Thu, 14 Nov 2013 05:22:46 -0800 (PST) Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AFC4B13680F2; Thu, 14 Nov 2013 05:22:45 -0800 (PST) Message-ID: <5284CE9E.4060001@innovationslab.net> Date: Thu, 14 Nov 2013 08:22:38 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rSJEo6mjTaftRL8RKGCuKIOvGibl3dlHQ" Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" , "Ralph Droms \(rdroms\)" Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 13:22:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rSJEo6mjTaftRL8RKGCuKIOvGibl3dlHQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, Scope 3 being contained within scope4 is mandated by RFC 4007. Specifically, RFC 4007 describes the following properties: o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.) o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. o Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property. I don't see anything in this draft that would change those properties. Regards, Brian On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote: > Hello Brian: >=20 > 03 seems to derive from autonomic behavior, whereas 04 derives from adm= in. I do not see there a direct indication that 03 is contained in 04 tho= ugh in the deployments I have in mind it would certainly be the case. Whe= ther we want to enforce or on the contrary do not want to enforce the nes= ting is probably something we want to clarify. >=20 > Cheers >=20 > Pascal >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: mercredi 13 novembre 2013 07:22 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ip= v6@ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-mu= lticast-scopes-02.txt >=20 > Pascal, >=20 > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >> The document has been accepted as a WG work item. Check out=20 >> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0= >> 2.txt >> >> >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >> >>> Hello Ralph: >>> >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does = not seem to contains the section you're inlining. The only diff I found w= as -specific going -local. >>> As we are at it, would we be ahead of ourselves if that the draft als= o specifies that a collection of RPL DODAGs of a same instance federated = over an isolated backbone (such as a VLAN) in an 04 ?. >>> >>> If I may add, there is kind of an habit that scopes are nested. Seems= that we are going away from that assumption and maybe it would be good t= o have a sentence saying that? >>> >=20 > Scopes are still nested. See RFC 4007. Are you saying that this docum= ent is changing that? >=20 > Regards, > Brian >=20 --rSJEo6mjTaftRL8RKGCuKIOvGibl3dlHQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShM6jAAoJEBOZRqCi7goqxLQH/j65Nu1jJOuRjErBYOp0bJJg zV27Tx9v4C4bTElHue8gAHtjY+xoR3MdExFaEu4izRbTxvAPC+tXXbxJmIGnrL16 RZpcbCF/pdG1g/utOpZmZA8UqlmPaum+RhbU05lUwTEBYviIU+xdUL+MVIL/aNaa KWyfwPMny5tTZjKVl72t1JMmjuVTBpq8AS7RMzoRnc9lTbBCyVGdrdwPi2AbX7YQ x3NFj+jQkvnT3xBzXhCvP8/pnORVgz0aF53r2+ETx93vMLq54+gvt9CGaP16scVG qtu+drkrl9maRrCuKyMVTHpy2xYaRlXOpz6mECU1E+aH+ftoYlRhSLfhYtUi1kc= =UNRa -----END PGP SIGNATURE----- --rSJEo6mjTaftRL8RKGCuKIOvGibl3dlHQ-- From pthubert@cisco.com Thu Nov 14 15:52:36 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E794611E8159; Thu, 14 Nov 2013 15:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCEib7-x3DMh; Thu, 14 Nov 2013 15:52:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33221E80E2; Thu, 14 Nov 2013 15:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3682; q=dns/txt; s=iport; t=1384473147; x=1385682747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vyzuw+lEYJ9etDV5M0FmxqXCnnbtQ4nyjYLgV02S98I=; b=iPEY83wo6xkIDkBSOuE/WKWM/IxFnFJZHKY6I/1GzOxK0z7DBf0QIJkA YSR0QxxLBunuQZqymxJumnkYkT8BG1PxtfljU5aIY8Q/KUv/pSpnl0pNg wpnljc+yCXq4lYXWlur4FvfsfIBoFqEBMSpMXIzSXjgJ+of12/9NA4B9h c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALlhhVKtJXHA/2dsb2JhbABaDoJ5OFO/HoEgFnSCJQEBAQMBAQEBNzQJAgUHBAIBCA4DAQMBAQEKFAkHJwsUAwYIAgQBDQUIAYdyBg3AfY4ngQcxBwaDGoERA5k/kF2Ban8/gio X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208";a="285024770" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2013 23:52:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAENqQqn004842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 23:52:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 17:52:26 -0600 From: "Pascal Thubert (pthubert)" To: Tim Chown , Brian Haberman Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO4RreZ/MxlpffAEipYTllbECB/ZolWRhg Date: Thu, 14 Nov 2013 23:52:25 +0000 Deferred-Delivery: Thu, 14 Nov 2013 23:50:00 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> 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.61.92.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "Ralph Droms \(rdroms\)" , "ipv6@ietf.org IPv6 List" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:52:36 -0000 Hello Tim; The 6TiSCH architecture documents a use case whereby a large (RPL based) LL= N is federated by an higher speed backbone such as Ethernet that mostly spa= ns the LLN. The LLN is partitioned by RPL in multiple DODAGs, and the roots of the DODA= Gs connect to the backbone to provide end to end connectivity over the form= ed multilink subnet. The LLN probably forms a single RPL Domain though we have not discussed tha= t yet. Discussing with Ralph, I understand that the RPL domain is 03 and th= e whole multilink subnet is 04. It results that we cannot address a single RPL instance or a single DODAG a= s a scope. The intersection with 802.15.4 PAN-ID still troubles me a bit bu= t that's another thread.=20 Cheers, Pascal -----Original Message----- From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]=20 Sent: jeudi 14 novembre 2013 03:21 To: Pascal Thubert (pthubert) Cc: Brian Haberman; Routing Lossy networks Over Low power and; 6lo@ietf.org= ; ipv6@ietf.org IPv6 List; Ralph Droms (rdroms) Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multic= ast-scopes-02.txt On 14 Nov 2013, at 05:51, Pascal Thubert (pthubert) wr= ote: > Hello Brian: >=20 > 03 seems to derive from autonomic behavior, whereas 04 derives from admin= . I do not see there a direct indication that 03 is contained in 04 though = in the deployments I have in mind it would certainly be the case. Whether w= e want to enforce or on the contrary do not want to enforce the nesting is = probably something we want to clarify. Are there use cases documented somewhere in a 6lo or 6lo-related draft? I'm interested as we're updating the homenet text about multicast scopes. = We have agreed some text in principle with Brian for that, but it's interes= ting because we may, indeed are likely to, have 6lo networks within future = IPv6 home networks. Tim > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: mercredi 13 novembre 2013 07:22 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6= @ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-mult= icast-scopes-02.txt >=20 > Pascal, >=20 > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >> The document has been accepted as a WG work item. Check out=20 >> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 >> 2.txt >>=20 >>=20 >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >>=20 >>> Hello Ralph: >>>=20 >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does no= t seem to contains the section you're inlining. The only diff I found was -= specific going -local. >>> As we are at it, would we be ahead of ourselves if that the draft also = specifies that a collection of RPL DODAGs of a same instance federated over= an isolated backbone (such as a VLAN) in an 04 ?. >>>=20 >>> If I may add, there is kind of an habit that scopes are nested. Seems t= hat we are going away from that assumption and maybe it would be good to ha= ve a sentence saying that? >>>=20 >=20 > Scopes are still nested. See RFC 4007. Are you saying that this documen= t is changing that? >=20 > Regards, > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pthubert@cisco.com Thu Nov 14 15:58:44 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D4B11E814D; Thu, 14 Nov 2013 15:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuuV-9VmLziy; Thu, 14 Nov 2013 15:58:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8105E11E8149; Thu, 14 Nov 2013 15:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4214; q=dns/txt; s=iport; t=1384473517; x=1385683117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HA69uJVdEGHFIe3twx2KyKTPKqRJxRCBJVwzzzLDczY=; b=fSOQGXkfxL2znTsR5YScctSIAwPu28O0KtZ10BDiAqygecUFR+UVhEko xL9ynO5Et+74Z+XBKD43dosKvz+2EFvCES+dUdcWG20rameouOPvAMH9g G0ALfqWl8CmNcVLALoDS7wvuYwDve+wdCLcH7IwC72Jg99E9EsZOU1BYV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAGBjhVKtJXG//2dsb2JhbABagwc4U78egSAWdIIlAQEBBDo9AgwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIAYd4DcB+jieBBzEHBoMagREDmT+QXYFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208";a="282030612" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 23:58:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAENwaCb020355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 23:58:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 17:58:36 -0600 From: "Pascal Thubert (pthubert)" To: Brian Haberman Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO4TyWZ/MxlpffAEipYTllbECB/ZolX+Vg Date: Thu, 14 Nov 2013 23:58:35 +0000 Deferred-Delivery: Thu, 14 Nov 2013 23:58:00 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <5284CE9E.4060001@innovationslab.net> In-Reply-To: <5284CE9E.4060001@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" , "Ralph Droms \(rdroms\)" Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:58:44 -0000 I mostly agree Brian; It's a bit touchy because in 802.15.4 a PAN ID is configured administrative= ly and could lead to an 04 interpretation.=20 A RPL domain (that is an 03) that may span multiple PAN IDs. If PAN ID was = 04 that would have been reverse nesting.=20 The draft now clarifies that this is also an 03 but now we still have a pot= ential conflict between a RPL domain and a PAN. Would a RPL domain be constrained by the PAN ID?=20 In this case that would imply that all the LLN must always be a single PAN = and constrain the size of a subnet to 64K. There is a lot behind the sentence "care must be taken in the definition of= those larger scopes to ensure that inclusion constraint is met."=20 Cheers; Pascal -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: jeudi 14 novembre 2013 07:23 To: Pascal Thubert (pthubert) Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6@i= etf.org IPv6 List; 6lo@ietf.org Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multic= ast-scopes-02.txt Pascal, Scope 3 being contained within scope4 is mandated by RFC 4007. Specifically, RFC 4007 describes the following properties: o Zone boundaries cut through nodes, not links. (Note that the global zon= e has no boundary, and the boundary of an interface-local zone encloses jus= t a single interface.) o Zones of the same scope cannot overlap; i.e., they can have no links or = interfaces in common. o A zone of a given scope (less than global) falls completely within zones= of larger scope. That is, a smaller scope zone cannot include more topolo= gy than would any larger scope zone with which it shares any links or inter= faces. o Each zone is required to be "convex" from a routing perspective; i.e., p= ackets sent from one interface to any other in the same zone are never rout= ed outside the zone. Note, however, that if a zone contains a tunneled lin= k (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the t= unnel can be located outside the zone without breaking the convexity proper= ty. I don't see anything in this draft that would change those properties. Regards, Brian On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote: > Hello Brian: >=20 > 03 seems to derive from autonomic behavior, whereas 04 derives from admin= . I do not see there a direct indication that 03 is contained in 04 though = in the deployments I have in mind it would certainly be the case. Whether w= e want to enforce or on the contrary do not want to enforce the nesting is = probably something we want to clarify. >=20 > Cheers >=20 > Pascal >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: mercredi 13 novembre 2013 07:22 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and;=20 > ipv6@ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for=20 > draft-ietf-6man-multicast-scopes-02.txt >=20 > Pascal, >=20 > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >> The document has been accepted as a WG work item. Check out >> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes- >> 0 >> 2.txt >> >> >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >> >>> Hello Ralph: >>> >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does no= t seem to contains the section you're inlining. The only diff I found was -= specific going -local. >>> As we are at it, would we be ahead of ourselves if that the draft also = specifies that a collection of RPL DODAGs of a same instance federated over= an isolated backbone (such as a VLAN) in an 04 ?. >>> >>> If I may add, there is kind of an habit that scopes are nested. Seems t= hat we are going away from that assumption and maybe it would be good to ha= ve a sentence saying that? >>> >=20 > Scopes are still nested. See RFC 4007. Are you saying that this documen= t is changing that? >=20 > Regards, > Brian >=20 From rdroms@cisco.com Thu Nov 14 16:22:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A3711E814C; Thu, 14 Nov 2013 16:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fITKXFhLJVG7; Thu, 14 Nov 2013 16:22:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C39F611E812B; Thu, 14 Nov 2013 16:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6642; q=dns/txt; s=iport; t=1384474939; x=1385684539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dYdE5otBm1R98WHLPuXZu8lX9iqZfQ7vqDpAom5fxjk=; b=J4Ti6Oz37osrtd4Kp3x+DoKkS2Icgzq63RDfrY+pOHgdjJfiNFMNXaO9 9v35fQGJCS5ftU8OgIo+i2bbFYUfz2BcuQz20XVzBU1LMZyxgKHQraB63 Z0Z9b7WKvc+OS5pnzTCUWfXRDpWi8OTEWnHljbNu9SW/fDMW5Ap+oB2jT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAINohVKtJXHA/2dsb2JhbABQCoMHOEcMvx6BIBZ0giUBAQEDAQEBATc0CQIFBwQCAQgRBAEBAR4JBycLFAkIAgQOBQmHcgYNwHeOHAuBBQgrBwaDGoERA5gQgS+QXYFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208";a="285033130" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2013 00:22:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAF0MInQ004873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 00:22:18 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.168]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 18:22:17 -0600 From: "Ralph Droms (rdroms)" To: "Pascal Thubert (pthubert)" Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO36llWVU3mHovmE25ODDEakEb8polX+VggAB22IA= Date: Fri, 15 Nov 2013 00:22:17 +0000 Message-ID: <626B6895-FE20-4139-BC07-16DB4A4D9A8B@cisco.com> References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <5284CE9E.4060001@innovationslab.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.164.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <4454DF5E0019E845813CE61E900F3CF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Haberman Brian , "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 00:22:24 -0000 On Nov 14, 2013, at 6:58 PM 11/14/13, "Pascal Thubert (pthubert)" wrote: > I mostly agree Brian; >=20 > It's a bit touchy because in 802.15.4 a PAN ID is configured administrati= vely and could lead to an 04 interpretation. I consider a PAN ID to be equivalent to an address ... both are configured = administratively but are part of the=20 >=20 > A RPL domain (that is an 03) that may span multiple PAN IDs. Pascal - RPL domains are, in my opinion, completely unrelated to MPL scopes= . RPL is only mentioned obliquely, as an example of a protocol that accomm= odates the memory constraints in highly constrained devices. So, I don't t= hink there is any reason to say "A RPL domain (that is an 03)". > If PAN ID was 04 that would have been reverse nesting.=20 > The draft now clarifies that this is also an 03 but now we still have a p= otential conflict between a RPL domain and a PAN. >=20 > Would a RPL domain be constrained by the PAN ID?=20 No ... RPL domain is independent of MPL scope. As a practical matter, a "RPL domain" is a little tricky to define, and eve= n trickier to tie into a multicast scope. There is nothing in the multicas= t address or the MPL header to tie it to a DODAG or some other RPL domain i= dentifier. In a mesh where multiple DODAGS and RPL domains may be interlea= ved, there doesn't seem to be a way to identify a MPL scope. >=20 > In this case that would imply that all the LLN must always be a single PA= N and constrain the size of a subnet to 64K. I think you're confusing the use of "scop 3" for carrying multicast traffic= via MPL across a single mesh network and the use of, e.g., "scop 4" for th= e scope of, say, mDNS for DNS-SD across a federation of subnets. I won't attempt the ASCII art here ... but here's an example scenario as I = understand it: SEP2.0 DNS-SD/mDNS queries intended to span a federation of = subnets is sent to (working from memory) FC04::FB. When delivered to an LB= R at the border of a 6LoWPAN mesh, that query would be encapsulated in FC03= :: to carry it across the mesh. Similarly, a query from= a mesh node would have an inner header with dst FC04::FB and encapsulated = by the source with outer header dst FC03::; then the MP= L outer header would be taken off by the LBR and inner DNS-SD/mDNS query wo= uld be forwarded out any other interfaces based on the dst FC04::FB. > There is a lot behind the sentence "care must be taken in the definition = of those larger scopes to ensure that inclusion constraint is met." OK, but I don't think draft-ietf-6man-multicast-scopes contradicts RFC 4007= in any way. > Cheers; > Pascal - Ralph >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: jeudi 14 novembre 2013 07:23 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6= @ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-mult= icast-scopes-02.txt >=20 > Pascal, > Scope 3 being contained within scope4 is mandated by RFC 4007. > Specifically, RFC 4007 describes the following properties: >=20 > o Zone boundaries cut through nodes, not links. (Note that the global z= one has no boundary, and the boundary of an interface-local zone encloses j= ust a single interface.) >=20 > o Zones of the same scope cannot overlap; i.e., they can have no links o= r interfaces in common. >=20 > o A zone of a given scope (less than global) falls completely within zon= es of larger scope. That is, a smaller scope zone cannot include more topo= logy than would any larger scope zone with which it shares any links or int= erfaces. >=20 > o Each zone is required to be "convex" from a routing perspective; i.e.,= packets sent from one interface to any other in the same zone are never ro= uted outside the zone. Note, however, that if a zone contains a tunneled l= ink (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the= tunnel can be located outside the zone without breaking the convexity prop= erty. >=20 >=20 > I don't see anything in this draft that would change those properties. >=20 > Regards, > Brian >=20 > On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote: >> Hello Brian: >>=20 >> 03 seems to derive from autonomic behavior, whereas 04 derives from admi= n. I do not see there a direct indication that 03 is contained in 04 though= in the deployments I have in mind it would certainly be the case. Whether = we want to enforce or on the contrary do not want to enforce the nesting is= probably something we want to clarify. >>=20 >> Cheers >>=20 >> Pascal >>=20 >>=20 >> -----Original Message----- >> From: Brian Haberman [mailto:brian@innovationslab.net] >> Sent: mercredi 13 novembre 2013 07:22 >> To: Pascal Thubert (pthubert) >> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and;=20 >> ipv6@ietf.org IPv6 List; 6lo@ietf.org >> Subject: Re: [6lo] Fwd: New Version Notification for=20 >> draft-ietf-6man-multicast-scopes-02.txt >>=20 >> Pascal, >>=20 >> On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >>> The document has been accepted as a WG work item. Check out >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes- >>> 0 >>> 2.txt >>>=20 >>>=20 >>> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >>>=20 >>>> Hello Ralph: >>>>=20 >>>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does n= ot seem to contains the section you're inlining. The only diff I found was = -specific going -local. >>>> As we are at it, would we be ahead of ourselves if that the draft also= specifies that a collection of RPL DODAGs of a same instance federated ove= r an isolated backbone (such as a VLAN) in an 04 ?. >>>>=20 >>>> If I may add, there is kind of an habit that scopes are nested. Seems = that we are going away from that assumption and maybe it would be good to h= ave a sentence saying that? >>>>=20 >>=20 >> Scopes are still nested. See RFC 4007. Are you saying that this docume= nt is changing that? >>=20 >> Regards, >> Brian >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kerlyn2001@gmail.com Thu Nov 14 16:31:27 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D151A11E817E; Thu, 14 Nov 2013 16:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I709WkIc8l8k; Thu, 14 Nov 2013 16:31:25 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4023411E8167; Thu, 14 Nov 2013 16:31:25 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id g12so3210258oah.28 for ; Thu, 14 Nov 2013 16:31:24 -0800 (PST) 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=gDB7wKz7XqnfEqYtzk4J+xvsun1WNFXDqUcz2TrcUuE=; b=d9Fo7OVXDrF+2Dt3QIzw2chOs8Ho7oa2fSV4ng3OyQoIs9V/8FcJCxXOcRt1BM18RL hLYjvOjXGTK3VRJ8tUWxgMN8ddaorz3oXWBRhx1jEAc7506rEHdA2x/zoim0IWKikUUA I6fU3gTrOjA8c/dg38VNafcFjBu4nYXgBpT8BtZKBHPGlQXznG28G7RVwg2seVWYtzay XsASZZpje0B/0nBvQtIJde8hD8SYYiDQLj9A1tZiPTDve2FrSUeE8hFEKtLGQDpfBy97 LBr/fx/+ws2xSK67JV3PNt7Zl8KtbGl99cd/Fy/pnr9q8HMre9QE8ZKUgVh5YAWIvcfZ OkCA== MIME-Version: 1.0 X-Received: by 10.60.47.228 with SMTP id g4mr4324925oen.10.1384475484771; Thu, 14 Nov 2013 16:31:24 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Thu, 14 Nov 2013 16:31:24 -0800 (PST) In-Reply-To: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <5284CE9E.4060001@innovationslab.net> Date: Thu, 14 Nov 2013 19:31:24 -0500 X-Google-Sender-Auth: zeRzswWQdiKUsgm0qgZN5qCC0MQ Message-ID: From: Kerry Lynn To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a11c2fcf6785bd104eb2c517a Cc: Brian Haberman , "Ralph Droms \(rdroms\)" , "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 00:31:27 -0000 --001a11c2fcf6785bd104eb2c517a Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal, On Thu, Nov 14, 2013 at 6:58 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > I mostly agree Brian; > > It's a bit touchy because in 802.15.4 a PAN ID is configured > administratively and could lead to an 04 interpretation. > One could take that argument to the extreme and say that selecting SSID (802.11) or plugging into a wall socket (802.3) is an administrative act. Let's not be too literal and instead say that the "automatic" zone boundary definition applies to an existing LAN. If you think about a Link-Local zone, it is defined as a set of physically connected interfaces and the zone boundary is defined by a *lack* of forwarding (see [RFC4291] section 2.5.6). I think if there is a need for scope value 3 it is to provide classic Link-Local multicast behavior over a connected mesh. I think the definition should be independent of RPL and instead depend on some "L2 instance" definition. PAN ID works for 802.15.4 networks. A RPL domain (that is an 03) that may span multiple PAN IDs. draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based on PAN ID. The latest version makes no mention at all of RPL. If PAN ID was 04 that would have been reverse nesting. > The draft now clarifies that this is also an 03 but now we still have a > potential conflict between a RPL domain and a PAN. > > Would a RPL domain be constrained by the PAN ID? > > In this case that would imply that all the LLN must always be a single PAN > and constrain the size of a subnet to 64K. > There is a lot behind the sentence "care must be taken in the definition > of those larger scopes to ensure that inclusion constraint is met." > > I think the understanding that was reached at dinner last week is that, under certain circumstances, policy can count as "administratively configured". Thus, if a RPL instance contained several PAN IDs then the former could be used as the basis of a scop 4 zone as long as if fully enclosed the PANs (scop 3 zones). OTOH, if a given PAN contains multiple RPL instances then the latter cannot be used to define a scop 4 zone boundary because that would violate the RFC 4007 constraints that Brian enumerated. HTH, -K- Cheers; > Pascal > > > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: jeudi 14 novembre 2013 07:23 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; > ipv6@ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for > draft-ietf-6man-multicast-scopes-02.txt > > Pascal, > Scope 3 being contained within scope4 is mandated by RFC 4007. > Specifically, RFC 4007 describes the following properties: > > o Zone boundaries cut through nodes, not links. (Note that the global > zone has no boundary, and the boundary of an interface-local zone encloses > just a single interface.) > > o Zones of the same scope cannot overlap; i.e., they can have no links or > interfaces in common. > > o A zone of a given scope (less than global) falls completely within > zones of larger scope. That is, a smaller scope zone cannot include more > topology than would any larger scope zone with which it shares any links or > interfaces. > > o Each zone is required to be "convex" from a routing perspective; i.e., > packets sent from one interface to any other in the same zone are never > routed outside the zone. Note, however, that if a zone contains a tunneled > link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of > the tunnel can be located outside the zone without breaking the convexity > property. > > > I don't see anything in this draft that would change those properties. > > Regards, > Brian > > On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote: > > Hello Brian: > > > > 03 seems to derive from autonomic behavior, whereas 04 derives from > admin. I do not see there a direct indication that 03 is contained in 04 > though in the deployments I have in mind it would certainly be the case. > Whether we want to enforce or on the contrary do not want to enforce the > nesting is probably something we want to clarify. > > > > Cheers > > > > Pascal > > > > > > -----Original Message----- > > From: Brian Haberman [mailto:brian@innovationslab.net] > > Sent: mercredi 13 novembre 2013 07:22 > > To: Pascal Thubert (pthubert) > > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; > > ipv6@ietf.org IPv6 List; 6lo@ietf.org > > Subject: Re: [6lo] Fwd: New Version Notification for > > draft-ietf-6man-multicast-scopes-02.txt > > > > Pascal, > > > > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: > >> The document has been accepted as a WG work item. Check out > >> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes- > >> 0 > >> 2.txt > >> > >> > >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" < > pthubert@cisco.com> wrote: > >> > >>> Hello Ralph: > >>> > >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does > not seem to contains the section you're inlining. The only diff I found was > -specific going -local. > >>> As we are at it, would we be ahead of ourselves if that the draft also > specifies that a collection of RPL DODAGs of a same instance federated over > an isolated backbone (such as a VLAN) in an 04 ?. > >>> > >>> If I may add, there is kind of an habit that scopes are nested. Seems > that we are going away from that assumption and maybe it would be good to > have a sentence saying that? > >>> > > > > Scopes are still nested. See RFC 4007. Are you saying that this > document is changing that? > > > > Regards, > > Brian > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11c2fcf6785bd104eb2c517a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pascal,

On Thu, Nov 1= 4, 2013 at 6:58 PM, Pascal Thubert (pthubert) <pthubert@cisco.com>= wrote:
I mostly agree Br= ian;

It's a bit touchy because in 802.15.4 a PAN ID is configured administra= tively and could lead to an 04 interpretation.

One could take that argument to the extreme and say that selecting = SSID (802.11) or plugging into a wall socket
(802.3) is an administrative act.=A0 Let's not be too litera= l and instead say that the "automatic" zone boundary
definition applies to an existing LAN.=A0 If you think about a Link-Local= zone, it is defined as a set of physically
connected interfaces and the zone boundary is defined by a *lack= * of forwarding (see [RFC4291] section 2.5.6).
I think if the= re is a need for scope value 3 it is to provide classic Link-Local multicas= t behavior over a connected
mesh.=A0 I think the definition should be independent of RPL and= instead depend on some "L2 instance" definition.
P= AN ID works for 802.15.4 networks.

A RPL domain (that is an 03) that may span multiple PAN IDs.
<= div>
draft-ietf-6man-multicast-scopes-02 defines a scop 3 zon= e boundary based on PAN ID.=A0 The latest version
makes no me= ntion at all of RPL.

If PAN ID was 04 that w= ould have been reverse nesting.
The draft now clarifies that this is also an 03 but now we still have a pot= ential conflict between a RPL domain and a PAN.

Would a RPL domain be constrained by the PAN ID?

In this case that would imply that all the LLN must always be a single PAN = and constrain the size of a subnet to 64K.
There is a lot behind the sentence "care must be taken in the definiti= on of those larger scopes to ensure that inclusion constraint is met."=

I think the understand= ing that was reached at dinner last week is that, under certain circumstanc= es, policy
can count as "administratively configured".=A0 Thus= , if a RPL instance contained several PAN IDs then the
former could be used as the basis of a scop 4 zone as long as if fully encl= osed the PANs (scop 3 zones).
OTOH, if a given PAN contains m= ultiple RPL instances then the latter cannot be used to define a scop 4
zone boundary because that would violate the RFC 4007 constraint= s that Brian enumerated.

HTH, -K-

Cheers;
Pascal


-----Original Message-----
From: Brian Haberman [mailto:br= ian@innovationslab.net]
Sent: jeudi 14 novembre 2013 = 07:23
To: Pascal Thubert (pthubert)
Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6@ietf.org IPv6 List; 6lo@ietf.org
Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multic= ast-scopes-02.txt

Pascal,
=A0 =A0 Scope 3 being contained within scope4 is mandated by RFC 4007.
Specifically, RFC 4007 describes the following properties:

o =A0Zone boundaries cut through nodes, not links. =A0(Note that the global= zone has no boundary, and the boundary of an interface-local zone encloses= just a single interface.)

o =A0Zones of the same scope cannot overlap; i.e., they can have no links o= r interfaces in common.

o =A0A zone of a given scope (less than global) falls completely within zon= es of larger scope. =A0That is, a smaller scope zone cannot include more to= pology than would any larger scope zone with which it shares any links or i= nterfaces.

o =A0Each zone is required to be "convex" from a routing perspect= ive; i.e., packets sent from one interface to any other in the same zone ar= e never routed outside the zone. =A0Note, however, that if a zone contains = a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer ne= twork of the tunnel can be located outside the zone without breaking the co= nvexity property.


I don't see anything in this draft that would change those properties.<= br>
Regards,
Brian

On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote:
> Hello Brian:
>
> 03 seems to derive from autonomic behavior, whereas 04 derives from ad= min. I do not see there a direct indication that 03 is contained in 04 thou= gh in the deployments I have in mind it would certainly be the case. Whethe= r we want to enforce or on the contrary do not want to enforce the nesting = is probably something we want to clarify.
>
> Cheers
>
> Pascal
>
>
> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: mercredi 13 novembre 2013 07:22
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; > ipv6@ietf.org IPv6 List; 6lo@ietf.org
> Subject: Re: [6lo] Fwd: New Version Notification for
> draft-ietf-6man-multicast-scopes-02.txt
>
> Pascal,
>
> On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote:
>> The document has been accepted as a WG work item. =A0Check out
>> http://www.ietf.org/internet-drafts/draft= -ietf-6man-multicast-scopes-
>> 0
>> 2.txt
>>
>>
>> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthube= rt)" <pthubert@cisco.com&= gt; wrote:
>>
>>> Hello Ralph:
>>>
>>> http://tools.ietf.org/html/draft-droms-6man= -multicast-scopes-02 does not seem to contains the section you're i= nlining. The only diff I found was -specific going -local.
>>> As we are at it, would we be ahead of ourselves if that the dr= aft also specifies that a collection of RPL DODAGs of a same instance feder= ated over an isolated backbone (such as a VLAN) in an 04 ?.
>>>
>>> If I may add, there is kind of an habit that scopes are nested= . Seems that we are going away from that assumption and maybe it would be g= ood to have a sentence saying that?
>>>
>
> Scopes are still nested. =A0See RFC 4007. =A0Are you saying that this = document is changing that?
>
> Regards,
> Brian
>

-----------------------= ---------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--001a11c2fcf6785bd104eb2c517a-- From mcr@sandelman.ca Fri Nov 15 07:26:17 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D895521F9D46; Fri, 15 Nov 2013 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSzCJIQ+ON6m; Fri, 15 Nov 2013 07:26:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2121F9A43; Fri, 15 Nov 2013 07:26:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F58720049; Fri, 15 Nov 2013 11:38:27 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C36E063B88; Fri, 15 Nov 2013 10:26:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B3D8463AEF; Fri, 15 Nov 2013 10:26:13 -0500 (EST) From: Michael Richardson To: Kerry Lynn In-Reply-To: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <5284CE9E.4060001@innovationslab.net> 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 Cc: "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , Brian Haberman , "Ralph Droms \(rdroms\)" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:26:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kerry Lynn wrote: > I mostly agree Brian; > It's a bit touchy because in 802.15.4 a PAN ID is configured > administratively and could lead to an 04 interpretation. > One could take that argument to the extreme and say that selecting SS= ID > (802.11) or plugging into a wall socket > (802.3) is an administrative act.=C2=A0 Let's not be too literal and = instead say > that the "automatic" zone boundary > definition applies to an existing LAN.=C2=A0 If you think about a Lin= k-Local I offer this definition: an independant outside observer can determine the boundaries of scope 3 (2, and 1) can be observed without knowledge of the internal policies of a node. That's why we can say that it is automatically defined: there is no choice to make or policy to apply. This is obvious with a wired network: you just follow the wires. (The nodes/machines don't even need to be on.) For a wireless network, you need to have a radio to sniff with, but given that, you can mostly determine things. scope 4 is the first scope where a policy *may* come into play. The thing that broke up the log jam last week was the understanding that policies may be administratively defined such that the device can make a decision on it's own, but that this decision is not necessarily visible to = an external observer. (insert reference to Heisenburg uncertainty principle, and Einstein's hidden variables if you like) (I need to follow up to Kerry's reply from last week. I'm not sure that Pascal read it) =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) iQCVAwUBUoY9FYqHRg3pndX9AQJd2AQAl1fYiWxsixRP26NnvPDK2QO7qxOr2sFJ NXYhCZwdksK45Pq9H5oh5Bue/E5tlmuqZfKgu9aGv4F1dpQVcxfICBpE9Eu28cha +nXRg1xB0AyHY0kZzutBwxRovh4SzE6H94f6BdhbQxbHFJKst4FXHjcXgGqbMghz cRXzxdAVvDw= =mvAI -----END PGP SIGNATURE----- --=-=-=-- From Randy.Turner@landisgyr.com Fri Nov 15 07:41:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3B11E80F5 for ; Fri, 15 Nov 2013 07:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z55YhmzNpdx2 for ; Fri, 15 Nov 2013 07:41:47 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09611E8171 for ; Fri, 15 Nov 2013 07:39:44 -0800 (PST) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB016.eurprd01.prod.exchangelabs.com (10.255.176.38) with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 15 Nov 2013 15:39:42 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.36]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.36]) with mapi id 15.00.0820.005; Fri, 15 Nov 2013 15:39:42 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] AMI applicability: storing/non-storing. Thread-Index: AQHO2aeOElTiGDu4skinht2fNlWkvJoWaBGAgACUR4CAAAFZMIAABe2AgA95L5A= Date: Fri, 15 Nov 2013 15:39:41 +0000 Message-ID: <81d9bba68e174c9fb066d18122eecb67@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(24454002)(189002)(199002)(51704005)(377454003)(13464003)(54356001)(74706001)(74876001)(76796001)(76786001)(51856001)(56816003)(77982001)(79102001)(59766001)(63696002)(69226001)(77096001)(85306002)(33646001)(83072001)(15202345003)(53806001)(15975445006)(76482001)(65816001)(47446002)(74502001)(19580395003)(50986001)(47976001)(87936001)(54316002)(81342001)(2656002)(31966008)(83322001)(19580405001)(80022001)(46102001)(74662001)(66066001)(56776001)(81542001)(81686001)(87266001)(4396001)(80976001)(47736001)(81816001)(74316001)(74366001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB016; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:41:52 -0000 Hi Don, Sorry for the delayed reply...was out of commission for awhile. Yes, I'm aware of the existing spec'd forms of storing and non-storing, how= ever, the "hybrid storing" mode is not hybrid with regards to unicast, but= just simply listening to multicast joins from your children and storing th= ose group addresses. I don't think this is that complex -- it would benef= it the non-flooding method that I referred to in the research paper, withou= t adding too much RAM burden for the routing motes in the network. If my a= ssumptions regarding the number of multicast groups that might be active in= an LLN is not correct, then that would have some application (may be appro= priate for some networks, but not others) affinity. =20 Randy -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don= Sturek Sent: Tuesday, November 05, 2013 2:16 PM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] AMI applicability: storing/non-storing. Hi Randy, "Hybrid storing" modes were looked into awhile ago in ROLL and abandoned du= e to complexity. Currently, only storing and non-storing is supported in a= specific DODAG instance. I think the topic of multicast support is a bit separate. I think you forwarded me a research paper that used storing mode to analyze multicast group member reachability. That is an interesting topic when considering multicast forwarding approaches that don't use flooding (although, I would = expect that storing mode would be used with the approach since you need all= of that routing information, plus multicast group membership, to make forw= arding decisions) Don On 11/5/13 10:59 AM, "Turner, Randy" wrote: >I agree that non-storing mode addresses the primary AMI use-case where=20 >endpoints push data up and through the DODAG root. > >Could there be a "hybrid-storing" mode that doesn't use as much RAM to=20 >contain routes to all nodes in a sub-tree? Instead of traditional=20 >storing mode, could a node store just multicast memberships in all nodes "= below" >a particular mote ? Assuming there would much fewer multicast=20 >memberships than would be required for RFC 6550 storing mode ? It's a=20 >variant of storing+multicast, without the traditional storing mode RAM=20 >usage. > >I'm still looking at the MPL document, so apologies if that's already=20 >discussed. > >Randy > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 >Michael Richardson >Sent: Tuesday, November 05, 2013 1:50 PM >To: Routing Over Low power and Lossy networks >Subject: Re: [Roll] AMI applicability: storing/non-storing. > > >Popa, Daniel wrote: > Daniel> However, my point is that these challenges are mostly=20 >related to > Daniel> RPL storing mode of operation. As a consequence, I am OK to > Daniel> narrow down the scope of the applicability statement for=20 >AMI to > Daniel> only RPL non-storing mode of operation, as I stated in my > Daniel> previous email. As for having different specs for different=20 >use > Daniel> cases, I expect that by focusing only on RPL non-storing=20 >mode a > Daniel> single AMI applicability statement will be able to cover > Daniel> efficiently "all" the reasonable requirements, for "all" use > Daniel> cases. > >Ah, I did not understand that from your previous email. >Yes, please. Pick non-storing, and lets' proceed!!! > >-- >] Never tell me the odds! | ipv6 mesh >networks [ >] Michael Richardson, Sandelman Software Works | network >architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > >P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > >This e-mail (including any attachments) is confidential and may be=20 >legally privileged. If you are not an intended recipient or an=20 >authorized representative of an intended recipient, you are prohibited=20 >from using, copying or distributing the information in this e-mail or=20 >its attachments. If you have received this e-mail in error, please=20 >notify the sender immediately by return e-mail and delete all copies of=20 >this message and any 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 From d.sturek@att.net Fri Nov 15 08:43:40 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17F11E81A6 for ; Fri, 15 Nov 2013 08:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOXcd4Bb8kYl for ; Fri, 15 Nov 2013 08:43:35 -0800 (PST) Received: from nm8-vm8.access.bullet.mail.gq1.yahoo.com (nm8-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.216]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FD11E81B7 for ; Fri, 15 Nov 2013 08:43:11 -0800 (PST) Received: from [216.39.60.176] by nm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Nov 2013 16:00:53 -0000 Received: from [98.138.104.100] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Nov 2013 16:00:53 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 15 Nov 2013 16:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1384531253; bh=DYAx/6ef5CMt58NxZHzjkWwNpyzxsisLgTFDmINEo28=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=c7BTbhMMOMCTpFC6yJdy0QottXFVgB2Tio8JkMnUZ6wZzTBdl0rbV2d6Q15ClUdqDNY9gDK4ZtnzRdgy5KL46t+pwyKvhMb3fEFs1XU3UUKF7cUOToCEbPf8bU8KoX+72CNPGihugQl7tMttDEChxTUTFhGpM4cIzYtnAVrXWK8= X-Yahoo-Newman-Id: 141020.97012.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gWTtGJsVM1noq0Qtg6j_daYdr.QKGl2eD1cC0lSWOAp8IEt J5lWOCrh8CRmXrbru3IrkvDdjnAWhyh86XCIWiHaQmMOBLLpM5.QyVv4Ntqi hi_p5m5cwzgvHc0sgPpgd_.p1Z2Zgii.c.gA41XUPVmhvJGw5cXU0Ct3mXxr 42q_qlAKtHTlFMSLwS3IHW8tN6zy_1uUJ_kgrXJL6fm91aXbxRsSYkADx5Wx 91AJIgnZGi3HQGWdkcR71yObEne3pYDkgsUyNXq6T.IHE_cxtg92ArN4wg9H W1EsuBzy6tloCZarfrIE04b1K1pE.Py8JvGnSPHgwSAhin_o5.EasEZ0X6q_ HhOmoXWKFopDVQEwci7G9._nd_C0IDkw80YjWOTyalQBYLgWkXo8PokW9NXR PhXU3_nAOerNZN679hb_24lDFtjRK5.fTitViCHFu7Fzg0yb8pCp9pvNDQSz .QsfedGiFoxWL.nTSQmcoldBQYmdEIn4R.lzXOuKREP4SadpcYja17hH4WzB SmqkNpSg.HJ7my0k9P6FapqrCVOA83N9PJEfLZ1rZkHwdG59nBRDx64PY X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.5] (d.sturek@69.106.86.14 with ) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 15 Nov 2013 16:00:52 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Fri, 15 Nov 2013 08:00:50 -0800 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] AMI applicability: storing/non-storing. In-Reply-To: <81d9bba68e174c9fb066d18122eecb67@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 16:43:40 -0000 Hi Randy, If you go back in the ROLL archives, you will see the discussion on a hybrid storing/non-storing deployment. I think there was a good deal of discussion at the time on complexity and it was decided (by the ROLL design team) not to pursue development. Of course, if you want to provide an individual submission I-D, I am sure there would be enough interest to at least review it..... Don On 11/15/13 7:39 AM, "Turner, Randy" wrote: > >Hi Don, > >Sorry for the delayed reply...was out of commission for awhile. > >Yes, I'm aware of the existing spec'd forms of storing and non-storing, >however, the "hybrid storing" mode is not hybrid with regards to >unicast, but just simply listening to multicast joins from your children >and storing those group addresses. I don't think this is that complex >-- it would benefit the non-flooding method that I referred to in the >research paper, without adding too much RAM burden for the routing motes >in the network. If my assumptions regarding the number of multicast >groups that might be active in an LLN is not correct, then that would >have some application (may be appropriate for some networks, but not >others) affinity. > > >Randy > > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Don Sturek >Sent: Tuesday, November 05, 2013 2:16 PM >To: Routing Over Low power and Lossy networks >Subject: Re: [Roll] AMI applicability: storing/non-storing. > >Hi Randy, > >"Hybrid storing" modes were looked into awhile ago in ROLL and abandoned >due to complexity. Currently, only storing and non-storing is supported >in a specific DODAG instance. > >I think the topic of multicast support is a bit separate. I think you >forwarded me a research paper that used storing mode to analyze multicast >group member reachability. That is an interesting topic when considering >multicast forwarding approaches that don't use flooding (although, I >would expect that storing mode would be used with the approach since you >need all of that routing information, plus multicast group membership, to >make forwarding decisions) > >Don > > >On 11/5/13 10:59 AM, "Turner, Randy" wrote: > >>I agree that non-storing mode addresses the primary AMI use-case where >>endpoints push data up and through the DODAG root. >> >>Could there be a "hybrid-storing" mode that doesn't use as much RAM to >>contain routes to all nodes in a sub-tree? Instead of traditional >>storing mode, could a node store just multicast memberships in all nodes >>"below" >>a particular mote ? Assuming there would much fewer multicast >>memberships than would be required for RFC 6550 storing mode ? It's a >>variant of storing+multicast, without the traditional storing mode RAM >>usage. >> >>I'm still looking at the MPL document, so apologies if that's already >>discussed. >> >>Randy >> >>-----Original Message----- >>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Michael Richardson >>Sent: Tuesday, November 05, 2013 1:50 PM >>To: Routing Over Low power and Lossy networks >>Subject: Re: [Roll] AMI applicability: storing/non-storing. >> >> >>Popa, Daniel wrote: >> Daniel> However, my point is that these challenges are mostly >>related to >> Daniel> RPL storing mode of operation. As a consequence, I am OK to >> Daniel> narrow down the scope of the applicability statement for >>AMI to >> Daniel> only RPL non-storing mode of operation, as I stated in my >> Daniel> previous email. As for having different specs for different >>use >> Daniel> cases, I expect that by focusing only on RPL non-storing >>mode a >> Daniel> single AMI applicability statement will be able to cover >> Daniel> efficiently "all" the reasonable requirements, for "all" use >> Daniel> cases. >> >>Ah, I did not understand that from your previous email. >>Yes, please. Pick non-storing, and lets' proceed!!! >> >>-- >>] Never tell me the odds! | ipv6 mesh >>networks [ >>] Michael Richardson, Sandelman Software Works | network >>architect [ >>] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails >> [ >> >> >>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 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 any 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 > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Fri Nov 15 10:23:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5932D11E821A; Fri, 15 Nov 2013 10:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZrOZs+iVrVQ; Fri, 15 Nov 2013 10:23:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 7A83311E820D; Fri, 15 Nov 2013 10:23:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4855D20083; Fri, 15 Nov 2013 14:35:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5672F63B88; Fri, 15 Nov 2013 13:22:59 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 459AE63AEF; Fri, 15 Nov 2013 13:22:59 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> 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 Cc: Brian Haberman , "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , "Ralph Droms \(rdroms\)" , Tim Chown , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 18:23:02 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > The LLN probably forms a single RPL Domain though we have not discussed > that yet. Discussing with Ralph, I understand that the RPL domain is 03 > and the whole multilink subnet is 04. No, that's not quite right. Scope-3 is each of the LLNs that have a single technology instance (e.g. 802.15.4 + PANID) Scope-4 is the whole multilink subnet as defined by the span of the collection of DODAGs (my suggestion) The RPL DODAG instances would likely span the backbone, and would be the basis for scope-4 configuration. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoZmg4qHRg3pndX9AQKgLAP/W6oWMA1AmEGTp4flzrMnltaQR5zJrm92 WeSBaXC+OvxeD5TLQROd7Oz99vJTOFPgydwhQYAqh9AqRRlFr3f/r9ZWFdD4TaVx ctPmT+GWoyfnszDF4LggIMJk0Y1uPBeRfSRa3l3pt5qe+B4e1180Ldo6n5X91or2 WIN8wNspZtc= =ZI7d -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 15 11:40:08 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB3821F9B4B for ; Fri, 15 Nov 2013 11:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-53K2FhLTQD for ; Fri, 15 Nov 2013 11:40:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 17FD511E810C for ; Fri, 15 Nov 2013 11:40:03 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CEA520087 for ; Fri, 15 Nov 2013 15:52:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1F42363B88; Fri, 15 Nov 2013 14:40:02 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FBF163AEF for ; Fri, 15 Nov 2013 14:40:02 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 19:40:08 -0000 --=-=-= Don Sturek wrote: > If you go back in the ROLL archives, you will see the discussion on a > hybrid storing/non-storing deployment. > I think there was a good deal of discussion at the time on complexity and > it was decided (by the ROLL design team) not to pursue development. It wasn't just that it was complex; it was that we couldn't come up with a use case that would justify that complexity at the time. My opinion is that the AMI people have such a use case and should pursue writing something up. -- 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) iQCVAwUBUoZ4kYqHRg3pndX9AQKXOwP/QbuSrEm9xTujnr/HbLA1Pxyc0WZWrmAZ ttFzvonaBJzLL0Etgg70zWybLhj7wZQuUn5WC/ai5C44NMaIsN7JC7nGA+/AOsRd B9tMz4GHzEkQbQwKvBEqbgFPk/1ZxVr3N4EElGhle1q87ps1pb5ri88mMWOS2c2L BN8HfQ63YW0= =rfVH -----END PGP SIGNATURE----- --=-=-=-- From tjc@ecs.soton.ac.uk Sat Nov 16 06:46:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041FA11E80F1; Sat, 16 Nov 2013 06:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hArLdB2aUYOJ; Sat, 16 Nov 2013 06:46:26 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id A623F11E80EC; Sat, 16 Nov 2013 06:46:20 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAGEkBiW002064; Sat, 16 Nov 2013 14:46:11 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rAGEkBiW002064 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1384613172; bh=O13vD0S5MI2nYV2fdm9udb+kXeg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=aw0x9bfPVlRHSNfzTzaNs9Mv46Pc1ArVN9wJc50QjHJtlKXIAvqA3Cs69c9Z4gQBd HJzN89Gj14hSKRDYd2oEpRQgkt4dnY54mwa+ueYRqaY3gOmAaFICmDJJgQzytZREeV jwtA0UUQAshLg92OzRppYGH0wibK7TTnWX6+rC6k= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pAFEkB0959623149C9 ret-id none; Sat, 16 Nov 2013 14:46:11 +0000 Received: from [192.168.1.109] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rAGEk5xd017536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Nov 2013 14:46:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Sat, 16 Nov 2013 14:46:05 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> <37635E59-0FE8-4EBA-B5C1-EFBA1DA3C6CD@ecs.soton.ac.uk> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pAFEkB095962314900; tid=pAFEkB0959623149C9; client=relay,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rAGEkBiW002064 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , Brian Haberman , "Ralph Droms \(rdroms\)" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 14:46:31 -0000 Hi, On 15 Nov 2013, at 00:12, Samita Chakrabarti = wrote: > Hi Tim, >=20 >> Are there use cases documented somewhere in a 6lo or 6lo-related = draft? >=20 >> I'm interested as we're updating the homenet text about multicast = scopes. We have agreed some text in principle with Brian for that, but = it's interesting because we may, indeed are likely to, have 6lo networks = within future IPv6 home networks. >=20 > [SC>] AFAIK, 6lo/6lowpan basic documents do not discuss the multicast = scopes in details.=20 > [SC>] It'll be certainly helpful to document the scopes of 6lo within = the scope of home networks or equivalent. > In addition I think, it'd be really helpful for implementers if we = provide some examples of scopes of different protocols in the = 6man-multicast-scopes doc along with the pointer to RFC 4007. That would be excellent. A separate document targeted at homenet WG = showing multicast scenarios might be nice, but perhaps overkill. Tim >=20 > Thanks, > -Samita >=20 >=20 >> -----Original Message----- >> From: Brian Haberman [mailto:brian@innovationslab.net]=20 >> Sent: mercredi 13 novembre 2013 07:22 >> To: Pascal Thubert (pthubert) >> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; = ipv6@ietf.org IPv6 List; 6lo@ietf.org >> Subject: Re: [6lo] Fwd: New Version Notification for = draft-ietf-6man-multicast-scopes-02.txt >>=20 >> Pascal, >>=20 >> On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >>> The document has been accepted as a WG work item. Check out=20 >>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 >>> 2.txt >>>=20 >>>=20 >>> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" = wrote: >>>=20 >>>> Hello Ralph: >>>>=20 >>>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 = does not seem to contains the section you're inlining. The only diff I = found was -specific going -local. >>>> As we are at it, would we be ahead of ourselves if that the draft = also specifies that a collection of RPL DODAGs of a same instance = federated over an isolated backbone (such as a VLAN) in an 04 ?. >>>>=20 >>>> If I may add, there is kind of an habit that scopes are nested. = Seems that we are going away from that assumption and maybe it would be = good to have a sentence saying that? >>>>=20 >>=20 >> Scopes are still nested. See RFC 4007. Are you saying that this = document is changing that? >>=20 >> Regards, >> Brian >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From trac+roll@trac.tools.ietf.org Sat Nov 16 16:30:54 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7F11E8105 for ; Sat, 16 Nov 2013 16:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6JpIP8nDaVX for ; Sat, 16 Nov 2013 16:30:52 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8671911E80E2 for ; Sat, 16 Nov 2013 16:30:52 -0800 (PST) Received: from localhost ([127.0.0.1]:54052 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhqGE-0005Fz-Fz; Sun, 17 Nov 2013 01:30:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 17 Nov 2013 00:30:46 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:17 Message-ID: <082.43d487082166be0953cea7f520573ec2@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 00:30:54 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): '''Related to draft-ietf-6man-multicast-scopes-02''' http://www.ietf.org/mail-archive/web/roll/current/msg08342.html This revision adds the definition of "scop 3" for IEEE 802.15.4 networks: 4. Definition of Realm-Local Scope for IEEE 802.15.4 When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. I've cross-posted to 6lo to get review and comment from that WG. http://www.ietf.org/mail-archive/web/roll/current/msg08343.html http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not seem to contains the section you're inlining. The only diff I found was -specific going -local. As we are at it, would we be ahead of ourselves if that the draft also specifies that a collection of RPL DODAGs of a same instance federated over an isolated backbone (such as a VLAN) in an 04 ?. If I may add, there is kind of an habit that scopes are nested. Seems that we are going away from that assumption and maybe it would be good to have a sentence saying that? http://www.ietf.org/mail-archive/web/roll/current/msg08344.html The document has been accepted as a WG work item. Check out http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast- scopes-02.txt http://www.ietf.org/mail-archive/web/6lo/current/msg00298.html Indeed, Section 4 talks about the realm-local scope for IEEE 802.15.4 "4. Definition of Realm-Local Scope for IEEE 802.15.4 When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID." In several places, I think there is a typo: s/scop /scope How about adding one or two examples in the appendix section to clarify the nested scope in the home-network containing two types of networks (wifi and LLN) ? Perhaps, we expecting that LLN could have further division in scope -- ie, IEEE 802.15.4 or BT-le or MS/TP networks. The example of mdns, rpl, and nd possibly will fall in different scopes. http://www.ietf.org/mail-archive/web/roll/current/msg08345.html Scopes are still nested. See RFC 4007. Are you saying that this document is changing that? http://www.ietf.org/mail-archive/web/roll/current/msg08346.html 03 seems to derive from autonomic behavior, whereas 04 derives from admin. I do not see there a direct indication that 03 is contained in 04 though in the deployments I have in mind it would certainly be the case. Whether we want to enforce or on the contrary do not want to enforce the nesting is probably something we want to clarify. http://www.ietf.org/mail-archive/web/roll/current/msg08348.html Pascal, Scope 3 being contained within scope4 is mandated by RFC 4007. Specifically, RFC 4007 describes the following properties: o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.) o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. o Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property. I don't see anything in this draft that would change those properties. http://www.ietf.org/mail-archive/web/roll/current/msg08350.html I mostly agree Brian; It's a bit touchy because in 802.15.4 a PAN ID is configured administratively and could lead to an 04 interpretation. A RPL domain (that is an 03) that may span multiple PAN IDs. If PAN ID was 04 that would have been reverse nesting. The draft now clarifies that this is also an 03 but now we still have a potential conflict between a RPL domain and a PAN. Would a RPL domain be constrained by the PAN ID? In this case that would imply that all the LLN must always be a single PAN and constrain the size of a subnet to 64K. There is a lot behind the sentence "care must be taken in the definition of those larger scopes to ensure that inclusion constraint is met." http://www.ietf.org/mail-archive/web/roll/current/msg08347.html > 03 seems to derive from autonomic behavior, whereas 04 derives from admin. I do not see >there a direct indication that 03 is contained in 04 though in the deployments I have in mind >it would certainly be the case. Whether we want to enforce or on the contrary do not want to >enforce the nesting is probably something we want to clarify. Are there use cases documented somewhere in a 6lo or 6lo-related draft? I'm interested as we're updating the homenet text about multicast scopes. We have agreed some text in principle with Brian for that, but it's interesting because we may, indeed are likely to, have 6lo networks within future IPv6 home networks. http://www.ietf.org/mail-archive/web/roll/current/msg08349.html Hello Tim; The 6TiSCH architecture documents a use case whereby a large (RPL based) LLN is federated by an higher speed backbone such as Ethernet that mostly spans the LLN. The LLN is partitioned by RPL in multiple DODAGs, and the roots of the DODAGs connect to the backbone to provide end to end connectivity over the formed multilink subnet. The LLN probably forms a single RPL Domain though we have not discussed that yet. Discussing with Ralph, I understand that the RPL domain is 03 and the whole multilink subnet is 04. It results that we cannot address a single RPL instance or a single DODAG as a scope. The intersection with 802.15.4 PAN-ID still troubles me a bit but that's another thread. http://www.ietf.org/mail-archive/web/roll/current/msg08356.html >Pascal Thubert (pthubert) wrote: > The LLN probably forms a single RPL Domain though we have not discussed > that yet. Discussing with Ralph, I understand that the RPL domain is 03 > and the whole multilink subnet is 04. No, that's not quite right. Scope-3 is each of the LLNs that have a single technology instance (e.g. 802.15.4 + PANID) Scope-4 is the whole multilink subnet as defined by the span of the collection of DODAGs (my suggestion) The RPL DODAG instances would likely span the backbone, and would be the basis for scope-4 configuration. http://www.ietf.org/mail-archive/web/roll/current/msg08351.html >On Nov 14, 2013, at 6:58 PM 11/14/13, "Pascal Thubert (pthubert)" wrote: > I mostly agree Brian; > > It's a bit touchy because in 802.15.4 a PAN ID is configured administratively and could lead to an 04 interpretation. I consider a PAN ID to be equivalent to an address ... both are configured administratively but are part of the > > A RPL domain (that is an 03) that may span multiple PAN IDs. Pascal - RPL domains are, in my opinion, completely unrelated to MPL scopes. RPL is only mentioned obliquely, as an example of a protocol that accommodates the memory constraints in highly constrained devices. So, I don't think there is any reason to say "A RPL domain (that is an 03)". > If PAN ID was 04 that would have been reverse nesting. > The draft now clarifies that this is also an 03 but now we still have a potential conflict between a RPL domain and a PAN. > > Would a RPL domain be constrained by the PAN ID? No ... RPL domain is independent of MPL scope. As a practical matter, a "RPL domain" is a little tricky to define, and even trickier to tie into a multicast scope. There is nothing in the multicast address or the MPL header to tie it to a DODAG or some other RPL domain identifier. In a mesh where multiple DODAGS and RPL domains may be interleaved, there doesn't seem to be a way to identify a MPL scope. > > In this case that would imply that all the LLN must always be a single PAN and constrain the size of a subnet to 64K. I think you're confusing the use of "scop 3" for carrying multicast traffic via MPL across a single mesh network and the use of, e.g., "scop 4" for the scope of, say, mDNS for DNS-SD across a federation of subnets. I won't attempt the ASCII art here ... but here's an example scenario as I understand it: SEP2.0 DNS-SD/mDNS queries intended to span a federation of subnets is sent to (working from memory) FC04::FB. When delivered to an LBR at the border of a 6LoWPAN mesh, that query would be encapsulated in FC03:: to carry it across the mesh. Similarly, a query from a mesh node would have an inner header with dst FC04::FB and encapsulated by the source with outer header dst FC03::; then the MPL outer header would be taken off by the LBR and inner DNS-SD/mDNS query would be forwarded out any other interfaces based on the dst FC04::FB. > There is a lot behind the sentence "care must be taken in the definition of those larger scopes to ensure that inclusion constraint is met." OK, but I don't think draft-ietf-6man-multicast-scopes contradicts RFC 4007 in any way. http://www.ietf.org/mail-archive/web/roll/current/msg08352.html > I mostly agree Brian > It's a bit touchy because in 802.15.4 a PAN ID is configured administratively and could lead to an 04 interpretation. One could take that argument to the extreme and say that selecting SSID (802.11) or plugging into a wall socket (802.3) is an administrative act. Let's not be too literal and instead say that the "automatic" zone boundary definition applies to an existing LAN. If you think about a Link-Local zone, it is defined as a set of physically connected interfaces and the zone boundary is defined by a *lack* of forwarding (see [RFC4291] section 2.5.6). I think if there is a need for scope value 3 it is to provide classic Link-Local multicast behavior over a connected mesh. I think the definition should be independent of RPL and instead depend on some "L2 instance" definition. PAN ID works for 802.15.4 networks. >A RPL domain (that is an 03) that may span multiple PAN IDs. draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based on PAN ID. The latest version makes no mention at all of RPL. >If PAN ID was 04 that would have been reverse nesting. > The draft now clarifies that this is also an 03 but now we still have a potential conflict between a RPL domain and a PAN. > Would a RPL domain be constrained by the PAN ID? > In this case that would imply that all the LLN must always be a single PAN and constrain the size of a >subnet to 64K. There is a lot behind the sentence "care must be taken in the definition of those larger >scopes to ensure that inclusion constraint is met." I think the understanding that was reached at dinner last week is that, under certain circumstances, policy can count as "administratively configured". Thus, if a RPL instance contained several PAN IDs then the former could be used as the basis of a scop 4 zone as long as if fully enclosed the PANs (scop 3 zones). OTOH, if a given PAN contains multiple RPL instances then the latter cannot be used to define a scop 4 zone boundary because that would violate the RFC 4007 constraints that Brian enumerated. http://www.ietf.org/mail-archive/web/roll/current/msg08353.html >Kerry Lynn wrote: > I mostly agree Brian; > It's a bit touchy because in 802.15.4 a PAN ID is configured > administratively and could lead to an 04 interpretation. > One could take that argument to the extreme and say that selecting SSID > (802.11) or plugging into a wall socket > (802.3) is an administrative act. Let's not be too literal and instead say > that the "automatic" zone boundary > definition applies to an existing LAN. If you think about a Link- Local I offer this definition: an independant outside observer can determine the boundaries of scope 3 (2, and 1) can be observed without knowledge of the internal policies of a node. That's why we can say that it is automatically defined: there is no choice to make or policy to apply. This is obvious with a wired network: you just follow the wires. (The nodes/machines don't even need to be on.) For a wireless network, you need to have a radio to sniff with, but given that, you can mostly determine things. scope 4 is the first scope where a policy *may* come into play. The thing that broke up the log jam last week was the understanding that policies may be administratively defined such that the device can make a decision on it's own, but that this decision is not necessarily visible to an external observer. http://www.ietf.org/mail-archive/web/6lo/current/msg00299.html Hi Tim, >Are there use cases documented somewhere in a 6lo or 6lo-related draft? >I'm interested as we're updating the homenet text about multicast scopes. We have agreed >some text in principle with Brian for that, but it's interesting because we may, indeed are >likely to, have 6lo networks within future IPv6 home networks. [SC>] AFAIK, 6lo/6lowpan basic documents do not discuss the multicast scopes in details. [SC>] It'll be certainly helpful to document the scopes of 6lo within the scope of home networks or equivalent. In addition I think, it'd be really helpful for implementers if we provide some examples of scopes of different protocols in the 6man-multicast- scopes doc along with the pointer to RFC 4007. http://www.ietf.org/mail-archive/web/roll/current/msg08358.html >On 15 Nov 2013, at 00:12, Samita Chakrabarti wrote: > In addition I think, it'd be really helpful for implementers if we provide some examples of scopes of different >protocols in the 6man- multicast-scopes doc along with the pointer to RFC 4007. That would be excellent. A separate document targeted at homenet WG showing multicast scenarios might be nice, but perhaps overkill. -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From mariainesrobles@googlemail.com Sun Nov 17 04:48:57 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B211E8C83 for ; Sun, 17 Nov 2013 04:48:57 -0800 (PST) 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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVrxgJ8UsY5v for ; Sun, 17 Nov 2013 04:48:56 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 383C811E8C81 for ; Sun, 17 Nov 2013 04:48:42 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so2988544vcb.9 for ; Sun, 17 Nov 2013 04:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oRGINZPlXTy84S5lqb4afkTvL/jpHVCOmDFtYu6CXhw=; b=hLFx0eUiAiTbdcE5bG1e/Y3XQgEDIIEHrPeJhERAhT3cUeTwzdnCbxJ5Y5UVPPdTRp nPKvsGK1whjybfxSVOzSjYjNAzOhGS99kLzo1V/kJ12IBER6n5uDkrrRHelQOU/Sj7zG AYdA4iWbW1UngxfoiwXdPqdyC4xInloGXzaTF1jjPWFqHuFyj1Eg+5/sB0WmMCc+jFnv nQCOhZpyNVwvI0wGVkpae9s7EDIR9kDOWvlINC63/nVUGY9WEdVojAt9QxMKdjXpBqH6 aUw9mXLmZx4DpU8wKZbqXu31LPHuGKPrgv9l1CglLm5fOiPZq0H61RrU40qGLIb6fD1a sumA== MIME-Version: 1.0 X-Received: by 10.220.74.69 with SMTP id t5mr10323577vcj.18.1384692521555; Sun, 17 Nov 2013 04:48:41 -0800 (PST) Received: by 10.220.46.198 with HTTP; Sun, 17 Nov 2013 04:48:41 -0800 (PST) Date: Sun, 17 Nov 2013 10:48:41 -0200 Message-ID: From: Ines Robles To: roll@ietf.org Content-Type: multipart/alternative; boundary=047d7b624cbededad304eb5ed972 Subject: [Roll] NOMCOM - final call for feedback, nominee list (NomCom Chair 2013) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 12:48:58 -0000 --047d7b624cbededad304eb5ed972 Content-Type: text/plain; charset=ISO-8859-1 FYI ------------------------------ Message: 2 Date: Sat, 16 Nov 2013 11:21:09 -0800 From: NomCom Chair 2013 To: IETF Announcement List Cc: wgchairs@ietf.org Subject: NOMCOM - final call for feedback, nominee list Message-ID: <20131116192109.11370.23437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" Help the Nomcom: this is the last call for general feedback on nominees. This email includes the willing nominee list for your convenience, as per RFC 5680. WG chairs, please forward this email to your WGs. WARNING - DO NOT reply to this email with feedback - the announcement tool provides an unpredictable Reply-To field. You may send mail to nomcom13, but please do continue reading for additional info. The deadline is midnight (any timezone) Wed Nov 20. Enter your feedback into the encrypted nomcom tool at: https://datatracker.ietf.org/nomcom/2013/feedback/ All feedback is confidential. Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry. The Nomcom will greatly appreciate your concrete and detailed thoughts on nominees. You need to have a datatracker account in order to enter feedback. This is the site to access either to create a datatracker account or to reset the password on an existing account: https://datatracker.ietf.org/accounts/ As we announced last week, we are sharing the names of the willing nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle. These names (appearing at the end of the email) have been available within the datatracker since our first call for feedback; we hope some people will be extra encouraged to provide feedback by seeing the names prior to datatracker login. All your feedback must be entered in the encrypted nomcom site (or mailed to nomcom-chair-2013@ietf.org or nomcom13@ietf.org). You may ask the chair or any another nomcom member to submit your feedback without your name attached, if you would prefer. Again, your feedback is absolutely confidential, however delivered. Thanks very much from all of us for your time and for helping the Nomcom to do the best possible job. Also enormous thanks to the willing nominees. Names below. Allison for the Nomcom APP Joe Hildebrand Barry Leiba (incumbent) Yoshiro Yoneya INT Donald Eastlake Wesley George Brian Haberman (incumbent) Ole Troan OPS Benoit Claise (incumbent) Linda Dunbar Victor Kuarsingh Bill Manning RAI Ben Campbell Alissa Cooper Keith Drage Dan Romascanu RTG Loa Andersson Alia Atlas Deborah Brungard Stewart Bryant (incumbent) Donald Eastlake Susan Hares Keyur Patel SEC Derek Atkins Donald Eastlake Jeff Hodges Leif Johansson Alexey Melnikov Kathleen Moriarty Eric Rescorla TSV Martin Stiemerling (incumbent) Dave Taht IAB Bernard Aboba (incumbent) Loa Andersson Alias Atlas Mary Barnes Marc Blanchet (incumbent) Ross Callon (incumbent) Hago Dafalla Linda Dunbar Roni Even Jim Gettys Ted Hardie Susan Hares Joe Hildebrand Sheng Jiang Eliot Lear (incumbent) Larry Masinter S. Moonesamy Kathleen Moriarty Kaveh Ranjbar Robert Sparks Tina Tsou Brian Trammell IAOC/IETF Trust Glenn Deen Tobias Gondrom Chris Griffiths (incumbent) John Levine Tina Tsou --047d7b624cbededad304eb5ed972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI

------------------------------

Message: 2
Date: Sat, 16 Nov 2013 11:21:09 -0800
From: NomCom Chair 2013 <n= omcom-chair-2013@ietf.org>
To: IETF Announcement List <ie= tf-announce@ietf.org>
Cc: wgchairs@ietf.org
Subject: NOMCOM - final call for feedback, nominee list
Message-ID: <20131116192109.11370.23437.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Help the Nomcom: =A0this is the last call for general feedback on
nominees. This email includes the willing nominee list for your
convenience, as per RFC 5680. WG chairs, please forward this
email to your WGs.

WARNING - DO NOT reply to this email with feedback - the
announcement tool provides an unpredictable Reply-To field.
You may send mail to nomcom13, but please do continue
reading for additional info.

The deadline is midnight (any timezone) Wed Nov 20.

Enter your feedback into the encrypted nomcom tool at:

https://datatracker.ietf.org/nomcom/2013/feedback/

All feedback is confidential.

Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry.

The Nomcom will greatly appreciate your concrete and detailed
thoughts on nominees.

You need to have a datatracker account in order to enter feedback.
This is the site to access either to create a datatracker account or to
reset the password on an existing account:

https:= //datatracker.ietf.org/accounts/

As we announced last week, we are sharing the names of the willing
nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle. =A0These names (appearing at the end of the email)
have been available within the datatracker since our first call for
feedback; we hope some people will be extra encouraged to provide
feedback by seeing the names prior to datatracker login. =A0 All your
feedback must be entered in the encrypted nomcom site (or mailed to
nomcom-chair-2013@ietf.org or nomcom13@ietf.org). =A0You ma= y ask the
chair or any another nomcom member to submit your feedback without
your name attached, if you would prefer.

Again, your feedback is absolutely confidential, however delivered.

Thanks very much from all of us for your time and for helping the
Nomcom to do the best possible job. =A0Also enormous thanks to the
willing nominees.

Names below.

Allison for the Nomcom

APP
Joe Hildebrand
Barry Leiba (incumbent)
Yoshiro Yoneya

INT
Donald Eastlake
Wesley George
Brian Haberman (incumbent)
Ole Troan

OPS
Benoit Claise (incumbent)
Linda Dunbar
Victor Kuarsingh
Bill Manning

RAI
Ben Campbell
Alissa Cooper
Keith Drage
Dan Romascanu

RTG
Loa Andersson
Alia Atlas
Deborah Brungard
Stewart Bryant (incumbent)
Donald Eastlake
Susan Hares
Keyur Patel

SEC
Derek Atkins
Donald Eastlake
Jeff Hodges
Leif Johansson
Alexey Melnikov
Kathleen Moriarty
Eric Rescorla

TSV
Martin Stiemerling (incumbent)
Dave Taht

IAB
Bernard Aboba (incumbent)
Loa Andersson
Alias Atlas
Mary Barnes
Marc Blanchet (incumbent)
Ross Callon (incumbent)
Hago Dafalla
Linda Dunbar
Roni Even
Jim Gettys
Ted Hardie
Susan Hares
Joe Hildebrand
Sheng Jiang
Eliot Lear (incumbent)
Larry Masinter
S. Moonesamy
Kathleen Moriarty
Kaveh Ranjbar
Robert Sparks
Tina Tsou
Brian Trammell

IAOC/IETF Trust
Glenn Deen
Tobias Gondrom
Chris Griffiths (incumbent)
John Levine
Tina Tsou


--047d7b624cbededad304eb5ed972-- From rdroms@cisco.com Mon Nov 18 08:11:24 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C711E8191; Mon, 18 Nov 2013 08:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7txC7MpFZ93; Mon, 18 Nov 2013 08:11:17 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7749711E81CE; Mon, 18 Nov 2013 08:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3659; q=dns/txt; s=iport; t=1384790812; x=1386000412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XFsE9EDZzqZ3nLbbTRnE4Rz7OkzMj0TVGA5WYxP5u/M=; b=HCo9tDPG50wtzyVuAt1msBgMeB1CCizL0PYnwVgVGCdNP+Ok9amtRsYm COHkwoFX4zHuRj6uYTdgiYh9ImJgTdoIIzAiDTe5wK27RId5ObRWHbysg 9uYEsFyARB0cJYv3zh2c6nQqIepPN7iSixnq0boXVBgF+gjxDacq4+Zhy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAO86ilKtJV2Y/2dsb2JhbABZgwc4U782gRsWdIIlAQEBAwEBAQE3NAkCBQcEAgEIEQQBAQEeCQcnCxQJCAIEDgUJh3IGDcI2F44xgQUzBwaDGoERA5gQgS+QXoFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,724,1378857600"; d="scan'208";a="359697" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 18 Nov 2013 16:06:45 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAIG6iDX020181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 16:06:44 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.168]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 10:06:44 -0600 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [6lo] New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO5HgsQxeYcn6OqEmLEG/VL5yhqQ== Date: Mon, 18 Nov 2013 16:06:43 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> <37635E59-0FE8-4EBA-B5C1-EFBA1DA3C6CD@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <9FEBB60F854DB24D90BC42ABA28F2799@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Haberman Brian , "ipv6@ietf.org IPv6 List" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 16:11:24 -0000 On Nov 16, 2013, at 6:46 AM 11/16/13, Tim Chown wrote= : > Hi, >=20 > On 15 Nov 2013, at 00:12, Samita Chakrabarti wrote: >=20 >> Hi Tim, >>=20 >>> Are there use cases documented somewhere in a 6lo or 6lo-related draft? >>=20 >>> I'm interested as we're updating the homenet text about multicast scope= s. We have agreed some text in principle with Brian for that, but it's int= eresting because we may, indeed are likely to, have 6lo networks within fut= ure IPv6 home networks. >>=20 >> [SC>] AFAIK, 6lo/6lowpan basic documents do not discuss the multicast s= copes in details.=20 >> [SC>] It'll be certainly helpful to document the scopes of 6lo within th= e scope of home networks or equivalent. >> In addition I think, it'd be really helpful for implementers if we provi= de some examples of scopes of different protocols in the 6man-multicast-sco= pes doc along with the pointer to RFC 4007. >=20 > That would be excellent. A separate document targeted at homenet WG show= ing multicast scenarios might be nice, but perhaps overkill. Samita - I don't understand what you're suggesting as "scopes of different = protocols in the 6man-multicast-scopes". Do you mean examples of the defin= ition of scope 3 for various L2 technologies? - Ralph >=20 > Tim >=20 >>=20 >> Thanks, >> -Samita >>=20 >>=20 >>> -----Original Message----- >>> From: Brian Haberman [mailto:brian@innovationslab.net]=20 >>> Sent: mercredi 13 novembre 2013 07:22 >>> To: Pascal Thubert (pthubert) >>> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ip= v6@ietf.org IPv6 List; 6lo@ietf.org >>> Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-mu= lticast-scopes-02.txt >>>=20 >>> Pascal, >>>=20 >>> On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >>>> The document has been accepted as a WG work item. Check out=20 >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 >>>> 2.txt >>>>=20 >>>>=20 >>>> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >>>>=20 >>>>> Hello Ralph: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does = not seem to contains the section you're inlining. The only diff I found was= -specific going -local. >>>>> As we are at it, would we be ahead of ourselves if that the draft als= o specifies that a collection of RPL DODAGs of a same instance federated ov= er an isolated backbone (such as a VLAN) in an 04 ?. >>>>>=20 >>>>> If I may add, there is kind of an habit that scopes are nested. Seems= that we are going away from that assumption and maybe it would be good to = have a sentence saying that? >>>>>=20 >>>=20 >>> Scopes are still nested. See RFC 4007. Are you saying that this docum= ent is changing that? >>>=20 >>> Regards, >>> Brian >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From glenzorn@gmail.com Wed Nov 6 01:02:05 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1821E8120; Wed, 6 Nov 2013 01:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRWXdigV9VWt; Wed, 6 Nov 2013 01:02:05 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D783F21E80F4; Wed, 6 Nov 2013 01:02:04 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so9936337pdj.33 for ; Wed, 06 Nov 2013 01:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y376FwR3u5rINYv1Ri9n7YMIjFXSgwVooGiCwXGJQxc=; b=0xmUB76CGyF23S7N7KyCyZw/E+905ecgAW2Xfq4VGOEiIvmpTyV1xwqWMJlcejQqqi 6YhQxFvh1ScBuVVCwy8YJooL+b/jawrAMCvp0M8VU+i4tF+s00E8rmP8+bujBB5AYJ51 AEkfmhvFQrRg+hXnEt2ba27n1ChIvH/q9Fmaez9iZQ5al4RLJy/KySMUgma8ssEOxb0l O3Y0rJ775F6QGhI2mZKHWGJTWziTlIFp0kgJH39GrpgsEU4mA3wxUMt5CC+pSL5Kd47G ctmNVfXhs+U+Me4Qr+q8yCvRo58DWqpm3hEN6jLKnWcXjarS16oTjZyYAJefTCHysYrX 4gEA== X-Received: by 10.68.203.164 with SMTP id kr4mr2257759pbc.48.1383728519124; Wed, 06 Nov 2013 01:01:59 -0800 (PST) Received: from [192.168.0.104] (ppp-171-96-33-208.revip8.asianet.co.th. [171.96.33.208]) by mx.google.com with ESMTPSA id ka3sm39880705pbc.32.2013.11.06.01.01.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 01:01:58 -0800 (PST) Message-ID: <527A0582.9010505@gmail.com> Date: Wed, 06 Nov 2013 16:01:54 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: ietf@ietf.org References: <20131105184722.29536.20794.idtracker@ietfa.amsl.com> In-Reply-To: <20131105184722.29536.20794.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Nov 2013 08:58:47 -0800 Cc: "ietf@ietf.org" , roll mailing list , The IESG , roll chair , glenzorn@gmail.com, RFC Editor Subject: Re: [Roll] Document Action: 'Terms used in Ruting for Low power And Lossy Networks' to Informational RFC (draft-ietf-roll-terminology-13.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: Wed, 06 Nov 2013 09:02:05 -0000 You're joking, right? 14 revs, IESG review and still nobody asked what "Ruting" was? On 11/06/2013 01:47 AM, The IESG wrote: > The IESG has approved the following document: > - 'Terms used in Ruting for Low power And Lossy Networks' > (draft-ietf-roll-terminology-13.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 Stewart Bryant. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ > > > > > Technical Summary > > This document provides a glossary of terminology used in routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). An LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. > > Working Group Summary > > No concerns, the document had good support. > > Document Quality > > There was good support in the working group towards getting the > definitions precise enough to be useful, but not overly specific. > > This Informational document contains only terminology so cannot > be implemented, but the WG is actively using this document as a > base reference in other work. > > There is no formal language in this document. > > Personnel > > Document Shepherd: Michael Richardson > Responsible AD: Adrian Farrel > > RFC Editor Note > > Document Title > s/Ruting/Routing/ > > Section 2 Directed Acyclic Graph: > s/edge v again/vertex v again/ > > Section 2 > OLD > HVAC: Heating, Ventilation and Air Conditioning. A term applied to > the comfort level of an internal space. > NEW > HVAC: Heating, Ventilation and Air Conditioning. A term applied to > mechanisms used to maintain the comfort level of an internal space. > END > > Section 2 Sleepy Node > s/When no in/When not in/ > From samita.chakrabarti@ericsson.com Thu Nov 14 16:02:04 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB311E814D; Thu, 14 Nov 2013 16:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWlJXfTGwG5y; Thu, 14 Nov 2013 16:01:59 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB4611E8149; Thu, 14 Nov 2013 16:01:59 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-50-52856475993c Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 80.CA.04556.57465825; Fri, 15 Nov 2013 01:01:57 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 19:01:57 -0500 From: Samita Chakrabarti To: "Ralph Droms (rdroms)" , "Pascal Thubert (pthubert)" Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO3/M086twEsnn0EKJMq+TXoIX15olaQsQ Date: Fri, 15 Nov 2013 00:01:56 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> In-Reply-To: <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXSPt25pSmuQwcw/6hbNUwQsXp59z2Qx Y8o7Ros3S+ewWzRdFnBg9ZjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4MtY9XcJesFq54tmS pawNjP2yXYwcHBICJhIH9nl3MXICmWISF+6tZ+ti5OIQEjjCKLHxz0ZWCGc5o8TVyf1sIFVs AlYSHb172EFsEYFEieMrDjCCFDELdDJKfN/6HqxIWCBO4vba2cwQRfESF65+ZYWwjSQ6/75n AdnMIqAq8f6CHkiYV8BXYtPtRUwQy14xSkyZuoYRJMEpYCuxdvFusF5GoPO+n1rDBGIzC4hL 3HoynwnibAGJJXvOM0PYohIvH/9jhbCVJb7PecQCUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzC MoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgRF0TILNcQfjgk+WhxilOViUxHm/ vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIq/9d1XHSz5eToh5eFtqxu2O//tpz+5ka Xj9R4ol7lHVpxf0pB0wiC33/zXPQdLvcuZM7++j/BUenHLnOd7qn/to/Nv5VHx8eUo8OVPJ7 qPL1luRJ0+S5q2Wbrp2rma05fQnzGsHybWcXl7lP+OOf0SezL6Mv4CLbdZ+Pu1oOfNhQXl06 v8xlphJLcUaioRZzUXEiAGyLBGNuAgAA X-Mailman-Approved-At: Tue, 19 Nov 2013 08:58:47 -0800 Cc: Routing Lossy networks Over Low power and , "ipv6@ietf.org IPv6 List" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 00:02:05 -0000 Indeed, Section 4 talks about the realm-local scope for IEEE 802.15.4 "4. Definition of Realm-Local Scope for IEEE 802.15.4 When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID." In several places, I think there is a typo: s/scop /scope How about adding one or two examples in the appendix section to clarify th= e nested scope in the home-network containing two types of networks (wifi = and LLN) ? Perhaps, we expecting that LLN could have further division in sc= ope -- ie, IEEE 802.15.4 or BT-le or MS/TP networks. The example of mdns, rpl, and nd possibly will fall in different scopes.=20 Thanks, -Samita -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ral= ph Droms (rdroms) Sent: Tuesday, November 12, 2013 2:04 PM To: Pascal Thubert (pthubert) Cc: Routing Lossy networks Over Low power and; ipv6@ietf.org IPv6 List; 6lo= @ietf.org Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multic= ast-scopes-02.txt The document has been accepted as a WG work item. Check out http://www.iet= f.org/internet-drafts/draft-ietf-6man-multicast-scopes-02.txt On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: > Hello Ralph: >=20 > http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not = seem to contains the section you're inlining. The only diff I found was -sp= ecific going -local. > As we are at it, would we be ahead of ourselves if that the draft also sp= ecifies that a collection of RPL DODAGs of a same instance federated over a= n isolated backbone (such as a VLAN) in an 04 ?. >=20 > If I may add, there is kind of an habit that scopes are nested. Seems tha= t we are going away from that assumption and maybe it would be good to have= a sentence saying that? >=20 > Cheers, > Pascal >=20 > -----Original Message----- > From: 6lo-bounces@ietf.org [mailto:6lo-bounces@ietf.org] On Behalf Of=20 > Ralph Droms (rdroms) > Sent: mardi 12 novembre 2013 08:33 > To: ipv6@ietf.org IPv6 List > Cc: Routing Lossy networks Over Low power and; 6lo@ietf.org > Subject: [6lo] Fwd: New Version Notification for=20 > draft-ietf-6man-multicast-scopes-02.txt >=20 > This revision adds the definition of "scop 3" for IEEE 802.15.4 networks: >=20 > 4. Definition of Realm-Local Scope for IEEE 802.15.4 >=20 > When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to > include all interfaces sharing a PAN ID. >=20 > I've cross-posted to 6lo to get review and comment from that WG. >=20 > - Ralph >=20 >=20 > Begin forwarded message: >=20 >> From: >> Subject: New Version Notification for=20 >> draft-ietf-6man-multicast-scopes-02.txt >> Date: November 12, 2013 8:16:26 AM EST >> To: Ralph Droms >>=20 >>=20 >> A new version of I-D, draft-ietf-6man-multicast-scopes-02.txt >> has been successfully submitted by Ralph Droms and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-ietf-6man-multicast-scopes >> Revision: 02 >> Title: IPv6 Multicast Address Scopes >> Creation date: 2013-11-11 >> Group: 6man >> Number of pages: 5 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-mul= ticast-scopes-02.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-6man-multica= st-scopes >> Htmlized: http://tools.ietf.org/html/draft-ietf-6man-multicast-sc= opes-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-mult= icast-scopes-02 >>=20 >> Abstract: >> This document updates the definitions of IPv6 multicast scopes. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From samita.chakrabarti@ericsson.com Thu Nov 14 16:12:35 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7252A11E8165; Thu, 14 Nov 2013 16:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKzuZyKDkI-m; Thu, 14 Nov 2013 16:12:30 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F711E812B; Thu, 14 Nov 2013 16:12:29 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-0c-528566ebb60c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6D.69.23183.BE665825; Fri, 15 Nov 2013 01:12:27 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 19:12:27 -0500 From: Samita Chakrabarti To: Tim Chown , "Pascal Thubert (pthubert)" Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt Thread-Index: AQHO4Rrv86twEsnn0EKJMq+TXoIX15olauiw Date: Fri, 15 Nov 2013 00:12:26 +0000 Message-ID: References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <1D6AAC82-2828-402C-BE2B-9A9FF019F397@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPuO7rtNYgg9OdhhbNUwQsZvb8Y7R4 efY9k8WMKe8YLd4sncNu0XRZwOLQnudsDuweU35vZPX4u87VY8mSn0weM49/YQlgieKySUnN ySxLLdK3S+DK2PLnB2PBW9GKb5emsjUwThPqYuTkkBAwkbj47QczhC0mceHeerYuRi4OIYEj jBLNd05AOcsZJZ7u/ckEUsUmYCXR0buHHcQWEQiXOHB1MgtIEbPAU0aJ79v/soIkhAXiJG6v nc0MURQvceHqV1YI20hi2naIOIuAqsSWB3/AhvIK+Ep0X/3EAmILCbSzSKxaZQcylFOglVFi ze0XYNsYge77fmoNWAOzgLjErSfzmSDuFpBYsuc81A+iEi8f/2OFsJUlvs95xAJRryOxYPcn NghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYGmxiBsXZM gk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLhWuv99//6v mg2fey77G2nqxqvdO3XHR/LbQevVT/b2ZrmIZfG9XcO2IG9iw6LCpet+2KZo/pgdd/DyJdfJ xicCrd8cez/Lf0GJVeumNTqrJlnYPlaecC97ec0B4a0/jaem33206+6DK0p5rovFljDnXD8h NfGhw42H3+Z+16xJUzy6d+frDX6blViKMxINtZiLihMBMxWmE4MCAAA= X-Mailman-Approved-At: Tue, 19 Nov 2013 08:58:47 -0800 Cc: Brian Haberman , "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" , Routing Lossy networks Over Low power and , "Ralph Droms \(rdroms\)" Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 00:12:35 -0000 Hi Tim, >Are there use cases documented somewhere in a 6lo or 6lo-related draft? >I'm interested as we're updating the homenet text about multicast scopes.= We have agreed some text in principle with Brian for that, but it's inter= esting because we may, indeed are likely to, have 6lo networks within futur= e IPv6 home networks. [SC>] AFAIK, 6lo/6lowpan basic documents do not discuss the multicast scop= es in details.=20 [SC>] It'll be certainly helpful to document the scopes of 6lo within the s= cope of home networks or equivalent. In addition I think, it'd be really helpful for implementers if we provide = some examples of scopes of different protocols in the 6man-multicast-scopes= doc along with the pointer to RFC 4007. Thanks, -Samita > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: mercredi 13 novembre 2013 07:22 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6= @ietf.org IPv6 List; 6lo@ietf.org > Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-mult= icast-scopes-02.txt >=20 > Pascal, >=20 > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote: >> The document has been accepted as a WG work item. Check out=20 >> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-0 >> 2.txt >>=20 >>=20 >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" wrote: >>=20 >>> Hello Ralph: >>>=20 >>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does no= t seem to contains the section you're inlining. The only diff I found was -= specific going -local. >>> As we are at it, would we be ahead of ourselves if that the draft also = specifies that a collection of RPL DODAGs of a same instance federated over= an isolated backbone (such as a VLAN) in an 04 ?. >>>=20 >>> If I may add, there is kind of an habit that scopes are nested. Seems t= hat we are going away from that assumption and maybe it would be good to ha= ve a sentence saying that? >>>=20 >=20 > Scopes are still nested. See RFC 4007. Are you saying that this documen= t is changing that? >=20 > Regards, > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jmjornet@buffalo.edu Thu Nov 14 19:41:50 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5309011E8181 for ; Thu, 14 Nov 2013 19:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2VvWwl2rBzK for ; Thu, 14 Nov 2013 19:41:45 -0800 (PST) Received: from mtareserve1.acsu.buffalo.edu (mtareserve4.acsu.buffalo.edu [128.205.7.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1611E8177 for ; Thu, 14 Nov 2013 19:41:41 -0800 (PST) Received: from localmailB.acsu.buffalo.edu (localmailb.acsu.buffalo.edu [128.205.5.200]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 287DC812 for ; Thu, 14 Nov 2013 22:41:38 -0500 (EST) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24FEBB47D for ; Thu, 14 Nov 2013 22:41:38 -0500 (EST) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id 75135B478 for ; Thu, 14 Nov 2013 22:41:36 -0500 (EST) Received: from smtp.buffalo.edu (smtp1.acsu.buffalo.edu [128.205.5.253]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 703A7B477 for ; Thu, 14 Nov 2013 22:41:36 -0500 (EST) Received: from [192.168.1.126] (cpe-74-77-220-133.buffalo.res.rr.com [74.77.220.133]) (Authenticated sender: jmjornet@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id C8CC28E40 for ; Thu, 14 Nov 2013 22:41:35 -0500 (EST) From: Josep Miquel Jornet Content-Type: multipart/alternative; boundary="Apple-Mail=_939D2A8D-C60F-415C-B7C4-9421B9287614" Message-Id: <00F22D67-1979-4F42-85A4-40C3C6330B25@buffalo.edu> Date: Thu, 14 Nov 2013 22:41:35 -0500 To: roll@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-PM-EL-Spam-Prob: XX: 27% X-Mailman-Approved-At: Tue, 19 Nov 2013 08:58:47 -0800 Subject: [Roll] ACM NANOCOM 2014 - 1st ACM International Conference on Nanoscale Computing and Communication - Call for Papers 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, 15 Nov 2013 03:45:35 -0000 --Apple-Mail=_939D2A8D-C60F-415C-B7C4-9421B9287614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 ________________________________________________________________ ________________________________________________________________ Call for Papers ACM NANOCOM 2014=20 1st ACM International Conference on Nanoscale Computing and = Communication http://nanocom.acm.org May 13th - 14th, 2014 =09 Atlanta, USA Submission deadline: December 10, 2013 ________________________________________________________________ ________________________________________________________________ The 1st ACM International Conference on Nanoscale Computing and=20 Communication (ACM NANOCOM 2014) will be held on May 13th - 14th in=20 Atlanta, Georgia, USA. The aim of the conference is to bring together=20 researchers from diverse disciplines that can foster and develop new=20 communications and computing paradigms for nanoscale devices.=20 Due to this highly inter-disciplinary field of research, the conference=20= aims to attract researchers and academics from various fields of study=20= such as electrical and electronic engineering, computer science, = biology,=20 chemistry, physics, mathematics, bio-engineering, bio-technology,=20 materials science, nanotechnology, who have an interest in computing=20 and communications at the nanoscale. We invite submissions to ACM NANOCOM 2014 with original (unpublished and=20= not currently under review) and novel contributions on nanoscale=20 communication in areas including (but not limited to), the following: * Nano-Electromagnetic (EM) communication [ Graphene based nano-antennas; modeling of EM channels; terahertz band=20= communications.] * Infrastructure for molecular communication nanonetworks [ Molecular diffusion; flagellated bacteria; molecular motors.] * Information theoretical approaches to nanoscale communication [ Information/network information theory modeling; capacity bounds and theorems for various nanoscale channels; transceiver and modulation optimization; nanoscale and molecular source and channel coding.] * Protocols and architectures for nano communications [ Network architectures; topologies; coverage/connectivity; relay,=20 broadcast and MAC mechanisms; synchronization; routing/addressing; reliable information coding; error control; energy efficiency.] * Nano computing [ DNA, enzyme, and membrane computing; nano/molecular electronics.] * Internet of Nano Things (IoNT) [ Service and application models for nano things; middleware design for=20= nanonetwork interface; security for nano communication networks;=20 wearable nanoscale sensor networks; software and programming=20 paradigms for nanonetworks.] * Privacy, Security and Trust in nanonetworks * Future emerging applications of nano/molecular communication [ Smart Health and Big Data; Smart City; Sports Applications and=20 Systems.] Submission Instructions and Important Dates: ________________________________________________________________ Papers submitted to ACM NANOCOM 2014 must be original, not previously=20 published or accepted for publication elsewhere, and they must not be=20 submitted to any other event or publication during the entire review=20 process. Paper submissions should follow the ACM double-column format=20 for conferences:=20 (http://www.acm.org/sigs/publications/proceedings-templates).=20 A maximum of 9 pages are allowed for each paper, all figures and=20 references included. Submitted papers will undergo a peer review=20 process, coordinated by the Program Committee. All accepted paper will=20= be published by ACM and submitted for indexing by ISI, EI Compendex,=20 Scopus, Google Scholar and many more. In addition to the main=20 conference, ACM NANOCOM 2014 will also have a series of special tracks=20= and poster sessions. Full Papers Due: December 10, 2013 Notification of Acceptance: February 15, 2014 Camera Ready Papers Due: April 1, 2014 General Co-Chairs: ________________________________________________________________ Ian F. Akyildiz (ian@ece.gatech.edu) =20 Georgia Institue of Technology, USA Raghupathy Sivakumar (siva@ece.gatech.edu) Georgia Institute of Technology, USA General Vice-Chair: ________________________________________________________________ Faramarz Fekri (faramarz.fekri@ece.gatech.edu) Georgia Institute of Technology, USA TPC Co-Chairs: ________________________________________________________________ Sasitharan Balasubramaniam (sasi.bala@tut.fi) =20 Tampere University of Technology, Finland Ozgur B. Akan (akan@ku.edu.tr) Koc University, Turkey Albert Cabellos-Aparicio (acabello@ac.upc.edu) Universitat Polit=E8cnica de Catalunya, Spain --=20 = --------------------------------------------------------------------------= -- Josep Miquel Jornet Assistant Professor Department of Electrical Engineering University at Buffalo, The State University of New York Office: 209 Davis Hall Buffalo, NY 14260 Tel: (716) 645-1607 Email: jmjornet@buffalo.edu Web: http://www.buffalo.edu/~jmjornet/ = --------------------------------------------------------------------------= --= --Apple-Mail=_939D2A8D-C60F-415C-B7C4-9421B9287614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ______________________________________________________= __________
____________________________________________________________= ____

          &n= bsp;           &nbs= p;            =             &n= bsp;  Call for = Papers

          =             &n= bsp;           &nbs= p;       ACM NANOCOM = 2014 

1st ACM International Conference on Nanoscale = Computing and = Communication

         = ;            &= nbsp;           &nb= sp;       http://nanocom.acm.org

 &n= bsp;           &nbs= p;            =             &n= bsp;    May 13th - 14th, 2014
=
          &nb= sp;            = ;            &= nbsp;           &nb= sp;   Atlanta, = USA

          &nb= sp;            = ;      Submission deadline: December 10, = 2013
________________________________________________________________________________________________________________________________

=
The 1st ACM International Conference on Nanoscale Computing = and 
Communication (ACM NANOCOM 2014) will be held on May 13th - = 14th in 
Atlanta, Georgia, USA. The aim of the conference is to = bring together 
researchers from diverse disciplines that can = foster and develop new 
communications and computing paradigms = for nanoscale devices. 

Due to this highly = inter-disciplinary field of research, the conference 
aims to = attract researchers and academics from various fields of = study 
such as electrical and electronic engineering, computer = science, biology, 
chemistry, physics, mathematics, = bio-engineering, bio-technology, 
materials science, = nanotechnology, who have an interest in computing 
and = communications at the nanoscale.

We invite submissions to ACM = NANOCOM 2014 with original (unpublished and 
not currently under = review) and novel contributions on nanoscale 
communication in = areas including (but not limited to), the following:

* = Nano-Electromagnetic (EM) communication
[ Graphene based = nano-antennas; modeling of EM channels; terahertz = band 
communications.]

* Infrastructure for molecular = communication nanonetworks
[ Molecular diffusion; flagellated = bacteria; molecular motors.]

* Information theoretical approaches = to nanoscale communication
[ Information/network information theory = modeling; capacity bounds and
 theorems for various nanoscale = channels; transceiver and modulation
 optimization; nanoscale = and molecular source and channel coding.]

* Protocols and = architectures for nano communications
[ Network  architectures; =  topologies;  coverage/connectivity; = relay, 
 broadcast and MAC mechanisms; synchronization; = routing/addressing;
 reliable information coding; error control; = energy efficiency.]

* Nano computing
[ DNA, enzyme, and = membrane computing; nano/molecular electronics.]

* Internet of = Nano Things (IoNT)
[ Service and application models for nano things; = middleware design for 
 nanonetwork interface; security for = nano communication networks; 
 wearable nanoscale sensor = networks; software and programming 
 paradigms for = nanonetworks.]

* Privacy, Security and Trust in = nanonetworks

* Future emerging applications of nano/molecular = communication
[ Smart Health and Big Data; Smart City; Sports = Applications and 
 Systems.]


Submission = Instructions and Important = Dates:

____________________________________________________________= ____

Papers submitted to ACM NANOCOM 2014 must be original, not = previously 
published or accepted for publication elsewhere, and = they must not be 
submitted to any other event or publication = during the entire review 
process. Paper submissions should = follow the ACM double-column format 
for = conferences: 

(http:/= /www.acm.org/sigs/publications/proceedings-templates). 

A = maximum of 9 pages are allowed for each paper, all figures = and 
references included. Submitted papers will undergo a peer = review 
process, coordinated by the Program Committee. All = accepted paper will 
be published by ACM and submitted for = indexing by ISI, EI Compendex, 
Scopus, Google Scholar and many = more. In addition to the main 
conference, ACM NANOCOM 2014 will = also have a series of special tracks 
and poster = sessions.


Full Papers Due: =             &n= bsp;           &nbs= p;       December 10, = 2013

Notification of Acceptance: =             &n= bsp; February 15, 2014

Camera Ready Papers Due: =            April = 1, 2014



General = Co-Chairs:
____________________________________________________________= ____

Ian F. Akyildiz  (ian@ece.gatech.edu) =  
Georgia Institue of Technology, USA

Raghupathy = Sivakumar (siva@ece.gatech.edu)
Georgia = Institute of Technology, USA


General = Vice-Chair:
___________________________________________________________= _____

Faramarz Fekri (faramarz.fekri@ece.gatech.ed= u)
Georgia Institute of Technology, USA


TPC = Co-Chairs:
____________________________________________________________= ____

Sasitharan Balasubramaniam  (sasi.bala@tut.fi)  
Tampere = University of Technology, Finland

Ozgur B. Akan (akan@ku.edu.tr)
Koc University, = Turkey

Albert Cabellos-Aparicio (acabello@ac.upc.edu)
Universita= t Polit=E8cnica de Catalunya, = Spain


-- 
---------------------------------------------= -------------------------------
Josep Miquel Jornet
Assistant = Professor
Department of Electrical Engineering
University at = Buffalo, The State University of New York
Office: 209 Davis = Hall
Buffalo, NY 14260
Tel: (716) 645-1607
Email: jmjornet@buffalo.edu
Web: = ;http://www.buffalo.edu/~jmjorne= t/
----------------------------------------------------------------= ------------= --Apple-Mail=_939D2A8D-C60F-415C-B7C4-9421B9287614-- From trac+roll@trac.tools.ietf.org Mon Nov 25 19:05:19 2013 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 6CF241AE148 for ; Mon, 25 Nov 2013 19:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 32Y_E3ohV39f for ; Mon, 25 Nov 2013 19:05:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 629131AE147 for ; Mon, 25 Nov 2013 19:05:17 -0800 (PST) Received: from localhost ([127.0.0.1]:52352 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vl8xY-0004vA-7L; Tue, 26 Nov 2013 04:05:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Tue, 26 Nov 2013 03:05:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:18 Message-ID: <082.4c4b1741dab1411728e603cea9f9c0d1@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 03:05:19 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): '''Related to draft-ietf-6man-multicast-scopes-02 http://www.ietf.org/mail- archive/web/6lo/current/msg00304.html >On 15/11/2013 00:31, Kerry Lynn wrote: >… >One could take that argument to the extreme and say that selecting SSID (802.11) or plugging into a wall socket (802.3) is an administrative act. Let's not be too literal and instead say that the "automatic" zone boundary definition applies to an existing LAN. If you think about a Link-Local zone, it is defined as a set of physically connected interfaces and the zone boundary is defined by a *lack* of forwarding (see [RFC4291] section 2.5.6). I think if there is a need for scope value 3 it is to provide classic Link-Local multicast behavior vover a connected mesh. I think the definition should be independent of RPL and instead depend on some "L2 instance" definition. PAN ID works for 802.15.4 networks. +1 - how PAN ID is assigned does not constitute "administratively configured" as it is a layer 2 concept. >draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based on PAN ID. The latest version makes no mention at all of RPL. Agree that RPL should not be mentioned here. >I think the understanding that was reached at dinner last week is that, under certain circumstances, policy can count as "administratively configured". Thus, if a RPL instance contained several PAN IDs then the former could be used as the basis of a scop 4 zone as long as if fully enclosed the PANs (scop 3 zones).OTOH, if a given PAN contains multiple RPL instances then the latter cannot be used to define a scop 4 zone boundary because that would violate the RFC 4007 constraints that Brian enumerated. MPL is orthogonal to RPL DODAGs. If there is a requirement to reach all nodes in a RPL DODAG which spans multiple 802.15.4 PANs, then that would be administratively configured and scope 4. If a RPL DODAG is wholly contained within the PAN ID then there would need to be some additional discriminator to limit propagation among a node set smaller than that of all nodes with the same PAN ID. In other words, it cannot be limited by just scope, which is too coarse a measurement. MPL doesn't cater for this as MPL Domains are defined as scope zones. http://www.ietf.org/mail-archive/web/roll/current/msg08361.html > On 15 Nov 2013, at 00:12, Samita Chakrabarti wrote: > >> Hi Tim, >> >>> Are there use cases documented somewhere in a 6lo or 6lo-related draft? >> >>> I'm interested as we're updating the homenet text about multicast scopes. We have agreed some text in principle with Brian for that, but it's interesting because we may, indeed are likely to, have 6lo networks within future IPv6 home networks. >> >> [SC>] AFAIK, 6lo/6lowpan basic documents do not discuss the multicast scopes in details. >> [SC>] It'll be certainly helpful to document the scopes of 6lo within the scope of home networks or equivalent. >> In addition I think, it'd be really helpful for implementers if we provide some examples of scopes of different protocols in the 6man- multicast-scopes doc along with the pointer to RFC 4007. Samita - I don't understand what you're suggesting as "scopes of different protocols in the 6man-multicast-scopes". Do you mean examples of the definition of scope 3 for various L2 technologies? - Ralph -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From adrian@olddog.co.uk Tue Nov 26 03:37:21 2013 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 1A4201AE1BC for ; Tue, 26 Nov 2013 03:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOEdFwCDFIj5 for ; Tue, 26 Nov 2013 03:37:19 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 71C601AD8D8 for ; Tue, 26 Nov 2013 03:37:19 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQBbFo3025337; Tue, 26 Nov 2013 11:37:15 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQBbB9V025309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 11:37:14 GMT From: "Adrian Farrel" To: Date: Tue, 26 Nov 2013 11:37:11 -0000 Message-ID: <047501ceea9b$daae9cb0$900bd610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7qm4ceH2cPf+MFR3u5TIIkFBXoCw== Content-Language: en-gb Cc: Michael Richardson , mariainesrobles@googlemail.com Subject: [Roll] Working group chairs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 11:37:21 -0000 Hi ROLL, JP Vasseur has served as ROLL WG chair since the working group was created. In fact he also drove the BoF that led to the working group and working first with David Cullen and more recently with Michael Richardson, JP led the working group through the development of a broad set of requirements and specification of RPL which has now seen some significant interop testing and deployments. But JP now tells me he is a bit too busy to give the WG the attention it deserves and he wants to step down so that someone else can help run the group. Ines Robles has been serving as working group secretary for a relatively short time, and she has already made an impact keeping an eye on the tasks and shepherding a couple of documents. At this stage in the WG's work cycle this is exactly the set of skills we need push the remaining documents forward and to make sure that all of the issues are tracked correctly, so I am happy to appoint Ines as the new co-chair of ROLL to work alongside Michael Richardson. Many thanks to JP for his work, and good luck to Ines. Thanks, Adrian From mariainesrobles@googlemail.com Tue Nov 26 13:00:34 2013 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 11A361AD9AE for ; Tue, 26 Nov 2013 13:00:34 -0800 (PST) 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 Btjgvif5_6iJ for ; Tue, 26 Nov 2013 13:00:32 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD41AD957 for ; Tue, 26 Nov 2013 13:00:32 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id p6so4347046vbe.13 for ; Tue, 26 Nov 2013 13:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=idftZv2zvS2P+8sR5luYy4ejecGeUryWAJTFaBO314E=; b=QFs76zIWMoPKZOxIqgwX1H6h5vKphmird21nWeD+LUWg7GqWvoVbieN3mpQ/xpdu4e DJFKxAkHgIRgT2V9r3QPDdiT+5nnf77eFTm6AZnYkZ9bbo3Nda5VWUtSZbVvKJwMXo6e 2HYOmRg7BopEj8kQvkzL+7W7yPSh2mi/sEVbTo5bAE6URKOnwqjxRka3abqDKqdmGtY3 /bbXE80QsMs/rHnX7lRvLt7pJyP3y82gw2zFxywrGt/rqgMHP7oE3K8UyaZkZpWzt9MG ThpsObcEMtz8TNWIiHpZkPODoSVf5MmV77PIW/xbbk4zrYmhvwr+dAjJaZwOjilQ6HjY qXVA== MIME-Version: 1.0 X-Received: by 10.52.28.78 with SMTP id z14mr338782vdg.54.1385499632151; Tue, 26 Nov 2013 13:00:32 -0800 (PST) Received: by 10.220.242.82 with HTTP; Tue, 26 Nov 2013 13:00:32 -0800 (PST) In-Reply-To: <047501ceea9b$daae9cb0$900bd610$@olddog.co.uk> References: <047501ceea9b$daae9cb0$900bd610$@olddog.co.uk> Date: Tue, 26 Nov 2013 19:00:32 -0200 Message-ID: From: Ines Robles To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf3079ba8a69318704ec1ac534 Cc: Michael Richardson , roll@ietf.org Subject: Re: [Roll] Working group chairs 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, 26 Nov 2013 21:00:34 -0000 --20cf3079ba8a69318704ec1ac534 Content-Type: text/plain; charset=ISO-8859-1 *Hi,Thank you very much to Adrian, Michael and JP.I remain at your disposal in anything that you need.Kind Regards and thanks again, Ines* 2013/11/26 Adrian Farrel > Hi ROLL, > > JP Vasseur has served as ROLL WG chair since the working group was > created. In > fact he also drove the BoF that led to the working group and working first > with > David Cullen and more recently with Michael Richardson, JP led the working > group > through the development of a broad set of requirements and specification > of RPL > which has now seen some significant interop testing and deployments. > > But JP now tells me he is a bit too busy to give the WG the attention it > deserves and he wants to step down so that someone else can help run the > group. > > Ines Robles has been serving as working group secretary for a relatively > short > time, and she has already made an impact keeping an eye on the tasks and > shepherding a couple of documents. At this stage in the WG's work cycle > this is > exactly the set of skills we need push the remaining documents forward and > to > make sure that all of the issues are tracked correctly, so I am happy to > appoint > Ines as the new co-chair of ROLL to work alongside Michael Richardson. > > Many thanks to JP for his work, and good luck to Ines. > > Thanks, > Adrian > > --20cf3079ba8a69318704ec1ac534 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,


Thank you very much to Adr= ian, Michael and JP.


I remain at your disposal = in anything that you need.


Kind Regards and thanks ag= ain,


Ines


2013/11/26 Ad= rian Farrel <adrian@olddog.co.uk>
Hi ROLL,

JP Vasseur has served as ROLL WG chair since the working group was created.= In
fact he also drove the BoF that led to the working group and working first = with
David Cullen and more recently with Michael Richardson, JP led the working = group
through the development of a broad set of requirements and specification of= RPL
which has now seen some significant interop testing and deployments.

But JP now tells me he is a bit too busy to give the WG the attention it deserves and he wants to step down so that someone else can help run the gr= oup.

Ines Robles has been serving as working group secretary for a relatively sh= ort
time, and she has already made an impact keeping an eye on the tasks and shepherding a couple of documents. At this stage in the WG's work cycle= this is
exactly the set of skills we need push the remaining documents forward and = to
make sure that all of the issues are tracked correctly, so I am happy to ap= point
Ines as the new co-chair of ROLL to work alongside Michael Richardson.

Many thanks to JP for his work, and good luck to Ines.

Thanks,
Adrian


--20cf3079ba8a69318704ec1ac534-- From mariainesrobles@googlemail.com Fri Nov 29 08:01:43 2013 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 0C65F1AE01E for ; Fri, 29 Nov 2013 08:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 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, J_CHICKENPOX_74=0.6, 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 pWdI3zEH6Yz3 for ; Fri, 29 Nov 2013 08:01:42 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0B1AC4C5 for ; Fri, 29 Nov 2013 08:01:41 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so6915576veb.8 for ; Fri, 29 Nov 2013 08:01:40 -0800 (PST) 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=vcqu6cYGckxeI+5iYPeb1RmhTwQIAULV+kFxf5L9/zE=; b=oUN1XLQaNfAJd82/hg01J5/gZcgmKR1bBow2yiN8IRBuxWRKooV20puqF9P910eTG7 0gZch77MMYe9Hsa0p1eWinqNuBmSUbE+L9tgRWOGea8MF2vgfeZg2sjvdlHPzRJklTW/ 0rB7u06RGpc3k5ie/CT9jkk4i8jQacUnGIhzPcrpmviCoMn9WGBYlJpLYv7JY8RLlYv5 reNZLIq6dmP4JDltczJDxd/40iccZtj9vHWeOItw61DBo22LRO9G9GLq83ZEqXzxbCq/ +KlER38CXBXApfOw9YXwEgpbZzvsks/9SreRdXK4wtcB7VnOwtWNd+FnvJKU3pa/XLKW /cNw== MIME-Version: 1.0 X-Received: by 10.58.228.231 with SMTP id sl7mr835489vec.49.1385740900527; Fri, 29 Nov 2013 08:01:40 -0800 (PST) Received: by 10.220.242.82 with HTTP; Fri, 29 Nov 2013 08:01:40 -0800 (PST) Date: Fri, 29 Nov 2013 14:01:40 -0200 Message-ID: From: Ines Robles To: roll@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6b4b22073eb04ec52f29b Cc: Michael Richardson Subject: [Roll] Looking for Document Shepherd 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, 29 Nov 2013 16:01:43 -0000 --047d7bd6b4b22073eb04ec52f29b Content-Type: text/plain; charset=ISO-8859-1 *Hello,We would like to know please, who would be interested to be a Document shepherd.Thank you in advance,Kind Regards,Ines Robles* --047d7bd6b4b22073eb04ec52f29b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,


We would = like to know please, who would be interested to be a Document shepherd.


Thank you= in advance,


Kind Rega= rds,


Ines Robl= es
--047d7bd6b4b22073eb04ec52f29b-- From ietf-secretariat-reply@ietf.org Fri Nov 29 07:18:36 2013 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 92E8D1AD94A for ; Fri, 29 Nov 2013 07:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neWUmYgX7-U8 for ; Fri, 29 Nov 2013 07:18:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B891ADBCD for ; Fri, 29 Nov 2013 07:18:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131129151833.22130.61219.idtracker@ietfa.amsl.com> Date: Fri, 29 Nov 2013 07:18:33 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 29 Nov 2013 12:40:25 -0800 Subject: [Roll] Milestones changed for roll WG 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, 29 Nov 2013 15:18:36 -0000 Changed milestone "Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/roll/charter/ From ietf-secretariat-reply@ietf.org Fri Nov 29 07:22:49 2013 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 78D6D1ADBCD for ; Fri, 29 Nov 2013 07:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afJHZbzl5rjg for ; Fri, 29 Nov 2013 07:22:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1F1ADF7E for ; Fri, 29 Nov 2013 07:22:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131129152246.21356.16485.idtracker@ietfa.amsl.com> Date: Fri, 29 Nov 2013 07:22:46 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 29 Nov 2013 12:40:25 -0800 Subject: [Roll] Milestones changed for roll WG 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, 29 Nov 2013 15:22:49 -0000 Changed milestone "WG to adopt RPL applicability statement for Industrial applications", resolved as "Done", added draft-ietf-roll-rpl-industrial-applicability to milestone. Changed milestone "WG to adopt RPL applicability statement Home for Automation applications", resolved as "Done", added draft-ietf-roll-applicability-home-building to milestone. Changed milestone "WG to adopt RPL applicability statement(s) for AMI networks", resolved as "Done", added draft-ietf-roll-applicability-ami to milestone. Deleted milestone "WG to adopt RPL applicability statement Building Automation applications ". Deleted milestone "Submit first draft of RPL applicability statement for Industrial applications to the IESG to be considered as an Informational RFC". Deleted milestone "Submit RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC". Deleted milestone "Submit first draft of RPL applicability statement for Building Automation applications to the IESG to be considered as an Informational RFC". Changed milestone "Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC", set due date to February 2014 from February 2013. Changed milestone "Evaluate WG progress, recharter or close", set due date to June 2014 from June 2013. URL: http://datatracker.ietf.org/wg/roll/charter/ From ietf-secretariat-reply@ietf.org Fri Nov 29 07:24:54 2013 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 C4DC91ADF7E for ; Fri, 29 Nov 2013 07:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_l4OWZsPZJA for ; Fri, 29 Nov 2013 07:24:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1F41ADF9D for ; Fri, 29 Nov 2013 07:24:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131129152452.20859.98752.idtracker@ietfa.amsl.com> Date: Fri, 29 Nov 2013 07:24:52 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 29 Nov 2013 12:40:25 -0800 Subject: [Roll] Milestones changed for roll WG 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, 29 Nov 2013 15:24:54 -0000 URL: http://datatracker.ietf.org/wg/roll/charter/ From ietf-secretariat-reply@ietf.org Fri Nov 29 08:18:24 2013 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 78AF21A1F5F for ; Fri, 29 Nov 2013 08:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJjBMtNqmzgL for ; Fri, 29 Nov 2013 08:18:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF461ADEA3 for ; Fri, 29 Nov 2013 08:18:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131129161821.28538.12100.idtracker@ietfa.amsl.com> Date: Fri, 29 Nov 2013 08:18:21 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 29 Nov 2013 12:40:26 -0800 Subject: [Roll] Milestones changed for roll WG 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, 29 Nov 2013 16:18:24 -0000 Changed milestone "Resolve question of whether to keep this in roll or 6tisch", set state to active from review, accepting new milestone. Changed milestone "submit REVISED thread-analysis document based upon security directorate review to IESG.", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/roll/charter/ From ietf-secretariat-reply@ietf.org Fri Nov 29 10:08:06 2013 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 173CC1AE119 for ; Fri, 29 Nov 2013 10:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLRnWb3Vj9Y6 for ; Fri, 29 Nov 2013 10:08:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A561AE17E for ; Fri, 29 Nov 2013 10:08:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131129180803.8472.70583.idtracker@ietfa.amsl.com> Date: Fri, 29 Nov 2013 10:08:03 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 29 Nov 2013 12:40:26 -0800 Subject: [Roll] Milestones changed for roll WG 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, 29 Nov 2013 18:08:06 -0000 Deleted milestone "WG to adopt reviewed template for applicability statements". URL: http://datatracker.ietf.org/wg/roll/charter/