From pthubert@cisco.com Fri Mar 1 06:58: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 A146311E80AD; Fri, 1 Mar 2013 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aki9fNP86e-f; Fri, 1 Mar 2013 06:58:20 -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 B793421F9269; Fri, 1 Mar 2013 06:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8663; q=dns/txt; s=iport; t=1362149900; x=1363359500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=khM1j521TtGgKW8Vb7S0/pvRydjSkP8GOwHDmAze77w=; b=hXxAonT/QQ9PXx3kUdAL29OuTOdtRl9cjk3wWT9a6N8I6tPsLAGvGtc4 O3f4g7FA5/2JZ3Q5u2hwCYGBQhGWcoxcnUKFcL3dwW3f9Gz2+kz5ONEF9 RVyocP0YJfuiEqteLtt3uswhabdvXBC2ytF9u1Z61IMz2A0PFjTXDgMAN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABzBMFGtJV2Z/2dsb2JhbABEwjN8FnOCHwEBAQMBOj8FCwIBCCICEhAyJQIEAQkEDQGIBAYMwQqHEYYygSAxB4JfYQOTApQsgwiBcjU X-IronPort-AV: E=Sophos;i="4.84,761,1355097600"; d="scan'208";a="182669861" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 01 Mar 2013 14:58:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r21EwHP0030923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 14:58:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 08:58:17 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "roll@ietf.org" , "Tom Phinney (tom.phinney@COX.NET)" Thread-Topic: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability Thread-Index: AQHOFeOzAFgeSP3LvEeUZPv2g83+c5iQtCMA Date: Fri, 1 Mar 2013 14:58:16 +0000 Deferred-Delivery: Fri, 1 Mar 2013 14:58:00 +0000 Message-ID: References: <20381.1362077015@sandelman.ca> In-Reply-To: <20381.1362077015@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Mar 2013 14:58:27 -0000 Dear Michael: [Pascal] Thanks for the comments : ) {this email was written in several sittings over 10 days. Probably I missed= some stuff} Section 1.3 says: 1.3. Out of scope requirements This applicability statement does not address requirements related to wireless LLNs employed in factory automation and related applications. So, as I understand things, this document applies to *plants*, but not automated factories. Forgive me for my ignorance, but I guess this means it applies to a oil refinery or chemical plant, but not to a car manu= facturer. (Even though, we call them "auto plants") I'm just trying to understand where the line is and why. [Pascal] You are correct. The industry makes a difference between Factory A= utomation (discrete manufacturing of individual products) and Process Contr= ols (continuous production). These are really 2 different activities, and F= actory Automation may require much stricter behaviors for very rapid operat= ions. At ISA, WG 11 has standardized ISA100.11a for Process Control, and the info= rmation you find in the draft leverages that experience. WG16 has been work= ing on Factory Automation. =3D=3D=3D=3D >The domain of applicability for the RPL protocol may include all > phases but the Normal Operation phase, where the bandwidth allocation > and the routes are usually optimized by an external Path Computing > Engine (PCE), e.g. an ISA100.11a System Manager. So, RPL could be used during phases P1, P2, P4, P5 and P6, but not during P= 3, (Normal Operation), unless a new OF was defined that interacted with the= PCE? [Pascal] Roughly yes, and this is the work we are starting at 6TSCH. In mor= e details, there will be flows that can use distributed routing but critica= l flows will need the PCE. (Last time I read the document, I was sure it said that LLNs could be used = only during P3) Given that, I guess the "X" in figure 1 means that RPL *can* be used? section 2.1.2 then says: For factory automation networks, the basic communications cycle for control is typically much faster, on the order of 100 Hz or more. but, I thought factory automation was out of scope? [Pascal] Yes, still this is good info.=20 =3D=3D=3D=3D=3D section 2.1.3: I think that I'm confused about Source-Sink(SS) vs Peer-to-multipeer(P2MP) = given that 2.1.3 says that the sink is usually a multicast address. Is the distinction that in P2MP multiple packets are unicast? Or is the distinction that P2MP is primary from outside the LLN, downward i= nto the LLN, while SS is within the LLN? [Pascal] let me quote Tom here: " There are three distinct paradigms used for the bulk of industrial automat= ion and control communication: 1) publish/subscribe, where an association exists between one source and on= e or a few recipients, all of which are identifiable, where publication is = periodic within strict time limits (though sometimes instances are suppress= ed due to source compression of the stream). When pub/sub is used for close= d-loop control, it is subject to timing attacks where deliberately induced = message delivery jitter can destabilize a control loop. Sequentiality and n= on-loss are insufficient to detect this; it must be based on source time st= amping , such as transport time-of-origination time stamping, that is check= ed at the receiver, or the equivalent, to discard anything that is not rece= ived within the proper cycle. In essence there is a fixed-acceptable-delay = pipeline between the publisher and the subscriber, generally with a transit= delay less than twice the publication period. COAP does not appear to be s= uitable for this communication paradigm without additional augmentation. 2) source/sink, where any of a number of sources logically multicasts (howe= ver that is implemented) to a predefined group address for the sinks, where= the membership in that group is time-varying and unknown to the sources. T= ransport time-of-origination time stamps here are used for message authenti= cation and perhaps in conjunction with source compression of related-interv= al time stamps in the application messaging. Arrival order and timing is of= relatively little interest here, as is message loss detection (except for = whatever impact that latter might have on security alerting).=20 3) client/server or peer/peer, where all of the traditional properties hold= and the specialized ones listed above generally do not. " My understanding is that this is more an upper layer paradigm then a routin= g issue. Pub/sub relates to periodic data that can be buffered to be read a= synchronously, like the periodic publication of a measurement. Tom? =3D=3D=3D=3D=3D=3D Or is it that the source is always on the LLN, and the sink is always elsew= here, and the fact that it's a multicast/anycast destination is just a ques= tion of how to implement redundancy in the data collection systems?=20 [Pascal] Not just redundancy. You might have a copy for a local actuator an= d a copy for a supervisory system, a log... page 13, section 2.1.4: says:=20 With rare exception, the control algorithms used with PS messaging in the process automation industries - those managing continuous material flows - rely on fixed-period sampling, computation and transfer of outputs, while those in the factory automation industries - those managing discrete manufacturing operations - rely on bounded delay between sampling of inputs, control computation and transfer of outputs to physical actuators that affect the controlled process. it seems that there are possibly two completely different industrial requir= ements here which can not, and should not, be satisfied with a single DAG. = Are two documents appropriate here? [Pascal] It is more than a different DAG, it is a different plant... I read= your question as do we want an additional draft for factory automation?=20 =3D=3D=3D=3D=3D > Note: Although there are known patent applications for duocast and > N-cast, at the time of this writing the patent assignee, Honeywell > International, has offered to permit cost-free RAND use in those > industrial wireless standards that have chosen to employee the > technology, under a reciprocal licensing requirement relative to that > use. =20 Can we get an official IPR statement via: http://www.ietf.org/ipr/file-disclosure on this? I don't think it is particularly relevant to the document, but pe= rhaps I could be wrong. you need to update [I-D.ietf-roll-rpl] to RFC6550. [Pascal] Done in 03 : ) 4.3.1 says: > Because the actual link capacity depends on the particular link=20 > technology used within an industrial automation network deployment,=20 > the Trickle parameters are specified in terms of the link's maximum=20 > capacity for conveying link-local multicast messages. If the link can=20 > convey m link-local multicast packets per second on average, the=20 > expected time it takes to transmit a link-local multicast packet is=20 > 1/m seconds. I am pleased that a formula is being provided, but I am uncomfortable that = this document is not more specific to actual link technology used. Can this document pick 1-2 actual link technologies and deal with them? [Pascal] We are working on those concepts at 6TSCH, ccing the ML. =3D=3D=3D=3D=3D=3D=3D=3D 5.: > The possibility of dynamically updating the metrics in use in the > network as well as the frequency of network updates allows deployment > characteristics (e.g., network density) to be discovered during > network bring-up and to be used to tailor network parameters once the > network is operational rather than having to rely on precise pre- > configuration. This also allows the network parameters and the > overall routing protocol behavior to evolve during the lifetime of > the network. I don't know how this discovery is going to occur. Someone trying to build a sensor that is going to satisfy an RFP for device= s to work in a network envisioned by this document needs to know what to include in their code base. As the code space is very finite, they need to know exactly what is important here. [Pascal] Finding the values for parameters is more of a deployment issue, s= o I read your question as 'which parameters are critical for the device to = operate in industrial environment and which range for those parameters'. Ag= ain, work at 6TSCH may help. Cheers, Pascal From pthubert@cisco.com Fri Mar 1 08:22: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 5C73821F93AD for ; Fri, 1 Mar 2013 08:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE4qoqb7B7m4 for ; Fri, 1 Mar 2013 08:22:39 -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 9819F21F93AC for ; Fri, 1 Mar 2013 08:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1145; q=dns/txt; s=iport; t=1362154959; x=1363364559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pXb6MWlgSPuYeafihFlCfUyylQdSH4oh4j2MLnCkPRA=; b=HugxdeMcCID37ZwLQ1mbwGHgRliMlykC2XEVZE+B686fn013OPnAe887 Eb3lklJSVMcLYEscMES9HPcdwcpDOhhgrpGBLYnglv+1esC6drtVTswV7 MidRv5NwLUATSOzmyAmqCB2SQbwE2WMCec3itkA3G6lD+QA/w31gkNmub Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN7UMFGtJXG//2dsb2JhbABEwjZ+FnOCHwEBAQRuCwwEAgEIEQQBAQsdBzIUCQgCBAENBQgBiAoMwRWNU4EQJgsCBQaCWWEDiDWPLI9NgwiBcjU X-IronPort-AV: E=Sophos;i="4.84,762,1355097600"; d="scan'208";a="182704247" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 01 Mar 2013 16:22:39 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r21GMd1s019073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 16:22:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 10:22:38 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-applicability-01 Thread-Index: AQHOFeOic4Xw+r2OEEa4Epe9sBVaR5iRBctQ Date: Fri, 1 Mar 2013 16:22:37 +0000 Deferred-Delivery: Fri, 1 Mar 2013 16:22:00 +0000 Message-ID: References: <17078.1361386986@sandelman.ca> <20285.1362076983@sandelman.ca> In-Reply-To: <20285.1362076983@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tom Phinney \(tom.phinney@COX.NET\)" , Robert Assimiti Subject: Re: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-applicability-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Mar 2013 16:22:40 -0000 Will do; Thanks a bunch Michael. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: jeudi 28 f=E9vrier 2013 19:43 To: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-appl= icability-01 This thread is at http://www.ietf.org/mail-archive/web/roll/current/msg0775= 5.html had only 1 message which was a +1. There were no objections. In addition to being announced in this WG, this document was also brought u= p in the 6tsch mailing list, which is looking at deterministic mechanisms t= hat may be required by industrial applications. As no participant express a view that the document was an inappropriate sta= rt, or that it was out of scope for the working group. The view of the chairs is to adopt the document. If the authors could repost it as draft-ietf-roll-applicability-industrial-00 on March 11, when the ID site r= eopens. -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Fri Mar 1 10:35: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 3D7C321F90EE; Fri, 1 Mar 2013 10:35:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK0Lksdrv-Qj; Fri, 1 Mar 2013 10:35:40 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7A21F9040; Fri, 1 Mar 2013 10:35:36 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D99220168; Fri, 1 Mar 2013 13:42:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E5E0C63A5B; Fri, 1 Mar 2013 13:34:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D028263769; Fri, 1 Mar 2013 13:34:23 -0500 (EST) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: References: <20381.1362077015@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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: "6tsch@ietf.org" <6tsch@ietf.org>, "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Mar 2013 18:35:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "pthubert" =3D=3D pthubert writes: pthubert> [Pascal] Thanks for the comments : ) pthubert> [Pascal] You are correct. The industry makes a difference pthubert> between Factory Automation (discrete manufacturing of pthubert> individual products) and Process Controls (continuous pthubert> production). These are really 2 different activities, and pthubert> Factory Automation may require much stricter behaviors for pthubert> very rapid operations. At ISA, WG 11 has standardized I guess this means that individual products are things which can come out of a production step, and then accumulate before going into the next step. (The kind of thing Goldratt warns us against having anywhere other than at a CCR) pthubert> So, RPL could be used during phases P1, P2, P4, P5 and P6, pthubert> but not during P3, (Normal Operation), unless a new OF was pthubert> defined that interacted with the PCE? pthubert> [Pascal] Roughly yes, and this is the work we are starting pthubert> at 6TSCH. In more details, there will be flows that can pthubert> use distributed routing but critical flows will need the pthubert> PCE. I think that we need to think about: 1) are the P1/P2/P4/P5 and P6 phases distinct in some way? I think that there are significant security differences between them, and the number of type of DAGs that need to be constructed may very a lot. This has implications that intermediate (storing!) nodes may have to have much large capacities for DAGs during non-P3 than they do for P3. Or not... My examination of RPL code to date suggests that some of what lets it fit into the smallest devices is because they support only a single DAG. (no tables, no searches, no code to sort A from B...) 2) how do you bootstrap *securely* into P3 operation? Does this require a rekey? It seems to me that it does. pthubert> 1) publish/subscribe, where an association exists between pthubert> one source and one or a few recipients, all of which are pthubert> identifiable, where publication is periodic within strict So, layer-6 multicasts carried on layer-3 unicast to known subscribers...=20 pthubert> 2) source/sink, where any of a number of sources logically pthubert> multicasts (however that is implemented) to a predefined 1:N multicast pthubert> 3) client/server or peer/peer, where all of the pthubert> traditional properties hold and the specialized ones pthubert> listed above generally do not. and this is 1:1 pthubert> page 13, section 2.1.4: says: pthubert> With rare exception, the control algorithms used with pthubert> PS messaging in the process automation industries - those pthubert> managing continuous material flows - rely on fixed-period pthubert> sampling, computation and transfer of outputs, while those pthubert> in the factory automation industries - those managing pthubert> discrete manufacturing operations - rely on bounded delay pthubert> between sampling of inputs, control computation and pthubert> transfer of outputs to physical actuators that affect the pthubert> controlled process. pthubert> it seems that there are possibly two completely different pthubert> industrial requirements here which can not, and should pthubert> not, be satisfied with a single DAG. Are two documents pthubert> appropriate here? pthubert> [Pascal] It is more than a different DAG, it is a pthubert> different plant... I read your question as do we want an pthubert> additional draft for factory automation? So, factory automation and plant control are not present in the same building. When someone comes along with factory automation expertise, they will need to write a draft. I'm not sure why factory automation is mentioned again. Let's just say: Tthe control algorithms used with PS messaging in the process automation industries - those managing continuous material flows - rely on fixed-period sampling, computation and transfer of outputs. As a result.. X, Y, Z. >> Note: Although there are known patent applications for duocast >> and N-cast, at the time of this writing the patent assignee, >> Honeywell International, has offered to permit cost-free RAND use >> in those industrial wireless standards that have chosen to >> employee the technology, under a reciprocal licensing requirement >> relative to that use. pthubert> Can we get an official IPR statement via: pthubert> http://www.ietf.org/ipr/file-disclosure pthubert> on this? I don't think it is particularly relevant to the pthubert> document, but perhaps I could be wrong. Not sure why it is mentioned then. pthubert> you need to update [I-D.ietf-roll-rpl] to RFC6550. pthubert> [Pascal] Done in 03 : ) pthubert> 4.3.1 says: >> Because the actual link capacity depends on the particular link >> technology used within an industrial automation network >> deployment, the Trickle parameters are specified in terms of the >> link's maximum capacity for conveying link-local multicast >> messages. If the link can convey m link-local multicast packets >> per second on average, the expected time it takes to transmit a >> link-local multicast packet is 1/m seconds. pthubert> I am pleased that a formula is being provided, but I am pthubert> uncomfortable that this document is not more specific to pthubert> actual link technology used. Can this document pick 1-2 pthubert> actual link technologies and deal with them? pthubert> [Pascal] We are working on those concepts at 6TSCH, ccing pthubert> the ML. But, wait. 6tsch is important for P3 only. The other phases need to have something written down. I think it's pretty important to have some concrete numbers for some actual technologies that actually are being deployed. Without that, it's pretty hard for academics to run simulations, or for people thinking about RPL extensions in field X to think how this might work (or not) in another field they aren't an expert in. Also, we need that set of layer 2s to be listed so that the security requirements of layer 2 can be expressed. Again, non-P3 vs P3 might require a rekey. pthubert> 5.: >> The possibility of dynamically updating the metrics in use in the >> network as well as the frequency of network updates allows >> deployment characteristics (e.g., network density) to be >> discovered during network bring-up and to be used to tailor >> network parameters once the network is operational rather than >> having to rely on precise pre- configuration. This also allows >> the network parameters and the overall routing protocol behavior >> to evolve during the lifetime of the network. mcr> I don't know how this discovery is going to occur. mcr> Someone trying to build a sensor that is going to satisfy mcr> an RFP for devices to work in a network envisioned by this mcr> document needs to know what to include in their code base. mcr> As the code space is very finite, they need to know mcr> exactly what is important here. pthubert> [Pascal] Finding the values for parameters is more of a pthubert> deployment issue, so I read your question as 'which pthubert> parameters are critical for the device to operate in pthubert> industrial environment and which range for those pthubert> parameters'. Again, work at 6TSCH may help. Yes, that's what I'm saying. The text talks about "dynamically updating the metrics in use" That says to me that it's not about the values of the metrics, but in changing which metrics are used. =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) iQCVAwUAUTD0r4qHRg3pndX9AQLjzgP/WJOvskNU4GAg0okJ/xqOSDKupg4894wP vpNC7l2Uy/5OdE7jNcpKJR6+Jewx4QpQ2ZNGanwrQFo0w6ZkiR+AJiXmBMEMPpk5 1kTYWo8sxEcsr5MNIo0zghIGSag7ejlBVmf8UF9ekkfQwzdxqzFbtJdNvc3VjFUK JnSEabpHEi8= =gFJT -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Mar 1 12:04:48 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 7EAB121E80C6; Fri, 1 Mar 2013 12:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZXd8QP3IMfV; Fri, 1 Mar 2013 12:04:47 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04E21E803F; Fri, 1 Mar 2013 12:04:47 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A877F20168; Fri, 1 Mar 2013 15:11:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2940463A5C; Fri, 1 Mar 2013 15:03:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 186C363A5B; Fri, 1 Mar 2013 15:03:25 -0500 (EST) From: Michael Richardson To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> In-Reply-To: <5131049C.9020504@cox.net> References: <20381.1362077015@sandelman.ca> <17207.1362162863@sandelman.ca> <5131049C.9020504@cox.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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] [6tsch] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Mar 2013 20:04:48 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Tom" =3D=3D Tom Phinney writes: Tom> Apologies to those who receive this e-mail on more than one Tom> list. First, the traditional industry differentiation between Tom> "factory automation" and "process control" is that factory Tom> automation is focused on discrete manufacturing steps (and thus Tom> is often referred to as "discrete parts manufacturing") while Tom> process control involves continuous processing of fluids and Tom> quasi-fluids (e.g., sand, cereal and other materials whose flow Tom> rate can be measured by a mass flowmeter). Many real-world Tom> plants use hybrids of these two manufacturing styles.=20=20 So, given that many plants are hybrids, are you saying that this document applies only to the process control parts of the plant? Or that hybrid plants are also out of scope? If there are scope constraints, what exactly are they?=20 What happens in a hydrid plant might be significantly more complicated, as it involves two kinds of networks; if there is a desire to have the different pieces interconnected. =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) iQCVAwUAUTEJjYqHRg3pndX9AQIyNwQArn+lzUGyYsGzUEG8z2+EBJsB+kEK2zDF 7yQpOo1smDzD1RXoSGqExH9ktyaiM/twHuvi2Ua4IsQOIpz+Ya6MN8UMy0Ef7E/2 HZe+CauGk+lYZTxK4FmxO6bCzpaRRtXtKMuQz5bAHbE/Z5VyS13ypH36BKgMx2nI k2YDnoIiJkg= =Ra17 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sat Mar 2 08:54: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 072E421F8540; Sat, 2 Mar 2013 08:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtpFAOex4pGU; Sat, 2 Mar 2013 08:54:49 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE321F8519; Sat, 2 Mar 2013 08:54:49 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 763AB20168; Sat, 2 Mar 2013 12:02:09 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 640A463A5B; Sat, 2 Mar 2013 11:53:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 554D663769; Sat, 2 Mar 2013 11:53:35 -0500 (EST) From: Michael Richardson To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> In-Reply-To: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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] [6tsch] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Mar 2013 16:54:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Tom" =3D=3D Tom Phinney writes: Tom> variance in cycle-to-cycle.execution time. The messaging Tom> involved in such automation typically require higher data rates Tom> than those offered by IEEE 802.15.4, and any wireless messaging ... Tom> The communication between the continuous process controllers Tom> of a plant and the discrete automation controllers typically Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless Tom> is not involved, and there is no reason to anticipate that it mcr> So, given that many plants are hybrids, are you saying that mcr> this document applies only to the process control parts of the mcr> plant? So, I take it that you are agreeing with this statement. And disagreeing that "hybrid plants are also out of scope", because all process plants have a factory automation component, but that the factory automation component is out of scope. Further, you have made it clear that there is no direct interconnection between the two networks. =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) iQCVAwUAUTIuj4qHRg3pndX9AQIK1gQAkEmBHYT3UGjnTRR52unzFjwlwAqwOrpP wtY5A8Xbkarnh5e/oT+H6iypdseFpGG27C3i7prMV0UAW4pYgKav9XH1eWiKc4uq Zld0bb79l54Rr5pS9AkFb0AaygszyIXHVhB3fYxOB4/vhlzcaoiVmyaHPqX8tEPL H4HeM79YCuk= =uN1v -----END PGP SIGNATURE----- --=-=-=-- From adrian@olddog.co.uk Sun Mar 3 12:03: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 10C3A21F8883 for ; Sun, 3 Mar 2013 12:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 EhO7FiZJLwVS for ; Sun, 3 Mar 2013 12:03:39 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E921F8884 for ; Sun, 3 Mar 2013 12:03:38 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r23K3aR2025962; Sun, 3 Mar 2013 20:03:36 GMT Received: from 950129200 (089144192226.atnat0001.highway.a1.net [89.144.192.226]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r23K3Y2r025940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 Mar 2013 20:03:35 GMT From: "Adrian Farrel" To: Date: Sun, 3 Mar 2013 20:03:37 -0000 Message-ID: <005501ce184a$3290ccc0$97b26640$@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: Ac4YSc1+RX4kliqKTde8YWkqYxrpoQ== Content-Language: en-gb Cc: roll@ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] AD review of draft-ietf-roll-terminology-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk 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 Mar 2013 20:03:40 -0000 Hi, I have done my usual AD review of your document prior to advancing it towards publication. The purpose of my review is to catch issues or nits that would be found during IETF last call or IESG review and which might delay the processing or hide other issues. The intent is to remove the issues efficiently at this stage. As usual, all of my points are open for discussion. I have found a number of relatively minor nits and small questions. Given the volume I think it would be worth producing a new revision. When I see the new version I will start the IETF last call process. During IETF last call, I will be bringing this I-D explicitly to the attention of several key working groups in other IETF areas so that they can consider alignment of terminology. Thanks, Adrian --- s/A LLN/An LLN/ throughout --- Remove the 2119 boilerplate and the reference to [RFC2119] --- Decide on capitalisation of "Low power and Lossy Networks" and apply it uniformly throughout the document. --- Section 2 Actuator s/modulates/modulate/ --- Section 2 Commissioning Tool s/expressed purpose/express purpose/ --- Section 2 Downstream / Upstream Are you convinced that these terms apply only to data entering / leaving the LLN at the LBR? They do not apply to traffic within the LLN? Although I see you use "inwards" in the definition of "MP2P". --- Section 2 Field Device s/A field deviced/A field device/ --- Section 2 Field Device Low power and Lossy Network Border Router (including LBR) Is this right? Isn't a Low power and Lossy Network Border Router exactly an LBR? --- Section 2 Field Devices compared to computers and routers used in the Internet. I know what you mean, but I think an LLN is part of the Internet. So maybe... compared to computers and routers used outside of LLNs. ...or... compared to computers and routers used in the rest of the Internet. --- Section 2 Non-sleepy Node Non-sleepy Node: A non-sleepy node is a node that always remains in a fully powered on state (i.e. always awake) where it has the capability to perform RPL protocol communication. I think that the specific reference to RPL is wrong in the context of this document. You may mean "perform routing protocol communication" or you may mean "perform communication". --- Section 2 P2MP You use the term DAG without explaining it. You either need to add it to the terms (maybe DAG Root is more useful) or change what is written for P2MP. --- Section 2 RPL Domain Fine, but no explanation of RPL. Since RPL is also used elsewhere in the document, I suggest you add an entry for RPL with a citation. --- Section 2 RPL Domain Since someone is bound to ask what a RPL router is... Best add an entry. --- Section 2 Sensor s/a analog/an analog/ --- Section 2 Sleepy Node Sleepy Node: A sleepy node is a node that may sometimes go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend protocol communication. A sleepy node may also sometimes remain in a fully powered on state where it has the capability to perform RPL protocol communication. This doesn't quite make sense. You are using "Sometimes remain", I think to contrast with "sometimes go into a sleep mode". I think it is enough to say "When no in a sleep mode, the sleepy node is in a fully powered on state...." Additionally, is the only issue "to perform RPL protocol communication"? As for non-sleepy node you may mean "perform routing protocol communication" or you may mean "perform communication". From tom.phinney@cox.net Fri Mar 1 11:42: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 2590621F8600 for ; Fri, 1 Mar 2013 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PekpSmRLjIw for ; Fri, 1 Mar 2013 11:42:22 -0800 (PST) Received: from fed1rmfepo201.cox.net (fed1rmfepo201.cox.net [68.230.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id C107F21F85DA for ; Fri, 1 Mar 2013 11:42:21 -0800 (PST) Received: from fed1rmimpo305 ([68.230.241.173]) by fed1rmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301194221.LOJR19285.fed1rmfepo201.cox.net@fed1rmimpo305> for ; Fri, 1 Mar 2013 14:42:21 -0500 Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo305 with cox id 6KiL1l00c3gAAro01KiLC8; Fri, 01 Mar 2013 14:42:21 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.5131049D.0057,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=W9Hmo2qk c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6t4AJK7m8D8A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=k8pYvbRhVL0A:10 a=48vgC7mUAAAA:8 a=rbl1wQeSwIs0QDm_BuAA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=1XBuBeO_FlPd5T-q:21 a=3Rh-E_-K3_sQRJYf:21 a=JyzrQi_NOIWKAaGf:21 a=mbYREmtDDBfCLQwKCHNpxg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <5131049C.9020504@cox.net> Date: Fri, 01 Mar 2013 12:42:20 -0700 From: Tom Phinney User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> References: <20381.1362077015@sandelman.ca> <17207.1362162863@sandelman.ca> In-Reply-To: <17207.1362162863@sandelman.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Mar 2013 09:50:38 -0800 Cc: "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Tom Phinney 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 Mar 2013 19:42:23 -0000 Apologies to those who receive this e-mail on more than one list.


First, the traditional industry differentiation between "factory automation" and "process control" is that factory automation is focused on discrete manufacturing steps (and thus is often referred to as "discrete parts manufacturing") while process control involves continuous processing of fluids and quasi-fluids (e.g., sand, cereal and other materials whose flow rate can be measured by a mass flowmeter).

Many real-world plants use hybrids of these two manufacturing styles. For example, a soup canning plant, or drink bottling plant (e.g., a brewery), or a dairy that bottles milk and packages ice cream, or a pharmaceutical plant, or a car tire manufacturing plant, all use continuous-flow manufacturing processes (process control) to make the raw product in batches, and discrete part manufacturing processes (factory automation) to package the product. This hybrid mode of operation is often referred to as "batch processing" and has its own terminology and set of standards that build on those of the other two manufacturing regimes. ISA, the Industrial Society for Automation, has developed standards that address both continuous process control and batch processes that are fed materials from a continuous process. (Most ISA standards then become IEC standards.)


Second, the distinction between peer/peer, client/server, publish/subscribe and source/sink is as follows:

1a) peer/peer is a 1:1 relationship of known correspondents, usually connected (i.e., a longer-term association with coordinated residual state information at both ends). This relationship can be symmetric (i.e., federation) or asymmetric (i.e., client/server).

1b) client/server is an asymmetric peer-peer relationship of "known" correspondents in which the client is always the initiator of the relationship. In cases where the provided service is transactional, the association often is more transient than in a symmetric peer-peer relationship. In this case the server may be a member of a server farm, in which case the correspondent is known by role, not device ID.

2) publish/subscribe is a 1:N relationship of known correspondents, which is best implemented as a multi-peer connection (i.e., a longer-term association with coordinated residual state information at the endpoints). Some industrial communication technologies, such as IEC 61158 Type 1 (Foundation Fieldbus H1) provide multi-peer connections within the lower four comm layers to directly support such operation. Timeliness is usually important in the publish/subscribe relationship, whether it be the timeliness of daily newspaper delivery or the timeliness of information delivery between devices acting in concert in closed-loop continuous control. As a consequence, untimely retransmission is not of significant value.

3) source/sink is a M:N relationship of unknown correspondents, which is best implemented by connectionless lower layer services. In the automation environment it is used primarily for reporting of alerts, which include a) device-local events and b) alarms about the monitored process. Alerts are reportable by every device that is involved in sensing and controlling the process -- the M of M:N -- and are reported to all devices that are interested in receiving such reports -- the N of M:N. That latter set includes all human operator workstations that are focused on the monitored process, all historians that are tracking information in the monitored process, etc. There is never a need for comm-layer-initiated retransmission of such information; other application-layer mechanisms come into play to retrieve recent reporting history from individual members of the M set when loss of a report is detected an an N endpoint. To make such loss detection and bulk recovery possible, each alert source includes a local monotonically-increasing sequence number in each alert report.

So, in summary,
1a) peer/peer is 1:1 and typically connected;
1b) client/server is 1:1 and often connected, particularly when the association is longer than a single transaction,
2) publish/subscribe is 1:N with known N, and connected in a long-term relationship;
3) source/sink is M:N with unknown M and N, and connectionless.

Typically 1a) and 1b) use unicast in each direction; 2) uses unicast in the subscriber-to-publisher direction and multicast to a publication-specific group address in the publisher-to-subscriber direction; and 3) uses multicast to a group address identifying the reported information scope (e.g., "unit_N_alerts").

-Tom
=====
On 2013.03.01 11:34, Michael Richardson wrote: 

      

        

          

            

              

                
"pthubert" == pthubert  <Pascal> writes:


              

            

          

        

      

      
    pthubert> [Pascal] Thanks for the comments : )

    pthubert> [Pascal] You are correct. The industry makes a difference
    pthubert> between Factory Automation (discrete manufacturing of
    pthubert> individual products) and Process Controls (continuous
    pthubert> production). These are really 2 different activities, and
    pthubert> Factory Automation may require much stricter behaviors for
    pthubert> very rapid operations.  At ISA, WG 11 has standardized

I guess this means that individual products are things which can come
out of a production step, and then accumulate before going into the next
step. (The kind of thing Goldratt warns us against having anywhere other
than at a CCR)

    pthubert> So, RPL could be used during phases P1, P2, P4, P5 and P6,
    pthubert> but not during P3, (Normal Operation), unless a new OF was
    pthubert> defined that interacted with the PCE?

    pthubert> [Pascal] Roughly yes, and this is the work we are starting
    pthubert> at 6TSCH. In more details, there will be flows that can
    pthubert> use distributed routing but critical flows will need the
    pthubert> PCE.

I think that we need to think about:
1) are the P1/P2/P4/P5 and P6 phases distinct in some way?
   I think that there are significant security differences between them,
   and the number of type of DAGs that need to be constructed may very
   a lot. This has implications that intermediate (storing!) nodes may
   have to have much large capacities for DAGs during non-P3 than they
   do for P3.  Or not...
   My examination of RPL code to date suggests that some of what lets it
   fit into the smallest devices is because they support only a single DAG.
   (no tables, no searches, no code to sort A from B...)

2) how do you bootstrap *securely* into P3 operation?
   Does this require a rekey?  It seems to me that it does.

    pthubert> 1) publish/subscribe, where an association exists between
    pthubert> one source and one or a few recipients, all of which are
    pthubert> identifiable, where publication is periodic within strict

So, layer-6 multicasts carried on layer-3 unicast to known
subscribers... 

    pthubert> 2) source/sink, where any of a number of sources logically
    pthubert> multicasts (however that is implemented) to a predefined

1:N multicast

    pthubert> 3) client/server or peer/peer, where all of the
    pthubert> traditional properties hold and the specialized ones
    pthubert> listed above generally do not.

and this is 1:1


    pthubert> page 13, section 2.1.4: says:

    pthubert>    With rare exception, the control algorithms used with
    pthubert> PS messaging in the process automation industries - those
    pthubert> managing continuous material flows - rely on fixed-period
    pthubert> sampling, computation and transfer of outputs, while those
    pthubert> in the factory automation industries - those managing
    pthubert> discrete manufacturing operations - rely on bounded delay
    pthubert> between sampling of inputs, control computation and
    pthubert> transfer of outputs to physical actuators that affect the
    pthubert> controlled process.

    pthubert> it seems that there are possibly two completely different
    pthubert> industrial requirements here which can not, and should
    pthubert> not, be satisfied with a single DAG.  Are two documents
    pthubert> appropriate here?

    pthubert> [Pascal] It is more than a different DAG, it is a
    pthubert> different plant... I read your question as do we want an
    pthubert> additional draft for factory automation?

So, factory automation and plant control are not present in the same
building.  When someone comes along with factory automation expertise,
they will need to write a draft.

I'm not sure why factory automation is mentioned again.
Let's just say:

Tthe control algorithms used with PS messaging in the process automation
industries - those managing continuous material flows - rely on fixed-period
sampling, computation and transfer of outputs.   As a result.. X, Y, Z.

    >> Note: Although there are known patent applications for duocast
    >> and N-cast, at the time of this writing the patent assignee,
    >> Honeywell International, has offered to permit cost-free RAND use
    >> in those industrial wireless standards that have chosen to
    >> employee the technology, under a reciprocal licensing requirement
    >> relative to that use.

    pthubert> Can we get an official IPR statement via:
    pthubert> http://www.ietf.org/ipr/file-disclosure

    pthubert> on this?  I don't think it is particularly relevant to the
    pthubert> document, but perhaps I could be wrong.

Not sure why it is mentioned then.

    pthubert> you need to update [I-D.ietf-roll-rpl] to RFC6550.

    pthubert> [Pascal] Done in 03 : )

    pthubert> 4.3.1 says:

    >> Because the actual link capacity depends on the particular link
    >> technology used within an industrial automation network
    >> deployment, the Trickle parameters are specified in terms of the
    >> link's maximum capacity for conveying link-local multicast
    >> messages.  If the link can convey m link-local multicast packets
    >> per second on average, the expected time it takes to transmit a
    >> link-local multicast packet is 1/m seconds.

    pthubert> I am pleased that a formula is being provided, but I am
    pthubert> uncomfortable that this document is not more specific to
    pthubert> actual link technology used.  Can this document pick 1-2
    pthubert> actual link technologies and deal with them?

    pthubert> [Pascal] We are working on those concepts at 6TSCH, ccing
    pthubert> the ML.

But, wait. 6tsch is important for P3 only.
The other phases need to have something written down.
I think it's pretty important to have some concrete numbers for some
actual technologies that actually are being deployed.    Without that,
it's pretty hard for academics to run simulations, or for people
thinking about RPL extensions in field X to think how this might work
(or not) in another field they aren't an expert in.

Also, we need that set of layer 2s to be listed so that the security
requirements of layer 2 can be expressed.  Again, non-P3 vs P3 might
require a rekey.

    pthubert> 5.:
    >> The possibility of dynamically updating the metrics in use in the
    >> network as well as the frequency of network updates allows
    >> deployment characteristics (e.g., network density) to be
    >> discovered during network bring-up and to be used to tailor
    >> network parameters once the network is operational rather than
    >> having to rely on precise pre- configuration.  This also allows
    >> the network parameters and the overall routing protocol behavior
    >> to evolve during the lifetime of the network.

   mcr> I don't know how this discovery is going to occur.
   mcr> Someone trying to build a sensor that is going to satisfy
   mcr> an RFP for devices to work in a network envisioned by this
   mcr> document needs to know what to include in their code base.
   mcr> As the code space is very finite, they need to know
   mcr> exactly what is important here.

    pthubert> [Pascal] Finding the values for parameters is more of a
    pthubert> deployment issue, so I read your question as 'which
    pthubert> parameters are critical for the device to operate in
    pthubert> industrial environment and which range for those
    pthubert> parameters'. Again, work at 6TSCH may help.

Yes, that's what I'm saying.

The text talks about "dynamically updating the metrics in use"

That says to me that it's not about the values of the metrics, but in
changing which metrics are used.



    

  


From tom.phinney@cox.net  Fri Mar  1 13:32: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 4D1071F0D10 for ; Fri,  1 Mar 2013 13:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.973
X-Spam-Level: 
X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZPD29e3zC9J for ; Fri,  1 Mar 2013 13:32:07 -0800 (PST)
Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC4C21F8870 for ; Fri,  1 Mar 2013 13:32:07 -0800 (PST)
Received: from fed1rmimpo210 ([68.230.241.161]) by fed1rmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301213202.GZGC1243.fed1rmfepo202.cox.net@fed1rmimpo210> for ; Fri, 1 Mar 2013 16:32:02 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo210 with cox id 6MY01l00M3gAAro01MY2dl; Fri, 01 Mar 2013 16:32:02 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020206.51311E52.008D,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=Q80MFfKa c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=fUqkgGA-opkA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=kefdhCRHuhUA:10 a=48vgC7mUAAAA:8 a=7fnSsO-jmgmup-exoxwA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=2u8-7BD2COMLsqic:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <51311E50.7010604@cox.net>
Date: Fri, 01 Mar 2013 14:32:00 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
References: <20381.1362077015@sandelman.ca>		<17207.1362162863@sandelman.ca> <5131049C.9020504@cox.net> <795.1362168205@sandelman.ca>
In-Reply-To: <795.1362168205@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 04 Mar 2013 09:50:39 -0800
Subject: Re: [Roll] [6tsch] comments on	draft-phinney-roll-rpl-industrial-applicability
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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 Mar 2013 21:32:08 -0000



  
    
  
  
    The continuous and discrete manufacturing parts
      of hybrid manufacturing plants are ALWAYS connected; it would be
      pointless to build such a plant if that were not the case.

      

      It is useful to consider the differences. Continuous processes use
      closed-loop control based on fixed-period process sampling and
      outputs to process actuators. The highest frequency of such
      control loops is usually 4 H, though a few compressor surge
      control loops that operate at a 9 Hz to 11 Hz rate may also be
      present. These process control systems are potential users of
      wireless communications because their fixed timing is compatible
      (in theory) with TSCH-like time schedules.

      

      It is important to understand that the publish-subscribe messaging
      used for process automation does not require 100% delivery. The
      control algorithms traditionally are designed to tolerate the loss
      of three or fewer consecutive messages before receiving another
      message in the series. However, typically loss of four consecutive
      messages triggers the equipment to shift to a fallback control
      strategy. It is this statistic that leads to use of duocast (with
      its approximate squaring of message loss rates) for high-speed
      loops, since most plant managers will not tolerate more than one
      such shift to a fallback control strategy per year, per plant, and
      there can be thousands of 1 Hz and 4 Hz control loops operating in
      the plant.

      

      Discrete processes use a different form of control that is cyclic
      but not periodic. This is usually implemented in PLCs
      (programmable logic controllers) that execute a
      variable-execution-duration program that repeats as soon as it
      finishes each iteration, leading to cyclic but aperiodic behavior.
      The duration of each execution cycle is usually a few ms,
      typically 3 ms to 10 ms, with a perhaps 50% maximum variance in
      cycle-to-cycle.execution time. The
      messaging involved in such automation typically require higher
      data rates than those offered by IEEE 802.15.4, and any wireless
      messaging itself would typically be single-hop, from a
      router/local-controller that is part of the manufacturing device
      to multiple wireless backbone routers arranged high on opposite
      walls in a roofed factory. High-data-rate optical signaling would
      be a good match for this communication.

      

      The variance in cycle-to-cycle times provides a significant
      challenge for comm technologies based on scheduled pairing of
      senders and receivers. That, coupled with the typically single-hop
      aspect of the communication, makes it likely that a non-TSCH
      approach will be optimal for such systems.

      

      The communication between the continuous process controllers of a
      plant and the discrete automation controllers typically occurs on
      a 100 Mbit/s or faster backbone comm link. Wireless is not
      involved, and there is no reason to anticipate that it will be in
      the future. Since the physical systems that implement the
      continuous and discrete processes are interconnected (e.g., pipes
      with valves connected to bottle handling-and-filling apparatus in
      a soda bottling plant), wired interconnection between backbone
      controllers is typically not a significant issue.

      

      I hope that the above discussion helps understand the differences
      in operating mode, timescales, comm needs and other high-level
      aspects of the continuous and discrete portions of a hybrid plant.
      There are others receiving this e-mail who are much more familiar
      with such plants and processes than I, so if I have erred
      substantially, I trust that they will post a correction to this
      list.

      

      -Tom

      =====

    On 2013.03.01 13:03, Michael Richardson wrote:
    

      

      

        

          

            

              

                
"Tom" == Tom Phinney <tom.phinney@cox.net> writes:


              

            

          

        

      

      
    Tom>    Apologies to those who receive this e-mail on more than one
    Tom> list.  First, the traditional industry differentiation between
    Tom> "factory automation" and "process control" is that factory
    Tom> automation is focused on discrete manufacturing steps (and thus
    Tom> is often referred to as "discrete parts manufacturing") while
    Tom> process control involves continuous processing of fluids and
    Tom> quasi-fluids (e.g., sand, cereal and other materials whose flow
    Tom> rate can be measured by a mass flowmeter).  Many real-world
    Tom> plants use hybrids of these two manufacturing styles.  

So, given that many plants are hybrids, are you saying that this
document applies only to the process control parts of the plant?

Or that hybrid plants are also out of scope?

If there are scope constraints, what exactly are they? 

What happens in a hydrid plant might be significantly more complicated,
as it involves two kinds of networks; if there is a desire to have the
different pieces interconnected.



      

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


    

  


From tom.phinney@cox.net  Sat Mar  2 09:58: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 4488321F8576 for ; Sat,  2 Mar 2013 09:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level: 
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXz-rkWvyWR5 for ; Sat,  2 Mar 2013 09:58:52 -0800 (PST)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 699D021F84BE for ; Sat,  2 Mar 2013 09:58:52 -0800 (PST)
Received: from fed1rmimpo209 ([68.230.241.160]) by fed1rmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130302175851.VPHK25001.fed1rmfepo101.cox.net@fed1rmimpo209> for ; Sat, 2 Mar 2013 12:58:51 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo209 with cox id 6hyr1l0093gAAro01hyrgr; Sat, 02 Mar 2013 12:58:51 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.51323DDB.0094,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=SfMpgItu c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=mu-2PAB6mIwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=zKXdt2971PUA:10 a=OyP9-m7eLojCRTrj5WcA:9 a=QEXdDO2ut3YA:10 a=4vB-4DCPJfMA:10 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <51323DDA.6050301@cox.net>
Date: Sat, 02 Mar 2013 10:58:50 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
References: <29193.1362243215@sandelman.ca>
In-Reply-To: <29193.1362243215@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 04 Mar 2013 09:50:39 -0800
Subject: [Roll] [6tsch] comments on draft-phinney-roll-rpl-industrial-applicability
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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 Mar 2013 17:58:53 -0000

On 2013.03.02 09:53, Michael Richardson wrote:
>>>>>> "Tom" == Tom Phinney  writes:
>     Tom> variance in cycle-to-cycle.execution time. The messaging
>     Tom> involved in such automation typically require higher data rates
>     Tom> than those offered by IEEE 802.15.4, and any wireless messaging
>
> ...
>
>     Tom>    The communication between the continuous process controllers
>     Tom> of a plant and the discrete automation controllers typically
>     Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless
>     Tom> is not involved, and there is no reason to anticipate that it
>
> mcr> So, given that many plants are hybrids, are you saying that
> mcr> this document applies only to the process control parts of the
> mcr> plant?
>
> So, I take it that you are agreeing with this statement.
Essentially yes. While the higher-layer parts of industrial wireless
protocols such as WirelessHART and ISA-100.11a are more-or-less suitable
for use in the factory automation environment, in general the time
scales of required reporting and action are such that IEEE 802.15.4 will
not be appropriate. Of course there may be some parts of the plant, such
as mechanical interlocks against human intrusion, that are workable with
a 100 ms or 250 ms or even 1 s reporting delay, but that will not be
true for limit switches and other such devices in factory automation
lines that typically must report every few ms.
> And disagreeing that "hybrid plants are also out of scope", because
> all process plants have a factory automation component, but that the
> factory automation component is out of scope.
Essentially yes, because the ROLL/RPL mechanism is focused on
self-organizing multi-hop networks where significant variance in
reporting delays is generally tolerable. The portions of process
automation networks where tight time constraints apply are typically one
hop off the backbone, so ROLL/RPL would be used only for self-organizing
system startup or recover after a plant disaster (e.g., explosion, fire,
tornado tearing up the plant, etc.). Likewise for most factory
automation systems, due to the information timeliness demands of the
PLCs that typically automate such processes.
> Further, you have made it clear that there is no direct interconnection
> between the two networks.
If you don't consider a wired Ethernet connection between routers to be
a direct connection, then that must be the case. I personally would not
phrase it that way; rather, the two networks do not interact directly in
their network organization, although their members communicate as
directly as their differing communications technologies permit.

Note that this is also true for IEEE 802.15.4 systems that communicate
with 802.11 systems; their networks do not interact directly in their
network organization, even though they use the same spectral RF band in
the same 3D spatial region. This is particularly the case where ETSI 300
328 v1.8.1 applies, since the process system may have to use at least
fifteen IEEE 802.15.4 channels when the distances involved require
operation at greater than 10 dBm EIRP and timeliness considerations do
not permit indefinitely-repeated deferral to ongoing IEEE 802.11
transmissions.


From cabo@tzi.org  Thu Mar  7 12:08:32 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 5410C21F8CDB; Thu,  7 Mar 2013 12:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level: 
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 J1SDaov9Av3i; Thu,  7 Mar 2013 12:08:31 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4B21F8C20; Thu,  7 Mar 2013 12:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r27K89og025537; Thu, 7 Mar 2013 21:08:09 +0100 (CET)
Received: from [192.168.217.105] (p548929A6.dip.t-dialin.net [84.137.41.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4672C366F; Thu,  7 Mar 2013 21:08:09 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Mar 2013 21:08:06 +0100
To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org>
Message-Id: <3CD61744-1CC9-45F4-A004-80B83E6C2BA4@tzi.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [Roll] Constrained Node/Network Cluster @ IETF86
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Mar 2013 20:08:32 -0000

As you can see, I'm terribly late in preparing for IETF86.

Here is my usual eclectic condensed agenda.  All times are EDT =
(UTC-0400).
Very comfortable this time for Europeans.
(This time, there are even more slot overlaps for me than I'm already =
used to.)

Gr=FC=DFe, Carsten


MONDAY, March 11, 2013

0900-1130  Morning Session I
Caribbean 1     APP     appsawg Applications Area Working Group WG - =
Combined with APPAREA
Caribbean 5     TSV     rmcat   RTP Media Congestion Avoidance =
Techniques WG

1300-1530  Afternoon Session I
Caribbean 4     APP     json    Javascript Object Notation BOF
Caribbean 6     OPS     eman    Energy Management WG
Caribbean 3     OPS     v6ops   IPv6 Operations WG

1540-1710  Afternoon Session II
Boca 2          SEC     oauth   Web Authorization Protocol WG
Caribbean 5     TSV     tsvwg   Transport Area Working Group WG

TUESDAY, March 12, 2013

0900-1020  Morning Session I
Caribbean 2     RTG *** roll    Routing Over Low power and Lossy =
networks WG

1030-1130  Morning Session II
Caribbean 4     INT     intarea Internet Area Working Group WG
Caribbean 2     RTG *** roll    Routing Over Low power and Lossy =
networks WG

1300-1500  Afternoon Session I
Caribbean 2     APP *** core    Constrained RESTful Environments WG

1700-1830  Afternoon Session III
Caribbean 2     SEC     httpauth        Hypertext Transmission Protocol =
Authentication WG

WEDNESDAY, March 13, 2013

0900-1130  Morning Session I
Caribbean 1     SEC     jose    Javascript Object Signing and Encryption =
WG
Caribbean 3     TSV     tsvarea Transport Area Open Meeting

1300-1500  Afternoon Session I
Caribbean 5     APP *** core    Constrained RESTful Environments WG

1510-1710  Afternoon Session II
Caribbean 5     OPS     v6ops   IPv6 Operations WG

THURSDAY, March 14, 2013

0900-1130  Morning Session I
Caribbean 3     INT     homenet Home Networking WG
Caribbean 1     INT *** lwig    Light-Weight Implementation Guidance WG

1300-1500  Afternoon Session I
Caribbean 4     RTG     rtgarea Routing Area Open Meeting

1510-1710  Afternoon Session II
Caribbean 4     SEC     saag    Security Area Open Meeting

1730-1830  Afternoon Session III
Boca 1          SEC     oauth   Web Authorization Protocol WG
Caribbean 2     TSV     tsvwg   Transport Area Working Group WG

FRIDAY, March 15, 2013

0900-1100  Morning Session I
Caribbean 5     APP     httpbis Hypertext Transfer Protocol Bis WG

1120-1220  Afternoon Session I
Caribbean 4     INT     6man    IPv6 Maintenance WG
Boca 2          SEC     tls     Transport Layer Security WG

1230-1330  Afternoon Session II
Caribbean 4     INT     6man    IPv6 Maintenance WG
Boca 2          SEC     tls     Transport Layer Security WG



From mcr@sandelman.ca  Fri Mar  8 09:56: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 AAF3721F8745 for ; Fri,  8 Mar 2013 09:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_05=-1.11, 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 zqA9+3v8deP7 for ; Fri,  8 Mar 2013 09:56:12 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2521F849A for ; Fri,  8 Mar 2013 09:56:05 -0800 (PST)
Received: from sandelman.ca (unknown [99.241.74.27]) by relay.sandelman.ca (Postfix) with ESMTPS id C15B422060 for ; Fri,  8 Mar 2013 17:56:04 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2192CCA0BC for ; Fri,  8 Mar 2013 12:56:05 -0500 (EST)
From: Michael Richardson 
To: roll@ietf.org
X-Mailer: MH-E 8.3; 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 Mar 2013 12:56:04 -0500
Message-ID: <11629.1362765364@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] DRAFT agenda for 2013-03-12 09:00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 17:56:13 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


This is still subject to change.

It has been uploaded at 12:55, but I think that there is a delay before
it shows up in the meeting materials.

1) Note Well	and Agenda Bashing	(09:00 - 5min)
2) Document status			(09:05 - 10min)
   - what document is there.
3) Applicability Statements=09=09
   - industrial				(09:15 - 10min)
   - home/building			(09:25 - 10min)
   - metering/AMI			(09:35 - 10min)
4) discussion/question: do applicability statements stand alone? (09:45 - 1=
5min)
5) 6TSCH summary/invite                 (10:00 - 10min)



=2D-=20
Michael Richardson
=2Don the road-



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

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

iQEcBAABAgAGBQJROiY0AAoJEKD0KQ7Gj3P2nRoIAJuaokDhU06Mn8EjLlmI1rNi
B+IymYmAYsX5rIA6cv0LvQsgzCnxI8Fs6jXklGKfaBaLhRrBUmZCmdw5+cvUZJGg
lSuxlzdVp6FeDvf74hbeI4g5j2UUJ+pFymHMDC3fUuiCjr2wcM8FukQu1zSw/9yy
+FHbtsZ2z0jQErGEZ5Lnxq103vxlmVeUtpxkWXd67mURoNrwfRJ3W2scD1YIX5DP
2nxEI5iD60CgrP/RdVvsp3yof8VdX5b40dfjG5N9Rzo7kUfuAYlqo7ZNgtHrJ+8I
+5VruUAr5xaa0F6pE1+CeAjnR71mv2CgyCUJTInBQD0yO/tOV57t4tFOeDcch1o=
=lxM8
-----END PGP SIGNATURE-----
--=-=-=--

From gnawali@cs.uh.edu  Mon Mar 11 06:34: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 B5B5521F85D8 for ; Mon, 11 Mar 2013 06:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 aTuhrTQn+O51 for ; Mon, 11 Mar 2013 06:34:13 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF1E21F84A9 for ; Mon, 11 Mar 2013 06:34:13 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id C91B023CAB5 for ; Mon, 11 Mar 2013 08:34:00 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spf4jgQ7LxUQ for ; Mon, 11 Mar 2013 08:33:58 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 47FB723CAAF for ; Mon, 11 Mar 2013 08:33:58 -0500 (CDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by it.cs.uh.edu (Postfix) with ESMTP id C1F152A2809D for ; Mon, 11 Mar 2013 08:52:31 -0500 (CDT)
Received: by mail-la0-f44.google.com with SMTP id eb20so3920473lab.17 for ; Mon, 11 Mar 2013 06:34:02 -0700 (PDT)
X-Received: by 10.112.9.10 with SMTP id v10mr4666919lba.47.1363008842257; Mon, 11 Mar 2013 06:34:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.99.38 with HTTP; Mon, 11 Mar 2013 06:33:41 -0700 (PDT)
From: Omprakash Gnawali 
Date: Mon, 11 Mar 2013 08:33:41 -0500
Message-ID: 
To: ROLL WG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Roll] roll operation dos and don'ts
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 13:34:14 -0000

Dear WG,

As we deploy ROLL, I am sure we have accumulated experiences on
how to make it work great or what not to do. It will be great to
collect that information to benefit everyone. I started a small
attempt at this a while ago. Here is the latest draft:

Recommendations for Efficient Implementation of RPL
http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-04

I would like to request everyone to send their experiences and
comments about RPL so I can incorporate them in the next revision of
the document in the next few days.

Thanks.

- om_p

From jvasseur@cisco.com  Mon Mar 11 07:14: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 D3D8321F8457 for ; Mon, 11 Mar 2013 07:14:19 -0700 (PDT)
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 wHjiJ4yMCs34 for ; Mon, 11 Mar 2013 07:14:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D38F21F8501 for ; Mon, 11 Mar 2013 07:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4471; q=dns/txt; s=iport; t=1363011258; x=1364220858; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XaykxbIFFMO67iyCnMLdfCr2L7gnByNOS2MugKAlgMw=; b=nEhWf9uvt9qiIcI7oUiYO2wFy+2A6sWy2TpIuL4nKcjQsWzHy5uw4t8J D19VxK7KJTaEDWySdhvcEapUTEC+aJTnwRx4pK4F3L3uYzOiMZMJ893Hr r3+w2JWlAa2Ah/ocDzXPfACc/gCV/zxh11/8EofNtQzt4gOCZZeJ+hlpT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFABfmPVGtJXG//2dsb2JhbABDs0eRDIFbFnSCKQEBAQMBAQEBNzQGBQULAgEIIgsJECcLJQIEDgUIiAUGDLsdEwSNXn0CMQcKglVhA6dKgwqBagkXAwEafw
X-IronPort-AV: E=Sophos;i="4.84,822,1355097600"; d="scan'208";a="186093393"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 11 Mar 2013 14:14:17 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2BEEHXs007092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 14:14:17 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 09:14:17 -0500
From: "JP Vasseur (jvasseur)" 
To: "" 
Thread-Topic: [Roll] AD review of draft-ietf-roll-terminology-11.txt
Thread-Index: AQHOHmK2jl1t9amjEEquq6ibrBfQIw==
Date: Mon, 11 Mar 2013 14:14:16 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A772332DFB3@xmb-rcd-x02.cisco.com>
References: <005501ce184a$3290ccc0$97b26640$@olddog.co.uk>
In-Reply-To: <005501ce184a$3290ccc0$97b26640$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.85.11]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" 
Subject: Re: [Roll] AD review of draft-ietf-roll-terminology-11.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 14:14:20 -0000

Many Thanks Adrian for the thorough review. This may be annoying but I took=
 all of your suggestions into account ;-)
New version has been posted.
Thanks.

JP.=20

On Mar 3, 2013, at 3:03 PM, Adrian Farrel wrote:

> Hi,
>=20
> I have done my usual AD review of your document prior to advancing it
> towards publication. The purpose of my review is to catch issues or nits
> that would be found during IETF last call or IESG review and which might
> delay the processing or hide other issues. The intent is to remove the
> issues efficiently at this stage.
>=20
> As usual, all of my points are open for discussion.
>=20
> I have found a number of relatively minor nits and small questions.=20
> Given the volume I think it would be worth producing a new revision.=20
>=20
> When I see the new version I will start the IETF last call process. Durin=
g
> IETF last call, I will be bringing this I-D explicitly to the attention o=
f=20
> several key working groups in other IETF areas so that they can
> consider alignment of terminology.
>=20
> Thanks,
> Adrian
>=20
> ---
>=20
> s/A LLN/An LLN/ throughout
>=20
> ---
>=20
> Remove the 2119 boilerplate and the reference to [RFC2119]
>=20
> ---
>=20
> Decide on capitalisation of "Low power and Lossy Networks" and apply it
> uniformly throughout the document.
>=20
> ---
>=20
> Section 2 Actuator
> s/modulates/modulate/
>=20
> ---
>=20
> Section 2 Commissioning Tool
> s/expressed purpose/express purpose/
>=20
> ---
>=20
> Section 2 Downstream / Upstream
>=20
> Are you convinced that these terms apply only to data entering / leaving
> the LLN at the LBR? They do not apply to traffic within the LLN?
>=20
> Although I see you use "inwards" in the definition of "MP2P".
>=20
> ---
>=20
> Section 2 Field Device
> s/A field deviced/A field device/
>=20
> ---
>=20
> Section 2 Field Device
>=20
>   Low power and Lossy Network Border Router (including LBR)
>=20
> Is this right? Isn't a Low power and Lossy Network Border Router exactly
> an LBR?
>=20
> ---
>=20
> Section 2 Field Devices
>=20
>   compared to computers and routers used in the Internet.
>=20
> I know what you mean, but I think an LLN is part of the Internet.
> So maybe...
>=20
>   compared to computers and routers used outside of LLNs.
>=20
> ...or...
>=20
>   compared to computers and routers used in the rest of the Internet.
>=20
> ---
>=20
> Section 2 Non-sleepy Node
>=20
>   Non-sleepy Node: A non-sleepy node is a node that always remains in a
>   fully powered on state (i.e. always awake) where it has the
>   capability to perform RPL protocol communication.
>=20
> I think that the specific reference to RPL is wrong in the context of=20
> this document. You may mean "perform routing protocol communication" or
> you may mean "perform communication".
>=20
> ---
>=20
> Section 2 P2MP
>=20
> You use the term DAG without explaining it. You either need to add it=20
> to the terms (maybe DAG Root is more useful) or change what is written
> for P2MP.
>=20
> ---
>=20
> Section 2 RPL Domain
>=20
> Fine, but no explanation of RPL. Since RPL is also used elsewhere in the
> document, I suggest you add an entry for RPL with a citation.
>=20
> ---
>=20
> Section 2 RPL Domain
>=20
> Since someone is bound to ask what a RPL router is...
> Best add an entry.
>=20
> ---
>=20
> Section 2 Sensor
>=20
> s/a analog/an analog/
>=20
> ---
>=20
> Section 2 Sleepy Node
>=20
>   Sleepy Node: A sleepy node is a node that may sometimes go into a
>   sleep mode (i.e. go into a low power state to conserve power) and
>   temporarily suspend protocol communication.  A sleepy node may also
>   sometimes remain in a fully powered on state where it has the
>   capability to perform RPL protocol communication.
>=20
> This doesn't quite make sense. You are using "Sometimes remain", I think
> to contrast with "sometimes go into a sleep mode".
>=20
> I think it is enough to say "When no in a sleep mode, the sleepy node is
> in a fully powered on state...."
>=20
> Additionally, is the only issue "to perform RPL protocol communication"?
> As for non-sleepy node you may mean "perform routing protocol
> communication" or you may mean "perform communication".
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From mcr@sandelman.ca  Mon Mar 11 15:49:37 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 0DC3021F8FE8 for ; Mon, 11 Mar 2013 15:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, 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 0hJ-74bBLCBw for ; Mon, 11 Mar 2013 15:49:36 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 76F6621F8FE3 for ; Mon, 11 Mar 2013 15:49:36 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.20.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 9963122060; Mon, 11 Mar 2013 22:49:35 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C92F8CA0BC; Mon, 11 Mar 2013 18:49:34 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-reply-to: <6e4fbca8e8b8c6a61c0f0086cb4dfbcd@xs4all.nl>
References: <6e4fbca8e8b8c6a61c0f0086cb4dfbcd@xs4all.nl>
Comments: In-reply-to peter van der Stok  message dated "Mon, 11 Mar 2013 16:59:26 +0100."
X-Mailer: MH-E 8.3; 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: Mon, 11 Mar 2013 18:49:34 -0400
Message-ID: <7484.1363042174@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: anders Brandt 
Subject: Re: [Roll] rpl-p2p applicability statement
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 22:49:37 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


(sending to the list)

>>>>> "peter" =3D=3D peter van der Stok  writes:
    peter> Do you agree to add the mpl applicability to building control
    peter> in the rpl-p2p applicability statement?  or do you prefer a
    peter> different document for mpl applicability?

I would like the applicability statements to explain how to explain how
to apply the appropriate technologies to solve the problem.

So, if you need P2P or MPL to solve your problem, then you should
specify it, and say how you are going to use it.  If there are sections
missing in the template on MPL (I think that there are), then we should
fill that in.

=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.10 (GNU/Linux)

iQEcBAABAgAGBQJRPl9+AAoJEKD0KQ7Gj3P2X5EH/2YR6/2tPJnTreqoMdg5cp1I
56JZ/GXLiOWxJTUf4SO4q9gQWxUw24RBVw8jXNO1BQg/FE9I4BH4sxc2DRMjzw7U
eOvk7M6CZ1NwTEmicwgT/n8ykCMpUlQIntP9bzHMZ9AnieerDkG2/byA4p7BRuug
5tMaPPk3PelbAzteOLSH/RbFQzAM5oem05gqiyE4pihoDz0fuwuX1x338XSoOkvx
p14aYQT7RTCGkhXaZNThiAsIu0twbPYdrbBl+oRel+s0Sb1S4NQl5R5NbzUFDSa/
A7SavNYEOpBN9t9W5KoxwpXhJmj97D0qyg1mOn998Rkt778hVrK1cpP6bOjhYDs=
=zeBi
-----END PGP SIGNATURE-----
--=-=-=--

From internet-drafts@ietf.org  Mon Mar 11 16:12: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 30CC311E8117; Mon, 11 Mar 2013 16:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level: 
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, 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 H85KyASIScl3; Mon, 11 Mar 2013 16:12:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF51B11E810C; Mon, 11 Mar 2013 16:12:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.42
Message-ID: <20130311231221.3828.71909.idtracker@ietfa.amsl.com>
Date: Mon, 11 Mar 2013 16:12:21 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 23:12:22 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : ROLL Applicability Statement Template
	Author(s)       : Michael C. Richardson
	Filename        : draft-ietf-roll-applicability-template-00.txt
	Pages           : 15
	Date            : 2013-03-11

Abstract:
   This document is a template applicability statement for the Routing
   over Low-power and Lossy Networks (ROLL) WG.  This document is not
   for publication, but rather is to be used as a template.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-applicability-template-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Tue Mar 12 06:42: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 28AED21F8B33; Tue, 12 Mar 2013 06:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5dvL0ZWNh2o0; Tue, 12 Mar 2013 06:42:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 899C721F8A99; Tue, 12 Mar 2013 06:42:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.42
Message-ID: <20130312134203.10479.10033.idtracker@ietfa.amsl.com>
Date: Tue, 12 Mar 2013 06:42:03 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-rpl-industrial-applicability-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 13:42:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : RPL applicability in industrial networks
	Author(s)       : Tom Phinney
                          Pascal Thubert
                          Robert Assimiti
	Filename        : draft-ietf-roll-rpl-industrial-applicability-00.txt
	Pages           : 37
	Date            : 2013-03-12

Abstract:
   The wide deployment of wireless devices, with their low installed
   cost (compared to wired devices), will significantly improve the
   productivity and safety of industrial plants.  It will simultaneously
   increase the efficiency and safety of the plant's workers, by
   extending and making more timely the information set available about
   plant operations.  The new Routing Protocol for Low Power and Lossy
   Networks (RPL) defines a Distance Vector protocol that is designed
   for such networks.  The aim of this document is to analyze the
   applicability of that routing protocol in industrial LLNs formed of
   field devices.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicabili=
ty

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From Internet-Drafts@ietf.org  Tue Mar 12 06:49: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 91E8F21F8AF4; Tue, 12 Mar 2013 06:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 EMpu66UAPO3b; Tue, 12 Mar 2013 06:49:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92621F856D; Tue, 12 Mar 2013 06:49:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.42
Message-ID: <20130312134911.17650.94034.idtracker@ietfa.amsl.com>
Date: Tue, 12 Mar 2013 06:49:11 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D ACTION:draft-ietf-roll-terminology-12.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 13:49:11 -0000

--NextPart

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

    Title         : Terminology in Low power And Lossy Networks
    Author(s)     : J. Vasseur
    Filename      : draft-ietf-roll-terminology
    Pages         : 8 
    Date          : March 12, 2013 
    
   The documents defines a terminology for discussing 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.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-roll-terminology";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2013-03-12064911.I-D@ietf.org>


--NextPart--

From mcr@sandelman.ca  Tue Mar 12 07:44: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 F100421F8930 for ; Tue, 12 Mar 2013 07:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level: 
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-0.182,  BAYES_00=-2.599, 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 BGk3OAo5iyj8 for ; Tue, 12 Mar 2013 07:44:50 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A621F87F6 for ; Tue, 12 Mar 2013 07:44:50 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 0481A22060 for ; Tue, 12 Mar 2013 14:44:47 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CBAA5CA0BC for ; Tue, 12 Mar 2013 10:44:45 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
X-Mailer: MH-E 8.3; 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: Tue, 12 Mar 2013 10:44:45 -0400
Message-ID: <5421.1363099485@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] MPL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 14:44:51 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


I wonder how people would feel about pronouncing the mcast-trickle
protocol, "MPL", as "Maple"

=2D-=20
Michael Richardson
=2Don the road-



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

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

iQEcBAABAgAGBQJRPz9dAAoJEKD0KQ7Gj3P2uAsH/2awohlHiKWHVGl5G/l+J5w6
G3gatl2rgJaIgpIP7IjBLUEg4w68bXt9OZtqZljnLGnsfpVy1gpzopyjRsnwqhKQ
ngwLqG/AlJR+qNEp+xYj8vqj1KBnRPBxpobHhUkuAoXpFMHOUt9UAKtulBd9FU+y
/pt8fLVtJtu+8M7ETUn37kEkqoD6AzgZxtQnWVTcIxXFVYig4/9+XMVNz90eYqQZ
5SDB2RPwcZ1umuBJc9oQt8wmYoRzei2eSokLcBqIywqCizCm+fyY52vUSrOe7kjU
ZldybKJSlUNnahewRmgwdQkNfRR2n+3/tp7zdjUbzcOCzkuiu60dA9HLE4kOtcQ=
=vCv7
-----END PGP SIGNATURE-----
--=-=-=--

From yi.jiazi@gmail.com  Tue Mar 12 10:31: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 63AD711E80A6 for ; Tue, 12 Mar 2013 10:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 LK5sUPeIwjNL for ; Tue, 12 Mar 2013 10:31:39 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82BB111E80A3 for ; Tue, 12 Mar 2013 10:31:39 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr12so90682wgb.23 for ; Tue, 12 Mar 2013 10:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=6aKF+h3KyhOMuymw/qkkDMW187QEu36wkReP78tD9PM=; b=GV4BPebfELjgNz6cio03spK4AhdJhIgwONTpJGO+PwgQCMTGcQ3bj5HW4Boag40WoK 6cUcBT+iInDk6IP7vGEB8mi4QGksckGeDuEuY1qIpVrn9x1w4BaZadPyTgOYxPpdSxsc ovWd1MDcLm0JBxZiCILgp8+aQz3fDTuu+G5iuReU8e3ZqVd7yeiBplQQyFMSuI9nib9p r42uQW2ROa2t4VhZRony4vcOt/BQGAWum8eeL3t7frjKDwqA6pLVbY29NQmmp/86rV/1 jE3pTBhQ4mfL2BM9soIKAVGhEMWyilM4OvGQteeiRGQamFVT9elQpmRrNY5gejrAOk2J PqjA==
X-Received: by 10.194.133.98 with SMTP id pb2mr28584971wjb.20.1363109496296; Tue, 12 Mar 2013 10:31:36 -0700 (PDT)
Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id fx5sm25434551wib.11.2013.03.12.10.31.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 10:31:35 -0700 (PDT)
Sender: Jiazi YI 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Jiazi Yi 
In-Reply-To: <5421.1363099485@sandelman.ca>
Date: Tue, 12 Mar 2013 18:31:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5421.1363099485@sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1499)
Cc: roll@ietf.org
Subject: Re: [Roll] MPL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 17:31:40 -0000

Hi,

I'm afraid that it would make people confused with the name of Maple =
software, which is widely used for math computation.=20
Something like Muple, can avoid such ambiguous (I'm not a native English =
speaker, not sure if it has any other meanings. At least, it doesn't =
exist in the dictionary).=20

best

Jiazi

On Mar 12, 2013, at 3:44 PM, Michael Richardson  =
wrote:

>=20
> I wonder how people would feel about pronouncing the mcast-trickle
> protocol, "MPL", as "Maple"
>=20
> --=20
> Michael Richardson
> -on the road-
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From paduffy@cisco.com  Tue Mar 12 10:36: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 8D5EE21F84FF for ; Tue, 12 Mar 2013 10:36:13 -0700 (PDT)
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 nYdbxBO0SOi8 for ; Tue, 12 Mar 2013 10:36:07 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E24B111E80A5 for ; Tue, 12 Mar 2013 10:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=945; q=dns/txt; s=iport; t=1363109767; x=1364319367; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e1tp1m+1bVgmEPrKvn+ejqdAXFUm6n23WEr7x749THs=; b=We58TWMTdCCgcoFxxSkITnvmqeeK/OWO1+PR8b6qZSBiWZ1sR4vkWsOQ VH1npBNr2wmzMdsvau40EoPF/bxD72aZqrwvhMOg00MMfshFrzmvZRaZn deuxec8332NSAzuE3F/vkb1jIOdW6xRgQ8HpQDWSESso/gAV8fcy2Bbba w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FADxmP1GtJV2Z/2dsb2JhbABDh1C9GoFLFnSCKQEBAQQBAQE1NgoBEAsOCgkWDwkDAgECARUwBg0BBQIBAYgQDLFVj2cTBI8NB4NAA5ZWhXuKe4Mm
X-IronPort-AV: E=Sophos;i="4.84,832,1355097600"; d="scan'208";a="186619276"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2013 17:36:06 +0000
Received: from [161.44.66.125] (printer-xx-00a645.cisco.com [161.44.66.125]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2CHa5PX014581;  Tue, 12 Mar 2013 17:36:06 GMT
Message-ID: <513F6785.9020801@cisco.com>
Date: Tue, 12 Mar 2013 13:36:05 -0400
From: Paul Duffy 
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jiazi Yi 
References: <5421.1363099485@sandelman.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org
Subject: Re: [Roll] MPL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: paduffy@cisco.com
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 Mar 2013 17:36:13 -0000

The Miple horse has already left many barns.

On 3/12/2013 1:31 PM, Jiazi Yi wrote:
> Hi,
>
> I'm afraid that it would make people confused with the name of Maple software, which is widely used for math computation.
> Something like Muple, can avoid such ambiguous (I'm not a native English speaker, not sure if it has any other meanings. At least, it doesn't exist in the dictionary).
>
> best
>
> Jiazi
>
> On Mar 12, 2013, at 3:44 PM, Michael Richardson  wrote:
>
>> I wonder how people would feel about pronouncing the mcast-trickle
>> protocol, "MPL", as "Maple"
>>
>> -- 
>> Michael Richardson
>> -on the road-
>>
>>
>> _______________________________________________
>> 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  Tue Mar 12 11:20: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 D888F11E810F; Tue, 12 Mar 2013 11:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level: 
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, 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 zQCxa3RJd2H8; Tue, 12 Mar 2013 11:20:28 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC111E80FB; Tue, 12 Mar 2013 11:20:27 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 1653922060; Tue, 12 Mar 2013 18:20:27 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EDEB1CA0C7; Tue, 12 Mar 2013 14:20:23 -0400 (EDT)
From: Michael Richardson 
To: saag@ietf.org
X-Mailer: MH-E 8.3; 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: Tue, 12 Mar 2013 14:20:23 -0400
Message-ID: <12252.1363112423@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org, Ted Lemon , Ralph Droms 
Subject: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 18:20:29 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


It was pointed out in a private discussion that the inclusion of
security parameters in the ROLL applicability statements might be
surprising to some.  For those who want a quick look:
  http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/
  http://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicabil=
ity/
  http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-=
building/

Specifically, people wouldn't not normally think to look at
applicability statements for a routing protocol to see that it is
specifying not just security parameters for the routing protocol=20
itself, but in some cases, requirements on access to the LLN as well.

I agreed that perhaps this needed additional socialization, which I'm
trying to do with this email.

Some of my logic of what we are doing is that by (securely) assembling
a bunch of links into a multi-link subnet, that in effect the ROLL
applicability statements are in effect a kind of IP-over-FOO document.

To parallel it to other IP-over-FOO documents better, they often specify
things like how to encapsulate, and how to do address resolution on the
subnet.=20

RPL LLNs do not use stock-ND/ARP (which normally would be specified in an
IP-over-FOO document), but rather use the RPL messages to discover other
nodes on the subnet.     I have asked that the applicability statements
be clear about if they use RFC6775 (6lowpan-ND), and if so, how.=20

It was suggested really, we never did that before: specify security of
the network in IP-over-FOO documents.  Well, that's true, because we
never did a an IP-over-802.11, because it was ethernet.

When WIFI's various incarnations happened (remember borrowing 2Mb/s *FH*
wireless PCICIA cards back at IETF46?), they tried hard to make it look
like ethernet, with ethernet-like physical security (WEP =3D=3D "Wired Equi=
valent
Privacy").  It's too bad that we didn't get more involved at the time,
in the end, we did EAP and keyprov in great part to get that part done
right.  I still think that the 802.11 security is largely a disaster.=20

It is possible that the problem is the word "applicability", and perhaps
we should have a different term.  I would welcome discussion here, or
even just +1 that this is the right approach.




=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.10 (GNU/Linux)

iQEcBAABAgAGBQJRP3HmAAoJEKD0KQ7Gj3P2fscH/0qBiwmHceSgQRLLMycvK10B
TbAe0b/3DNf5Asiyh5aEYZvxF3ovs+fJbZTbPU4DFLHS5yKT82EljsouyqM7Fkjh
BT4vX71jBKXEM6H44PTcLIfxtjRlgpsWPx40eRkcEVNiblnl4etVtWOvwKdsXGXN
4lRLIjDIi1S0WhY3czJCITcyK9U7jw+V02jzexevcVb2o5ZVlFfwzjnh85wMMsoA
SgheXScsXvYvdRQ4Bzr4qHtt3bcFMu2HZdkaqEJhMhR/3pTIixBKsxtTdn4BanNL
Z+ggTTAW8TIGdHyFjIk7H3NT0dxJuOH6D1exdhN5zWCnk/ZRW+qt6dlESj56A2w=
=JLTP
-----END PGP SIGNATURE-----
--=-=-=--

From ulrich@herberg.name  Tue Mar 12 11:31: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 CCF9311E8164 for ; Tue, 12 Mar 2013 11:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qT8-Rpgez2xB for ; Tue, 12 Mar 2013 11:31:46 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id A65E411E8165 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id p1so80593vcq.6 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3QDnNIGtnL7IyVT4Gy42llRn27yRE/3V0bWL7fcyi7w=; b=Gun6wHuC6D5RkcF5MNyqhnQ1Xl62IAurV6crJ7lV3jYKthD1GBy/k+hALFQ/JaFY9C nwlZ5y4Tbz6epqKAXFwHFj7gHE53VYqPeZF7i69kNEsQRx+mdntJBI1xyIkjbqaHQX0r yfY1mTvUNtjxYTCgxIgooa+FOKdgZbUYDegP0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3QDnNIGtnL7IyVT4Gy42llRn27yRE/3V0bWL7fcyi7w=; b=SbokIpcD3jmkw2RIZzL5B3TsH/h8BWsIHa+VA7ayOPt38GqDoAegIhLRZwB7O6WsEz Y2uVoBlSogdg9GPYbhmVfaOYgTKR5OLQGqNJn3+wNpvw6fNYcUkoBx/6FYyBhA+le6/s WPd+u4gImxS92NatSCyGJ5Xcscnnyoit74fYN9607qwPMOBF+GMiYNeIb0135A1lwjxn 8AYBytxwjHCPvvfEaUtWXrecfZCuhcPIKR8gYYgCNi8FwsNCfK3ljrmOhgSQcW70sZbh aKxPjDJQPrLVfwsEW6iCnJNwAZaPtQsFtJV6XybYqseLdMU1mND9QsHw93UIZYqrLg8E 3CQA==
MIME-Version: 1.0
X-Received: by 10.52.29.136 with SMTP id k8mr6015520vdh.40.1363113105105; Tue, 12 Mar 2013 11:31:45 -0700 (PDT)
Received: by 10.220.106.202 with HTTP; Tue, 12 Mar 2013 11:31:44 -0700 (PDT)
In-Reply-To: <12252.1363112423@sandelman.ca>
References: <12252.1363112423@sandelman.ca>
Date: Tue, 12 Mar 2013 14:31:44 -0400
Message-ID: 
From: Ulrich Herberg 
To: Michael Richardson 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkqHH9ulT4/ZgU3IvigPpmSv6+kRQ9+I+hvq+FwzLeQZ2mLAgmUiaN1iywbp6forGIgeRwS
Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms 
Subject: Re: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 18:31:47 -0000

Michael,

I think it is also worth mentioning RFC4903, in particular:

"A multi-link subnet model should be avoided.  IETF working groups
   using, or considering using, multi-link subnets today should
   investigate moving to one of the other models."

Have the issues mentioned in RFC4903 been sufficiently addressed?

Best regards
Ulrich

On Tue, Mar 12, 2013 at 2:20 PM, Michael Richardson
 wrote:
>
> It was pointed out in a private discussion that the inclusion of
> security parameters in the ROLL applicability statements might be
> surprising to some.  For those who want a quick look:
>   http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/
>   http://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicability/
>   http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-building/
>
> Specifically, people wouldn't not normally think to look at
> applicability statements for a routing protocol to see that it is
> specifying not just security parameters for the routing protocol
> itself, but in some cases, requirements on access to the LLN as well.
>
> I agreed that perhaps this needed additional socialization, which I'm
> trying to do with this email.
>
> Some of my logic of what we are doing is that by (securely) assembling
> a bunch of links into a multi-link subnet, that in effect the ROLL
> applicability statements are in effect a kind of IP-over-FOO document.
>
> To parallel it to other IP-over-FOO documents better, they often specify
> things like how to encapsulate, and how to do address resolution on the
> subnet.
>
> RPL LLNs do not use stock-ND/ARP (which normally would be specified in an
> IP-over-FOO document), but rather use the RPL messages to discover other
> nodes on the subnet.     I have asked that the applicability statements
> be clear about if they use RFC6775 (6lowpan-ND), and if so, how.
>
> It was suggested really, we never did that before: specify security of
> the network in IP-over-FOO documents.  Well, that's true, because we
> never did a an IP-over-802.11, because it was ethernet.
>
> When WIFI's various incarnations happened (remember borrowing 2Mb/s *FH*
> wireless PCICIA cards back at IETF46?), they tried hard to make it look
> like ethernet, with ethernet-like physical security (WEP == "Wired Equivalent
> Privacy").  It's too bad that we didn't get more involved at the time,
> in the end, we did EAP and keyprov in great part to get that part done
> right.  I still think that the 802.11 security is largely a disaster.
>
> It is possible that the problem is the word "applicability", and perhaps
> we should have a different term.  I would welcome discussion here, or
> even just +1 that this is the right approach.
>
>
>
>
> --
> 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
>

From mcr@sandelman.ca  Tue Mar 12 12:38: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 0458B11E80D5 for ; Tue, 12 Mar 2013 12:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, 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 64emYugE0EU4 for ; Tue, 12 Mar 2013 12:38:30 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB611E80F0 for ; Tue, 12 Mar 2013 12:38:30 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F08522060 for ; Tue, 12 Mar 2013 19:38:29 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E1ACACA0BC for ; Tue, 12 Mar 2013 15:38:27 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-reply-to: <513F6785.9020801@cisco.com>
References: <5421.1363099485@sandelman.ca>  <513F6785.9020801@cisco.com>
Comments: In-reply-to Paul Duffy  message dated "Tue, 12 Mar 2013 13:36:05 -0400."
X-Mailer: MH-E 8.3; 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: Tue, 12 Mar 2013 15:38:27 -0400
Message-ID: <16691.1363117107@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] MPL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 19:38:31 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Paul" =3D=3D Paul Duffy  writes:
    Paul> The Miple horse has already left many barns.

fair enough.  Mipple it is. (I think you have spell it with two P to get
the right sound in english)

=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.10 (GNU/Linux)

iQEcBAABAgAGBQJRP4QyAAoJEKD0KQ7Gj3P2BukH/i6+EYzxwL6Ik3O9F/vwfA2+
UMpWXsbvbtWo3oQE5qTTgaE82a4sw1B0uqqhtNqHgN9ujVVUrdsAJexujBvNqfu/
UGcZokHT5w9m0ZDsG4/yIdg/slD/iYEAwWyLi1k6sXm1HQ9azIsslGxb5+pZrkQT
AA/4X6W5ytka0OHItyQHjb+/S5v6nsSxeDrRVwUK9c3mO5v3tOx71sYGwKSesUjV
dNM0PfFGPcjAWsOPgrRVnt8ArjJm+tDs5q8NOv18Q027Xx0TlkWUNsvK/pePfEGR
rsD37ZRpfKRmBvtTHl5YEvOGkslJDX60xWQNp1S1knCOaaVPh042B5yvRzxgL+E=
=HoTK
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Tue Mar 12 12:46: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 A2C5011E80F0; Tue, 12 Mar 2013 12:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level: 
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, 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 z0mtxmscwFh0; Tue, 12 Mar 2013 12:46:08 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0EC11E8127; Tue, 12 Mar 2013 12:46:08 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 32E5722060; Tue, 12 Mar 2013 19:46:07 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 347C9CA0BC; Tue, 12 Mar 2013 15:46:06 -0400 (EDT)
From: Michael Richardson 
To: Ulrich Herberg 
In-reply-to: 
References: <12252.1363112423@sandelman.ca> 
Comments: In-reply-to Ulrich Herberg  message dated "Tue, 12 Mar 2013 14:31:44 -0400."
X-Mailer: MH-E 8.3; 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: Tue, 12 Mar 2013 15:46:05 -0400
Message-ID: <16795.1363117565@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms 
Subject: Re: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 19:46:08 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Ulrich" =3D=3D Ulrich Herberg  writes:
    Ulrich> I think it is also worth mentioning RFC4903, in particular:

    Ulrich> "A multi-link subnet model should be avoided.  IETF working gro=
ups
    Ulrich> using, or considering using, multi-link subnets today should
    Ulrich> investigate moving to one of the other models."

    Ulrich> Have the issues mentioned in RFC4903 been sufficiently addresse=
d?

I think that if we were going supposed to avoid a multi-link subnet,
that would have been objected to already.=20=20
I think that 4903 concerns applied to all of 6lowpan and ROLL work, and
I think that actually we did deal with all of these.

=2D-=20
Michael Richardson
=2Don the road-



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

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

iQEcBAABAgAGBQJRP4X8AAoJEKD0KQ7Gj3P2ADkH/izSIOeAQAxgMoXcUttMLQDc
sNS00G0ywTlgkyaHWEH1jb4frm3dQHN5ZMtttFJ/IF4quMM6dyPuVsghNLaIRMeA
5TNMw9QMW8d2mTLJhpDOWIv+7ED79wq6VDpwwcVe50dDZNB9HPPwTryfjzE//v2J
lTlsgodUu/cZTKsEyE8Wc7jFXwdRHKYCRmjZVcf+iIBdUOoyQ02RaCrLS4mx+0QY
TRwVuckrh1wpuPbyUscuMyh/r+4cCYdFSIOHSDA6en6ccgVg502Xrf8DsWhHe/Xu
ewqg74/pMrMUKy8j2atyHF49R1/DYwL4L00pYQuA/GHdMtIrxcWN+Ql9AanRcco=
=ovmM
-----END PGP SIGNATURE-----
--=-=-=--

From d.sturek@att.net  Tue Mar 12 12:59: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 BFE4211E8111 for ; Tue, 12 Mar 2013 12:59:03 -0700 (PDT)
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 qvWa2ricE+q1 for ; Tue, 12 Mar 2013 12:58:59 -0700 (PDT)
Received: from nm16-vm0.access.bullet.mail.sp2.yahoo.com (nm16-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4E86911E80D5 for ; Tue, 12 Mar 2013 12:58:55 -0700 (PDT)
Received: from [98.139.44.104] by nm16.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000
Received: from [98.138.226.241] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000
Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1363118330; bh=OYxF7Qzv5vN5RDPaAPBglfGLxut3Bunp5AU71vPm4K4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Fzs9mZXMW/M8ZjhBmGzn9f+RmWCOSRy6VTokj9qNrnmNLXqKM5F+Jd3bM9k/n2JbGzC2hI3+pjX1NpxhkFhhRIvEEHTelilEgIm/s7zqv1lhmNpfHZK7UQFZ+Y6KWI9DtkPCdXEOxdN5pfphGWfWSxKxVJboTXQDZPM9LlAqaT8=
X-Yahoo-Newman-Id: 232035.222.bm@smtp112.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: PaH4t0MVM1n8euOzwnY5Jbc9eGgC_Qw8dF9MWu7pCbsMm_V xRMy9rcwCK9QZoHXGSf2KKxEGz8RkvIadV.bH9uvf5BpPRMckEnT5em0kPTO lXewI8QcOHv9RMSSkY9KoMcOx8TfqvlzlhMJAKRd7EjVk3a8O1LBS6HAq8V8 aBnBb4ToUDrKUjCJskD2dtBjRnojmKAYiEI4V9QtIlD3cNSJQHR1j4SGyZDH 7veNW6RVNt6Z_zmOomlRJOH99neMyj35.l6ZDx5kvebd85VcMjCJ5iZbVcjT qd3EciS62lCSFHwPZBtWYzWKcEH56hPrXipaWqbC_OXbhwYwOFNuk6NGM3yy NSNHe820RiH_IYDWTNT1ovIrdo8ZM_1kSOFWSmB9g6p0g6sAYR8QqMk06Bhq Hu7DevPZH2BnS6_Ah_U_cbfh21yDdp.dglHMfELRKM3UxwdWBgmeVOrLGVMK ME_wdAbjxbS_IcphM
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [10.1.1.117] (d.sturek@66.27.60.174 with login) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 12 Mar 2013 12:58:50 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Tue, 12 Mar 2013 12:58:44 -0700
From: Don Sturek 
To: Michael Richardson , Ulrich Herberg 
Message-ID: 
Thread-Topic: [Roll] security for multi-link subnets
In-Reply-To: <16795.1363117565@sandelman.ca>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms 
Subject: Re: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 19:59:04 -0000

Hi Michael (and Ulrich),

The area that I think needs more work around the multi-link subnets topic
is the scope for site-local addresses.

Since link locals are not that useful in multi-link subnets (routing wise)
and not all devices in a 6LoWPAN/ROLL environment may want global
addresses even if such a prefix were available, clear scoping rules (eg,
routing, multicast propagation) on site local addresses is a major topic.
If someone knows of an RFC (or even a draft) that starts to address the
issue of identifying site local versus non-site prefixes/interfaces, that
would be interesting.  This topic is especially interesting in deployments
with multiple prefixes (like that now being discussed in Homenet) as well
as campus type environments.

I also bring this up (on purpose) under the topic of "security for
multi-link subnets" since turning on link security does not help securing
these networks.......

Don



On 3/12/13 12:46 PM, "Michael Richardson"  wrote:

>
>>>>>> "Ulrich" == Ulrich Herberg  writes:
>    Ulrich> I think it is also worth mentioning RFC4903, in particular:
>
>    Ulrich> "A multi-link subnet model should be avoided.  IETF working
>groups
>    Ulrich> using, or considering using, multi-link subnets today should
>    Ulrich> investigate moving to one of the other models."
>
>    Ulrich> Have the issues mentioned in RFC4903 been sufficiently
>addressed?
>
>I think that if we were going supposed to avoid a multi-link subnet,
>that would have been objected to already.
>I think that 4903 concerns applied to all of 6lowpan and ROLL work, and
>I think that actually we did deal with all of these.
>
>-- 
>Michael Richardson
>-on the road-
>
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll



From ulrich@herberg.name  Tue Mar 12 13:36: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 D4B451F0C36 for ; Tue, 12 Mar 2013 13:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6hm-d0JbBM8D for ; Tue, 12 Mar 2013 13:36:07 -0700 (PDT)
Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51821F8C8F for ; Tue, 12 Mar 2013 13:36:07 -0700 (PDT)
Received: by mail-ve0-f179.google.com with SMTP id da11so222883veb.24 for ; Tue, 12 Mar 2013 13:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FOp06LDqNC2OAeQtOlfytgoc6dVhly+Qv8Dt8u+jXTo=; b=zZ0xeCpLCSyxaQaOobOwYY/fa0+J0f4OjJZR/HBKPyW8Dh/6SjDPnBpwcPYjLnsMTM llRilkQxMPntQ/5arBlYnFHAC7xxxhqrzt75cCvPUNx+cLbuH4JyhFSBdtsUnftKPmQA 9E/P7Sct9TB5OFCmtNt0XGWWt2/J1szvDc3RM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FOp06LDqNC2OAeQtOlfytgoc6dVhly+Qv8Dt8u+jXTo=; b=dMGATLqrWpsXdtmsFjvSrNdYGLCQOoFDzdlDvwL6NmfPaET82lWO/Mtp/GTYxTd+Pa 74EBU1azIp7n1pJQxZ3ac9AL+YW+C5SArB3x+aG+1k3NzggcplvoAcPJuB2p58oWjFFe PWI3dh+i5oz0/bnUxJb2YdW4J61fFSPxpc3HItB6zJdmvMO8DlVU/KfrqcthcW/VpMuB oVYUbl1gq8V32AneDuhoaP1KXlXMpsjaxjh0JScua6X239yzS0v68p8XfkQHmx5ABODm W2IHMEOcrr565JWCJOhYnYd+16yvP/tF5q7dnF8fiju5ReVRMxBaW7kOu1FGmPbS3fjE a8NQ==
MIME-Version: 1.0
X-Received: by 10.58.188.48 with SMTP id fx16mr7285150vec.22.1363120566754; Tue, 12 Mar 2013 13:36:06 -0700 (PDT)
Received: by 10.220.106.202 with HTTP; Tue, 12 Mar 2013 13:36:06 -0700 (PDT)
In-Reply-To: <16795.1363117565@sandelman.ca>
References: <12252.1363112423@sandelman.ca>  <16795.1363117565@sandelman.ca>
Date: Tue, 12 Mar 2013 16:36:06 -0400
Message-ID: 
From: Ulrich Herberg 
To: Michael Richardson 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnu690R+HSUB30lWc1BfRMxiLVvCPF9RoNgfkwSWIpMUKQf92VpWtHxBJHzxnCGVKgJNsRD
Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms 
Subject: Re: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 20:36:09 -0000

Michael,

On Tue, Mar 12, 2013 at 3:46 PM, Michael Richardson
 wrote:
> [...]
>     Ulrich> Have the issues mentioned in RFC4903 been sufficiently addressed?
>
> I think that if we were going supposed to avoid a multi-link subnet,
> that would have been objected to already.
> I think that 4903 concerns applied to all of 6lowpan and ROLL work, and
> I think that actually we did deal with all of these.

I must have missed that discussion. Can you please point me to where
and how the issues have been solved, and why the advice of RFC4903 to
not use multi-link subnets does not apply to LLNs / to RPL?

Thanks
Ulrich

From rdroms.ietf@gmail.com  Wed Mar 13 06:37: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 B062721F87F9 for ; Wed, 13 Mar 2013 06:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.048
X-Spam-Level: 
X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=0.551, 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 aqMWWynMRc55 for ; Wed, 13 Mar 2013 06:37:18 -0700 (PDT)
Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2570F21F87AC for ; Wed, 13 Mar 2013 06:37:18 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id 1so579597qec.8 for ; Wed, 13 Mar 2013 06:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=aw2lW7qquRznIAmnHfH/bzj2sZ3wez4vpUWr0tEuPPk=; b=EKyM8z0RwLoE/fVOyL5t/OARlXmqwIG2wwSDffyC5sMUD5cIDLgRdREuk8VZYSzdqL E+LilCoNY/pCuwWL7Aa17QnkJgQAOqPX3ylqs1lpWT3q70Fv8XZzOdH+cIrsitS1MWhq odcaqVI6+prEEfJsKb6UGYsnumlG9H+MnnqrgtgA7udwud58l0lRwQdCTDU0llDp8mt0 59NIRU2No20VDjQqhkyAzyq7mVh05NLYeUlw36aWyZ4ptELy64i3QaAjEFziliDEyBzz bJGSyHbwNkUbDWHkBJGlRHVkPgjva3Qqfnri7b4D+jzCxP/ggAy4HYTQGBnf9ltbA01o ER+g==
X-Received: by 10.49.61.164 with SMTP id q4mr2834508qer.60.1363181835609; Wed, 13 Mar 2013 06:37:15 -0700 (PDT)
Received: from [10.86.255.244] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id ku2sm36660811qeb.4.2013.03.13.06.37.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 06:37:14 -0700 (PDT)
From: Ralph Droms 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Mar 2013 09:33:20 -0400
Message-Id: <0CD48245-8B5B-416B-AE6B-F780CB44B89E@gmail.com>
To: "roll@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "roll-chairs@tools.ietf.org" 
Subject: [Roll] IPv6 multicast scope 0x03 in trickle-mcast
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 13:37:18 -0000

WG - To help move the trickle multicast spec along for ZigBee, I applied =
to IANA for the well-known multicast address for ALL_MPL_FORWARDERS.

As part of the review, Stig Venaas (designated expert) pointed out that =
draft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope =
0x03, which is currently "reserved" [RFC4291].  Turns out it was never =
officially defined as "subnet-local scope" in an RFC, although it was =
identified as such in early IPv6 addressing architecture I-Ds.  So, =
something has to be done to allow MPL to use scope 0x03.

Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed =
the issue, and devised a plan to redefine scope 0x03 to be "unassigned" =
(like the other unused scope values), and then identify scope 0x03 in =
draft-ietf-roll-trickle-mcast as a special-purpose use for "trickle =
multicast networks" (rather than a "subnet").

draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but =
otherwise I think this plan should meet ZA's requirements.  Also, I'll =
need to publish a 1-paragraph RFC with the new definition of scope 0x03, =
but that will be a very quick process.

The next revision of draft-ietf-roll-trickle-mcast will include the =
necessary edits.  I'll start the process to publish the RFC to redefine =
scope 0x03 next week.

- Ralph=

From j.schoenwaelder@jacobs-university.de  Wed Mar 13 07: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 6274221F8D90 for ; Wed, 13 Mar 2013 07:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.176
X-Spam-Level: 
X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 CyIsia9W9Dog for ; Wed, 13 Mar 2013 07:22:22 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3D21F8DF1 for ; Wed, 13 Mar 2013 07:22:22 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0337720BF7; Wed, 13 Mar 2013 15:22:22 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FR0P9sVxQ-at; Wed, 13 Mar 2013 15:22:21 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9268B20BF5; Wed, 13 Mar 2013 15:22:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 844D524EBD36; Wed, 13 Mar 2013 15:22:34 +0100 (CET)
Date: Wed, 13 Mar 2013 15:22:34 +0100
From: Juergen Schoenwaelder 
To: roll@ietf.org
Message-ID: <20130313142234.GA73681@elstar.local>
Mail-Followup-To: roll@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Roll] rpl mib implementation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
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 Mar 2013 14:22:23 -0000

Hi,

we have implemented

  http://tools.ietf.org/html/draft-sehgal-roll-rpl-mib-06

on Contiki and we have put an AVR Raven online so you can throw
packets at it. For the details how to talk to this device see this
page:

  http://cnds.eecs.jacobs-university.de/the-rpl-mib-testbed/

We believe finding agreement on the instrumentation needed to monitor
and troubleshoot RPL installations would be highly useful, even if
people prefer to ship data via different protocols. Anyway, comments
and feedback are highly welcome. (If the demo fails, please send us
private emails and we will take a look at things.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From kerlyn2001@gmail.com  Wed Mar 13 07:35:03 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 9013F21F8C83 for ; Wed, 13 Mar 2013 07:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AUyULZu5wOhF for ; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id A89D921F8C5C for ; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id l20so1166533oag.9 for ; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BrspiF9dP8AUyvn8gFLKR9KoRMuZbk0UzwWBNLJPtmM=; b=y9zThpoF3Aa8OVJDmGF8wWH+NiIYlCg3Vlk2Eu29wrWrf4/NRNe4o8vSh9mPE5FR2d 1LLumnE5DEVxnwQH2JWRE+u+9SikBpnyoAjRScFooaNrBUkafHCFcPvZid05gZ9f+xge EDSTFfORN+NsKJkb+SAOpIHWtGwRIOg0T9379+W4atqK/Q/paJeZfv1ItmxHxbqamw/a 0D8Gb99telRJJ5FHjOaUKFsbhccLMGXDpg7TSn+RTcWAy8ZwvbIVQE/Ox8URQV1vLMKK w2E0NsWQ6quLPucXwafM+9eE1EJ9MGHyWEpFCQJFCvzbRz51wPYiiuGIJ9oZuH4EGDtL 4z0g==
MIME-Version: 1.0
X-Received: by 10.182.98.109 with SMTP id eh13mr16047856obb.50.1363185302299;  Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.4.233 with HTTP; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
In-Reply-To: <0CD48245-8B5B-416B-AE6B-F780CB44B89E@gmail.com>
References: <0CD48245-8B5B-416B-AE6B-F780CB44B89E@gmail.com>
Date: Wed, 13 Mar 2013 10:35:02 -0400
X-Google-Sender-Auth: iwmC0FLemQoBDsbi3rmLHs543hU
Message-ID: 
From: Kerry Lynn 
To: Ralph Droms 
Content-Type: multipart/alternative; boundary=14dae93a15c3b4ea8004d7cf4fa3
Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" , "roll@ietf.org" , "roll-chairs@tools.ietf.org" 
Subject: Re: [Roll] IPv6 multicast scope 0x03 in trickle-mcast
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Mar 2013 14:35:03 -0000

--14dae93a15c3b4ea8004d7cf4fa3
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 13, 2013 at 9:33 AM, Ralph Droms  wrote:

> WG - To help move the trickle multicast spec along for ZigBee, I applied
> to IANA for the well-known multicast address for ALL_MPL_FORWARDERS.
>
> As part of the review, Stig Venaas (designated expert) pointed out that
> draft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope
> 0x03, which is currently "reserved" [RFC4291].  Turns out it was never
> officially defined as "subnet-local scope" in an RFC, although it was
> identified as such in early IPv6 addressing architecture I-Ds.  So,
> something has to be done to allow MPL to use scope 0x03.
>
> Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed the
> issue, and devised a plan to redefine scope 0x03 to be "unassigned" (like
> the other unused scope values), and then identify scope 0x03 in
> draft-ietf-roll-trickle-mcast as a special-purpose use for "trickle
> multicast networks" (rather than a "subnet").
>
> draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but
> otherwise I think this plan should meet ZA's requirements.  Also, I'll need
> to publish a 1-paragraph RFC with the new definition of scope 0x03, but
> that will be a very quick process.
>
> The next revision of draft-ietf-roll-trickle-mcast will include the
> necessary edits.  I'll start the process to publish the RFC to redefine
> scope 0x03 next week.
>
> - Ralph
>
> I don't mean to hijack this thread, but I mentioned in the ROLL meeting
yesterday that
I'd have comments/questions regarding draft-ietf-roll-trickle-mcast-04
(MPL) and I think
they're relevant to this proposed definition of IPv6 multicast scope 0x03.

My interest is in using MPL in networks of heterogeneous links, e.g.
homenet.  My
original thinking was that when Proactive Forwarding is employed it might
be useful
to identify links that have no hidden nodes (e.g. ethernets) and suppress
repeating MPL
Data Messages on links that have this property if the message was received
on that link
(flooding bridges work this way).

In further conversation with Jonathan, it seemed that e.g. a site-scoped
message could
be propagated by MPL through a heterogeneous network using link-local
(0x02) multicast
scope and without any changes to the document.  For example, assuming a
site-scoped
multicast message originates in the 6LoWPAN it would be decapsulated at the
6LBR.
The MPL Option header could be re-written with the original packet's source
address
now included as the seed-id.  The packet is then encapsulated with
link-local multicast
scope.  Crucially, reactive forwarding is used on ethernet or other BMA
links to avoid
unnecessary traffic.  (Would this all work as I think?)

If I understand the proposed use of multicast scope 0x03, there would no
longer be a
scope boundary at the 6LBR.  Any router acting as a MPL forwarder would
presumably
treat all its ports as being in multicast scope 0x03 by default, modulo
site-boundary detection.
I think it would be useful in this context to assign proactive/reactive
forwarding behavior
on a port-by-port basis with ports on BMA (e.g. ethernet) links defaulting
to "reactive".

Thoughts?

-K-

--14dae93a15c3b4ea8004d7cf4fa3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2013 at 9:33 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:

WG - To help move the trickle multicast spec along for ZigBee, I applied to=
 IANA for the well-known multicast address for ALL_MPL_FORWARDERS.



As part of the review, Stig Venaas (designated expert) pointed out that dra=
ft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope 0x03, =
which is currently "reserved" [RFC4291]. =A0Turns out it was neve=
r officially defined as "subnet-local scope" in an RFC, although =
it was identified as such in early IPv6 addressing architecture I-Ds. =A0So=
, something has to be done to allow MPL to use scope 0x03.




Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed the =
issue, and devised a plan to redefine scope 0x03 to be "unassigned&quo=
t; (like the other unused scope values), and then identify scope 0x03 in dr=
aft-ietf-roll-trickle-mcast as a special-purpose use for "trickle mult=
icast networks" (rather than a "subnet").




draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but other=
wise I think this plan should meet ZA's requirements. =A0Also, I'll=
 need to publish a 1-paragraph RFC with the new definition of scope 0x03, b=
ut that will be a very quick process.




The next revision of draft-ietf-roll-trickle-mcast will include the necessa=
ry edits. =A0I'll start the process to publish the RFC to redefine scop=
e 0x03 next week.



- Ralph

I don't mean to hijack this thread, bu=
t I mentioned in the ROLL meeting yesterday that
I'd have comments/q=
uestions regarding draft-ietf-roll-trickle-mcast-04 (MPL) and I think

they're relevant to this proposed definition of IPv6 multicast scope 0x=
03.

My interest is in using MPL in networks of heterogeneous links, =
e.g. homenet.=A0 My
original thinking was that when Proactive Forwarding=
 is employed it might be useful

to identify links that have no hidden nodes (e.g. ethernets) and suppress r=
epeating MPL
Data Messages on links that have this property if the messa=
ge was received on that link
(flooding bridges work this way).


In further conversation with Jonathan, it seemed that e.g. a site-scoped me=
ssage could
be propagated by MPL through a heterogeneous network using l=
ink-local (0x02) multicast
scope and without any changes to the document=
.=A0 For example, assuming a site-scoped

multicast message originates in the 6LoWPAN it would be decapsulated at the=
 6LBR.
The MPL Option header could be re-written with the original packe=
t's source address
now included as the seed-id.=A0 The packet is the=
n encapsulated with link-local multicast

scope.=A0 Crucially, reactive forwarding is used on ethernet or other BMA l=
inks to avoid
unnecessary traffic.=A0 (Would this all work as I think?)<=
br>
If I understand the proposed use of multicast scope 0x03, there woul=
d no longer be a

scope boundary at the 6LBR.=A0 Any router acting as a MPL forwarder would p=
resumably
treat all its ports as being in multicast scope 0x03 by defaul=
t, modulo site-boundary detection.
I think it would be useful in this co=
ntext to assign proactive/reactive forwarding behavior

on a port-by-port basis with ports on BMA (e.g. ethernet) links defaulting =
to "reactive".

Thoughts?

-K-



--14dae93a15c3b4ea8004d7cf4fa3--

From jvasseur@cisco.com  Fri Mar 15 04:34:59 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 883A421F8D6E for ; Fri, 15 Mar 2013 04:34:58 -0700 (PDT)
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=[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 YIgl20Ji3qXL for ; Fri, 15 Mar 2013 04:34:57 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3B13121F8AA6 for ; Fri, 15 Mar 2013 04:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2784; q=dns/txt; s=iport; t=1363347297; x=1364556897; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FTGtuwefpvzz22Vkop5iWcj+qhxKdT+87GwsNVOsiH4=; b=BgpTxLKZzwZ9uLIRYB/IGI/BNE0P+afrmtj7sOVc68Qo3FbSwLFSi/Ji SJ766VSiR3groER1zX83vnWXNEzUC7M/I/ofo1WpMLKQK2I5E7OG8BLs6 5ACmUOA5u6VSJHPcA5vaSom2+eYVR0PYQars31x7YAXGEGdcor6qNk0W1 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAOAGQ1GtJV2Y/2dsb2JhbABDhCjAa4FuFnSCKwEBBAEBAWsLEAIBDAEdHQcnCxQRAgQOBQiIDAzCKwSNSoEaMQeCX2EDp1yDCoIo
X-IronPort-AV: E=Sophos;i="4.84,850,1355097600";  d="scan'208,217";a="187869316"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 15 Mar 2013 11:34:55 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2FBYsvq028701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 11:34:54 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 06:34:54 -0500
From: "JP Vasseur (jvasseur)" 
To: "roll@ietf.org WG" 
Thread-Topic: WG Last Call draft-ietf-roll-trickle-mcast-04
Thread-Index: AQHOIXEdgTiLqfJiVkmPoRqI8b/ZWg==
Date: Fri, 15 Mar 2013 11:34:54 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.73.12]
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772333BC0Dxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: Michael Richardson 
Subject: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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 Mar 2013 11:34:59 -0000

--_000_03B78081B371D44390ED6E7BADBB4A772333BC0Dxmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

All issues raised during the previous WG LC have been successfully addresse=
d in draft-ietf-roll-trickle-mcast-04.
That said, since we made several changes, this starts a 2-week WG LC that w=
ill end on March 29 at noon ET.
Thanks.

JP.

On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:

Dear all,

draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list an=
d during WG meeting a number of time; the document is stable and
has been implemented. Thus this starts a 2-week WG Last call ending on Nov =
9 at noon ET. Please send your comments to the authors
and copy the mailing list and the co-chairs.

Thanks.

JP.

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


--_000_03B78081B371D44390ED6E7BADBB4A772333BC0Dxmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Dear all,









--_000_03B78081B371D44390ED6E7BADBB4A772333BC0Dxmbrcdx02ciscoc_--

From stokcons@xs4all.nl  Fri Mar 15 07:16:03 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 6111E21F872E for ; Fri, 15 Mar 2013 07:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 vq3LijKs88nU for ; Fri, 15 Mar 2013 07:16:02 -0700 (PDT)
Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 814E921F8700 for ; Fri, 15 Mar 2013 07:16:02 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2FEG0oh031761 for ; Fri, 15 Mar 2013 15:16:00 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from dhcp-46ef.meeting.ietf.org ([130.129.70.239]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 15 Mar 2013 15:16:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Mar 2013 15:16:00 +0100
From: peter van der Stok 
To: 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
Message-ID: <535a4a0f1c3c0cab55ccbe8b3d13fda7@xs4all.nl>
X-Sender: stokcons@xs4all.nl (7dGqrvGnlKIyib8O8FOlXXMf8c2CjPgq)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 14:16:03 -0000

Hi Jonathan,

I have a few editing remarks for mpl-4 document:

  end of page 8, end of Reactive forwarding paragraph. I suggest to 
replace <..... using the Trickle algorithm> by
<.....using proactive forwarding>.

page 11, default value of DATA_MESSAGE_IMIN "10 times the worst-case 
link-layer latency"
given the medium sensing and back-off in the MAC, the worst case 
link-layer latency becomes easily 100 ms, giving a default value of 1 
second or more.
May be you mean the transmission time which has a value of 3 ms ?

page 11, default value of DATA_MESSAGE_K has value of 5, before the 
value of 1 was encouraged. Personally for me, the value 1 seems adquate.

page 15 MPL Seed Info [0..n], page 14 MPL Seed Info [1..n], Given the 
other text with bit i=0 meaning the message with seq nr min-seqno, I 
would suggest MPL Seed Info [0..n-1]

Many thanks for your work,

Peter

JP Vasseur (jvasseur) schreef op 2013-03-15 12:34:
> Dear all,
> 
> All issues raised during the previous WG LC have been successfully
> addressed in draft-ietf-roll-trickle-mcast-04.
> 
> That said, since we made several changes, this starts a 2-week WG LC
> that will end on March 29 at noon ET.
> Thanks.
> 
> JP.
> 
> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
> 
>> Dear all,
>> 
>> draft-ietf-roll-trickle-mcast-02 has been discussed on the mailing 
>> list and during WG meeting a number of time; the document is stable 
>> and
>> has been implemented. Thus this starts a 2-week WG Last call ending 
>> on Nov 9 at noon ET. Please send your comments to the authors
>> and copy the mailing list and the co-chairs.
>> 
>> Thanks.
>> 
>> JP.
>> 
>> _______________________________________________
>> 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 iesg-secretary@ietf.org  Sat Mar 16 10:17: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 88C5621F894D; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.461
X-Spam-Level: 
X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, 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 fo8cL5hlBz+r; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2780321F88F5; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
Message-ID: <20130316171751.11374.33419.idtracker@ietfa.amsl.com>
Date: Sat, 16 Mar 2013 10:17:51 -0700
Cc: roll@ietf.org
Subject: [Roll] Last Call:  (Terminology in Low	power And Lossy Networks) to Informational RFC
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 17:17:51 -0000

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Terminology in Low power And Lossy Networks'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract
   The documents defines a terminology for discussing 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.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ballot/

No IPR declarations have been submitted directly on this I-D.

From iesg-secretary@ietf.org  Sat Mar 16 10:17: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 C41C021F8995 for ; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.461
X-Spam-Level: 
X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, 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 7+S+lBjUj9UJ; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EFB21F8922; Sat, 16 Mar 2013 10:17:51 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IANA 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
X-IETF-Draft-string: draft-ietf-roll-terminology
X-IETF-Draft-revision: 12
Message-ID: <20130316171751.11374.80516.idtracker@ietfa.amsl.com>
Date: Sat, 16 Mar 2013 10:17:51 -0700
Cc: roll@ietf.org
Subject: [Roll] Last Call:  (Terminology in Low	power And Lossy Networks) to Informational RFC
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: noreply@ietf.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 17:17:51 -0000

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Terminology in Low power And Lossy Networks'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract
   The documents defines a terminology for discussing 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.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ballot/

No IPR declarations have been submitted directly on this I-D.

From sensys@cfpmail.info  Mon Mar 18 18:39: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 1B79D21F8B97 for ; Mon, 18 Mar 2013 18:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c2luwfaXZhHc for ; Mon, 18 Mar 2013 18:39:21 -0700 (PDT)
Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F05721F8B96 for ; Mon, 18 Mar 2013 18:39:17 -0700 (PDT)
Received: by mail-vb0-f47.google.com with SMTP id e21so3849560vbm.34 for ; Mon, 18 Mar 2013 18:39:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:content-transfer-encoding:x-gm-message-state; bh=i73Urc4/SBOJ1cLOeIWmVsUccCkwTFDfqlQAaBHqTQg=; b=Tp255YMWPLo+zOdqvktU5sW5EHgIhl+vqwknekplQjgP/Bh4gWUzrGRWNg2qej/zJC +iBhfrosO+C63SDwJpqbc2/Ad0HshE8AuHHx30bS0UcTnhAQviWECL+aD6f8WIgss63H I9BtGBViUpvdrJNcX6OO429R9RpMW7MCZYpo++1V2FcShS3Yx9TW/cIWMthfUbM8ykIY NKRGCNeTj+AGN+wr9/E9TwcrbGq21zXaPont1H5OR/g+jc/dPZdU5ZsovqF2nvQpYDVE vHSdZpeV7/Q68CjYh7ITtp58W75eEYXYNDlw12WNnfsod8jCX48uphQOym0O33LmpPIS +UxA==
MIME-Version: 1.0
X-Received: by 10.220.221.143 with SMTP id ic15mr306342vcb.32.1363657156522; Mon, 18 Mar 2013 18:39:16 -0700 (PDT)
Received: by 10.52.160.104 with HTTP; Mon, 18 Mar 2013 18:39:16 -0700 (PDT)
X-Originating-IP: [71.195.166.116]
Date: Mon, 18 Mar 2013 18:39:16 -0700
Message-ID: 
From: "SenSys'13 Publicity" 
To: usn-sankasha@mail.ieice.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnwBz4xB6U7/jDEwdtm6io73MFv50UpcpKnY5GI/RlDGL9xLQckc6zRLc3DZXWPtRB1THp/
X-Mailman-Approved-At: Tue, 19 Mar 2013 05:32:16 -0700
Subject: [Roll] Call for Papers - ACM SenSys 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: Tue, 19 Mar 2013 01:39:22 -0000

[Apologies in advance for any cross-postings]

***************************************************************************=
************************
Call For Papers
SenSys 2013---The 11th ACM Conference on Embedded Networked Sensor Systems

November 11-15, 2013
Rome, Italy
***************************************************************************=
*************************
Sensing systems are changing the way computers interact with the
physical world -- and are driving a host of new issues in computer
system design, implementation, and performance.

SenSys 2013 is the premier venue to discuss system issues raised by
emerging trends in sensing systems =96 broadly defined to include mobile
sensing, body sensing, Kinect, camera networks, RFID, and many others.

We solicit technical papers describing original ideas, ground breaking
results and/or quantified system experiences involving sensor systems.
 The conference values papers that take a broad systems perspective
rather than a narrow focus on individual components.  Of particular
interest are technical contributions that enable new and compelling
sensing applications.

Topics of interest include, but are not limited to, the following:
=95	Experience with real-world applications
=95	Innovative sensing applications (e.g., mobile healthcare,
transportation, buildings)
=95	New models of sensor usage (e.g., mobile sensing, body sensing, RFIDs, =
robots)
=95	Sensor data quality, integrity, and trustworthiness
=95	Challenges for =93Big Sensor Data=94
=95	Sensor data storage, retrieval, processing and management
=95	Data reduction, inference, and signal processing
=95	Fault-tolerance and reliability
=95	Provable correctness and performance guarantees
=95	Support for integrated sensing, actuation and control
=95	Wireless communication systems and protocols
=95	Energy management and energy harvesting
=95	Resource management and OS support
=95	Programming paradigms for sensing systems
=95	Security and privacy in sensor networks
=95	Time and location estimation and management

Detailed submission instructions can be found at
http://sensys.acm.org/2013/submissions/

Key Dates
These are hard deadlines: No extensions will be granted.
=95	Paper Registration: March 30, 2013, 11:59 pm EST.
=95	Paper Submission Deadline: April 6, 2013, 11:59 pm EST.
=95	Notification of Paper Acceptance: July 15, 2013.

General Chair
Chiara Petrioli (University of Rome 'La Sapienza')

Program Chairs
Landon Cox (Duke University)
Kamin Whitehouse (University of Virginia)

Poster Chair
Chenyang Lu (Washington University in St. Louis)
Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien=
ce)

Demo Chairs
Emiliano Miliuzzo (AT&T Labs)
Amy Murphy (FBK)

Local Arrangements Chairs
Francesca Cuomo, Gaia Maselli, Andrea Vitaletti (University of Rome
'La Sapienza')

Finance Chair
Rasit Eskicioglu (University of Manitoba)

Publicity Chairs
Stefano Basagni (Northeastern University)
Alberto Cerpa (University of California, Merced)
Salil Kanhere (University of New South Wales)
Mike Chieh-Jan Liang (Microsoft Research Asia)

Publicaton Chair
Wendi Heizelman (University of Rochester)

Workshop Chairs
Luca Benini (ETHZ & University of Bologna)
Deepak Ganesan (UMASS Amherst)

Industrial Liaison Chairs
Jie Liu (Microsoft Research)
Adam Wolisz (Technische Universitat Berlin)

N2Women Chair
Niki Trigoni (University of Oxford)

Doctoral Colloquium Chair
Cecilia Mascolo (University of Cambridge)

Student Travel Award Chair
Pedro Marron (University of Duisburg-Essen)
Radu Stoleru (Texas A&M University)

Web Site Chair
David Boyle (Imperial College London)

Technical Program Committee
Yuvraj Agarwal (University of California, San Diego)
Jan Beutel (Swiss Federal Institute of Technology, Zurich)
Geoffrey Challen (University at Buffalo)
Tanzeem Choudhary (Cornell University)
David Chu (Microsoft Research, Redmond)
Deborah Estrin (Cornell Tech)
Wen Hu (CSIRO, Australia)
Fred Jiang (Intel Labs, China)
Nic Lane (Microsoft Research, Asia)
Jie Liu (Microsoft Research, Redmond)
Pedro Jose Marron (University of Duisburg Essen)
Cecilia Mascolo (University of Cambridge)
Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien=
ce)
Lama Nachman (Intel Labs)
Gian Pietro Picco (University of Trento)
Raj Rajkumar (Carnegie Mellon University)
Anthony Rowe (Carnegie Mellon University)
Romit Roy Choudhury (Duke University)
Silvia Santini (Technische Universitat Darmstadt)
Mahadev Satyanarayanan (Carnegie Mellon University)
Thomas Schmid (University of Utah)
Junehwa Song (Korean Advanced Institute of Science and Technology)
Niki Trigoni (University of Oxford)
Lin Zhong (Rice University)

From internet-drafts@ietf.org  Wed Mar 20 09:05: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 07B4E21F9037; Wed, 20 Mar 2013 09:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.429
X-Spam-Level: 
X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.171, 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 pArvhG6FwKhU; Wed, 20 Mar 2013 09:05:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4AD21F903B; Wed, 20 Mar 2013 09:05:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
Message-ID: <20130320160538.22616.92349.idtracker@ietfa.amsl.com>
Date: Wed, 20 Mar 2013 09:05:38 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-17.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, 20 Mar 2013 16:05:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : Reactive Discovery of Point-to-Point Routes in Low Power=
 and Lossy Networks
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Matthias Philipp
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-rpl-17.txt
	Pages           : 39
	Date            : 2013-03-20

Abstract:
   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover "on demand" routes to one or more IPv6
   routers in the LLN such that the discovered routes meet specified
   metrics constraints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-17

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-17


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From prvs=78581f61c=mukul@uwm.edu  Wed Mar 20 21:55:58 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 1A74921F8585 for ; Wed, 20 Mar 2013 21:55:58 -0700 (PDT)
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 kHndL+ptXBxo for ; Wed, 20 Mar 2013 21:55:50 -0700 (PDT)
Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11621F8E38 for ; Wed, 20 Mar 2013 21:55:48 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoEACqRSlF/AAAB/2dsb2JhbABDhUeCWr0bgW+DGAEBAQQBAQEgSzcEAQEDAg0ZAikmAggGEwmICwcFoTSOVYkriQ+BI4w+exIXEgaCJ4ETA4h1jWuBH49jgyiCCg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id CE4E21210FA for ; Wed, 20 Mar 2013 23:55:47 -0500 (CDT)
X-Virus-Scanned: amavisd-new at 
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSf2jZP159cw for ; Wed, 20 Mar 2013 23:55:47 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 8358A1210DB for ; Wed, 20 Mar 2013 23:55:47 -0500 (CDT)
Date: Wed, 20 Mar 2013 23:55:47 -0500 (CDT)
From: Mukul Goyal 
To: roll < roll@ietf.org>
Message-ID: <1775590041.43590.1363841747387.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20130320160538.22616.92349.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - [unknown] (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Subject: [Roll] Fwd:  I-D Action: draft-ietf-roll-p2p-rpl-17.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, 21 Mar 2013 04:55:58 -0000

Hi all

Besides a number of editorial changes, the new version (-17) has the following key changes over the previous version:

1) The data option has been removed.
2) Only options allowed in a P2P mode DIO are: P2P-RDO, the dodag configuration option, the target option, the metric container options, the route information option. Any other option (in particular a prefix information option) found inside a P2P mode DIO will be ignored.
3) Suggested rules for RPLInstanceID reuse (Section 6.1).
4) Included the requirement that addresses in the TargetAddr and Address vector fields inside a P2P-RDO MUST be global or unique local (section 7).
5) Clarified that it is not possible to solicit P2P mode DIOs using DIS messages (Section 9.1)
6) Added a new section "Secure P2P RPL Operation". The basic requirement is that all routers participating in a secure P2P-RPL route discovery MUST follow the same Security Configuration ( tuple) as the Origin. Also disallowed the use of per-pair keys for a P2P-RPL route discovery.
7) Updated the "Security Considerations" section in view of the new "Secure P2P RPL Operation" section.

Thanks
Mukul


----- Forwarded Message -----
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: roll@ietf.org
Sent: Wednesday, March 20, 2013 11:05:38 AM
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-17.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Matthias Philipp
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-rpl-17.txt
	Pages           : 39
	Date            : 2013-03-20

Abstract:
   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover "on demand" routes to one or more IPv6
   routers in the LLN such that the discovered routes meet specified
   metrics constraints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-17

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-rpl-17


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From mcr@sandelman.ca  Thu Mar 21 07:46:43 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 A6E7921F90B4 for ; Thu, 21 Mar 2013 07:46:43 -0700 (PDT)
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 vqfG+9Dy-qXe for ; Thu, 21 Mar 2013 07:46:43 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CFFFE21F9096 for ; Thu, 21 Mar 2013 07:46:40 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4DABB2016D for ; Thu, 21 Mar 2013 10:55:01 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 678BC63860; Thu, 21 Mar 2013 10:46:24 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B7ED63827 for ; Thu, 21 Mar 2013 10:46:24 -0400 (EDT)
From: Michael Richardson 
To: Routing Over Low power and Lossy networks 
In-Reply-To: <1775590041.43590.1363841747387.JavaMail.root@mail17.pantherlink.uwm.edu>
References: <1775590041.43590.1363841747387.JavaMail.root@mail17.pantherlink.uwm.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
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] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-17.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, 21 Mar 2013 14:46:43 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Mukul" =3D=3D Mukul Goyal  writes:
    Mukul> Hi all

    Mukul> Besides a number of editorial changes, the new version (-17)
    Mukul> has the following key changes over the previous version:

Thank you Mukul, for persuing this process with the IESG reviewers.

My opinion is that much of this should have happened in sight of the WG,
but there is some changing IESG view as to how to do this.

I'd like to ask the WG to think strongly about the changes that have
occurred.    Do they affect your current or future usage of P2P?

If they do, then I think we need to talk about whether this means you
will write an enhancement document... reminding that P2P is going
forward as Experimental.  Likely it will switch tracks in 12 months once
there is some significant deployment reports.

We are in IESG review process, and we aren't doing another WGLC on
this.  My opinion is that none of the things changed affect real use=20
cases that people currently deploying care about.

(and also thanks to the other authors)

(And remind that we a WGLC on mcast-trickle, aka "MPL" aka "Mipple")

=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)

iQCVAwUAUUsdQIqHRg3pndX9AQKIaQQA8La79TPQS7PnBcrF07mE3PDYW2FrhtL2
bk1YVqUh2xv6yXJjKLzZhC2e8/QkOPLct8RI7jjO0mYLTDPR7Rf1L5MzfCF/ZoJq
U+RyGNLS0K1ikIVA81mQei0OiUREsu+eZ9uGjH4K+GTNxpRgCV2pFwd4gja7HObt
Z6ESqIRuvfQ=
=YuHI
-----END PGP SIGNATURE-----
--=-=-=--

From prvs=78581f61c=mukul@uwm.edu  Thu Mar 21 08:07: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 0028F11E80BF for ; Thu, 21 Mar 2013 08:07:23 -0700 (PDT)
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 IWMOqrEtH3sZ for ; Thu, 21 Mar 2013 08:07:23 -0700 (PDT)
Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E711E80BA for ; Thu, 21 Mar 2013 08:07:23 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEALMgS1F/AAAB/2dsb2JhbABDiB+9F4FugxgBAQEEAQEBIEsXDxEEAQEDAg0ZAikoCAYTiBQMoWCOVYkuiQ+BI4w/eykSBoIngRMDiHeNbYEfj2ODKIIK
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9F92F120CCD for ; Thu, 21 Mar 2013 10:07:22 -0500 (CDT)
X-Virus-Scanned: amavisd-new at 
Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVWvglUB26zf for ; Thu, 21 Mar 2013 10:07:22 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 58281120CCB for ; Thu, 21 Mar 2013 10:07:22 -0500 (CDT)
Date: Thu, 21 Mar 2013 10:07:22 -0500 (CDT)
From: Mukul Goyal 
To: Routing Over Low power and Lossy networks 
Message-ID: <1658041537.46549.1363878442228.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <24467.1363877184@sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-17.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, 21 Mar 2013 15:07:24 -0000

Hi Michael

>My opinion is that none of the things changed affect real use 
cases that people currently deploying care about.

That is my opinion too.

Thanks
Mukul

----- Original Message -----
From: "Michael Richardson" 
To: "Routing Over Low power and Lossy networks" 
Sent: Thursday, March 21, 2013 9:46:24 AM
Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-17.txt


>>>>> "Mukul" == Mukul Goyal  writes:
    Mukul> Hi all

    Mukul> Besides a number of editorial changes, the new version (-17)
    Mukul> has the following key changes over the previous version:

Thank you Mukul, for persuing this process with the IESG reviewers.

My opinion is that much of this should have happened in sight of the WG,
but there is some changing IESG view as to how to do this.

I'd like to ask the WG to think strongly about the changes that have
occurred.    Do they affect your current or future usage of P2P?

If they do, then I think we need to talk about whether this means you
will write an enhancement document... reminding that P2P is going
forward as Experimental.  Likely it will switch tracks in 12 months once
there is some significant deployment reports.

We are in IESG review process, and we aren't doing another WGLC on
this.  My opinion is that none of the things changed affect real use 
cases that people currently deploying care about.

(and also thanks to the other authors)

(And remind that we a WGLC on mcast-trickle, aka "MPL" aka "Mipple")

-- 
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

From mcr@sandelman.ca  Fri Mar 22 11:16: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 3EEB421F8FDC for ; Fri, 22 Mar 2013 11:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Level: 
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
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 QQ59iUn0Skw8 for ; Fri, 22 Mar 2013 11:16:06 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C45ED21F8FD4 for ; Fri, 22 Mar 2013 11:16:05 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id E834C2016D for ; Fri, 22 Mar 2013 14:24:36 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3784A639D7; Fri, 22 Mar 2013 14:15:55 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 27E6F639D5 for ; Fri, 22 Mar 2013 14:15:55 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
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: [Roll] DRAFT minutes from IETF86
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, 22 Mar 2013 18:16:07 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


Thank you to Dan King and Ines Robles for these notes.

TUESDAY, March 12, 2013
0900-1020 Morning Session I
ROLL WG

AllSlides
Home/Building/P2P Applicability Status
6tsch work
industrial applicability

1) Note Well and Agenda Bashing

2) Document status

draft-ietf-roll-p2p-measurement-09

draft-ietf-roll-p2p-rpl-16

Feature discussion, sending data in a payload. Discussion regarding the data
format and is it application specific.
Also if prefix information object was valid for P2P. You need source route
info, what would be the preference. There is a restricted set of P2P DIOs,
any changes will need justification.

draft-ietf-roll-security-threats-01

Adrian Farrel (as AD) provided SECDIR review update. If authors have a new
version in the next week then it can be kept on the agenda. Co-chairs to
make the authors aware of this.

draft-ietf-roll-terminology-11

AD has provided review/comments. Author has reissued the document.

=2D

draft-ietf-roll-trickle-mcast-04

=2D

Comment from WG that DNS service discovery, in context of home net/college
campuses, et al., as a method of lightweight distribution. Commentator will
post comments on list.

3) Applicability Statements

draft-brandt-roll-rpl-applicability-homebuilding

=2D

Comments on the use of RPL in Building and Home Environments. It was felt
that more info was needed, especially regarding configuration parameters.
Specifically on infrastructure nodes and p2p traffic.

Suggestion to focus on indoor building commercial applications, controlled
environments, and remove home content.

Co-chairs reluctant to change the name, but fine to reaffirm the building
applicability, and list technologies.

Co-chairs reiterated that the document should reflect goals of the group.
Furthermore, a request to avoid biasing or restricting technology (P2P, MPL,
DNS, IPv6, etc.) the solution in the document.

Document needs to be applicable to p2p and infrastructure.

Co-chairs would like to target Last Call around IETF 88.



4) Discussion/question: do applicability statements stand alone?

No comments.



5) 6TSCH summary/invite


New mailing list 6tsch (http://www.ietf.org/mail-archive/web/6tsch/)
Discussions have included audio conferences. Webex info published for access
on the list (above).
Discussing use cases and problem statements.
Comment made regarding time synchronization and reservation. Are existing
tools are being considered (including NTP). Confirmed that NTP is used on
the backbone, and across LLNs it would be complimentary.
Various aspects of synchronization discussed in architecture document.
However, it is important to consider synchronisation versus energy trade
off.
All options are being explored. As is various applicability to other
technologies.
Concerns raised that any potential solution(s) need(s) to scale to
potentially millions of devices.
Request that people participate on the list, and the informal sessions (one
of which follows the ROLL WG).
See the list for notification of interim meetings.




=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)

iQCVAwUAUUyf2oqHRg3pndX9AQK/6QQAtJVOCTo2a8fS8wx//jLDeFmqzUvfOVvz
8prDIBu/NjAszRygEqLuGlqdksUYFNVA/Y81a34HICNGoz8FYBPxvR/0cls39/P+
C3ZosgErqV9OhNhFDE3F9QgEA+dvvAQmTZfG4YU3K1gf2XDfUfc7W06T7/F33e+E
y0n2KiYVYwU=
=qhQB
-----END PGP SIGNATURE-----
--=-=-=--

From alfragk@gmail.com  Thu Mar 28 07:32: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 8DDAD21F8E7B for ; Thu, 28 Mar 2013 07:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nhtNOUDjh8Vk for ; Thu, 28 Mar 2013 07:32:52 -0700 (PDT)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5FB521F8D92 for ; Thu, 28 Mar 2013 07:32:51 -0700 (PDT)
Received: by mail-ee0-f45.google.com with SMTP id b57so4803941eek.4 for ; Thu, 28 Mar 2013 07:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=leIX+FYQXTCXd9xe6zbHcHhNBBEaTfKUmXOEu0Xv7Po=; b=RidoXMGke0fjYLIIIgO/9AL6tKlUr5byUh5sov/mFaiTNgYaaUaC1XTfPh/+4QqBAG OttDgulFXz1f3PHp3xZ4sJ1dP2t3fbfn6ptucLz3mDFWFJZfe17gKEYVJsJX/IX6OQTU pEQF5QB7XVKvSxo/U0SSm79+SJ9AZFKaD0xGEc2KEQTk9qa+0JgZMaoa4NleKYpjjGy5 b8giU/QS68fDv3cdD+LcPxA6z0zQHz9WDvxln5+XYa+0sighoO8Fo+VifI8rSQpjY47O cv5xN+F3IIsgDCdi47lbu8zNu/JNohg4ZaFCL5iOO/jDOG9QhcLOh2pzZ03T/4OV/KnX 9AKA==
X-Received: by 10.14.183.67 with SMTP id p43mr53294751eem.10.1364481170849; Thu, 28 Mar 2013 07:32:50 -0700 (PDT)
Received: from [139.91.68.29] ([139.91.68.29]) by mx.google.com with ESMTPS id u44sm38104663eel.7.2013.03.28.07.32.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 07:32:49 -0700 (PDT)
Message-ID: <5154548A.3080600@gmail.com>
Date: Thu, 28 Mar 2013 16:32:42 +0200
From: Alex 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110323 Lanikai/3.1.9
MIME-Version: 1.0
To: roll@ietf.org
Content-Type: multipart/alternative; boundary="------------090308030202070600070405"
Subject: [Roll] RPL code for Omnet
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, 28 Mar 2013 14:34:58 -0000

This is a multi-part message in MIME format.
--------------090308030202070600070405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

i've repeatedly used RPL in wireless sensor networks using the Contiki OS.

Now i'd like to test RPL functionalities in the OMNET simulator.

Are you aware of any RPL source code for Omnet?


Thanks in advance,

Alex

--------------090308030202070600070405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear all,

      

      i've repeatedly used RPL in wireless sensor networks using the
      Contiki OS. 

      

      Now i'd like to test RPL functionalities in the OMNET simulator.

      

      Are you aware of any RPL source code for Omnet?

      

      

      Thanks in advance,

      

      Alex

    
  


--------------090308030202070600070405--

From adrian@olddog.co.uk  Fri Mar 29 03:58: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 62AE121F8FDC for ; Fri, 29 Mar 2013 03:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  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 5KOtE6KbbwqC for ; Fri, 29 Mar 2013 03:58:09 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED1B21F8F1E for ; Fri, 29 Mar 2013 03:58:09 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2TAw8Kl008565 for ; Fri, 29 Mar 2013 10:58:08 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2TAw7H8008551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Mar 2013 10:58:07 GMT
From: "Adrian Farrel" 
To: "'Routing Over Low power and Lossy networks'" 
References: <1775590041.43590.1363841747387.JavaMail.root@mail17.pantherlink.uwm.edu> <24467.1363877184@sandelman.ca>
In-Reply-To: <24467.1363877184@sandelman.ca>
Date: Fri, 29 Mar 2013 10:58:08 -0000
Message-ID: <00bd01ce2c6c$4c9a16e0$e5ce44a0$@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: AQIhz/t+oC75I4BvrT70VQ84+CtTnAHDuqAlmAcaLOA=
Content-Language: en-gb
Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-17.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 29 Mar 2013 10:58:10 -0000

Hi,

Thanks, Michael for taking the care to ask the question, below.
I have waited a week and have heard only form you and Mukul, both saying that
you don't think the changes affect real use cases for today.

So I will now go ahead and resume processing of the document.

Thanks to all, and especially Mukul, for getting the issues resolved.

Cheers,
Adrian

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Michael
> Richardson
> Sent: 21 March 2013 14:46
> To: Routing Over Low power and Lossy networks
> Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-17.txt
> 
> 
> >>>>> "Mukul" == Mukul Goyal  writes:
>     Mukul> Hi all
> 
>     Mukul> Besides a number of editorial changes, the new version (-17)
>     Mukul> has the following key changes over the previous version:
> 
> Thank you Mukul, for persuing this process with the IESG reviewers.
> 
> My opinion is that much of this should have happened in sight of the WG,
> but there is some changing IESG view as to how to do this.
> 
> I'd like to ask the WG to think strongly about the changes that have
> occurred.    Do they affect your current or future usage of P2P?
> 
> If they do, then I think we need to talk about whether this means you
> will write an enhancement document... reminding that P2P is going
> forward as Experimental.  Likely it will switch tracks in 12 months once
> there is some significant deployment reports.
> 
> We are in IESG review process, and we aren't doing another WGLC on
> this.  My opinion is that none of the things changed affect real use
> cases that people currently deploying care about.
> 
> (and also thanks to the other authors)
> 
> (And remind that we a WGLC on mcast-trickle, aka "MPL" aka "Mipple")
> 
> --
> Michael Richardson , Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/



From cabo@tzi.org  Fri Mar 29 06:22: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 9825721F9403; Fri, 29 Mar 2013 06:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.156
X-Spam-Level: 
X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 FNa9NZvslK2G; Fri, 29 Mar 2013 06:22:13 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9721F9401; Fri, 29 Mar 2013 06:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TDM6lV003394; Fri, 29 Mar 2013 14:22:06 +0100 (CET)
Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2BDE136A2; Fri, 29 Mar 2013 14:22:06 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <26808a929674c2b96850f40a9d7cd686@xs4all.nl>
Date: Fri, 29 Mar 2013 14:22:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <18113.1339529290@marajade.sandelman.ca>   <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl>
To: "6lowpan@ietf.org" <6lowpan@ietf.org>
X-Mailer: Apple Mail (2.1503)
Cc: roll@ietf.org, "ipv6@ietf.org List" , "core \(core@ietf.org\)" 
Subject: [Roll] GHC now crunches DTLS (Re:  [6lowpan]  draft-bormann-ghc)
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, 29 Mar 2013 13:22:16 -0000

On Aug 25, 2012, at 13:41, peter van der Stok  =
wrote:

> GHC applied to DTLS encrypted messages is interesting indeed. It may =
represent an important number of messages to transmit.
> I would concentrate on getting the GHC on DTLS results known and then =
start pushing ghc draft.

It took a while, but is now done:  GHC-06 is ready for consumption.

Htmlized:       =20
http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-06
Diff:           =20
http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lowpan-ghc-06

It turns out my gut feeling about how to design this was just about =
right, so with all the research done, the only technical change from the =
previous version is the addition of a 16-byte static dictionary.  This =
should result in about a 3-line change in an implementation (and 16 =
bytes of increased temporary buffer size).  The specification no longer =
fits on a single page because that includes a note about the reserved =
code points.

I also have removed the speculative parts of GHC-05 -- there was little =
interest in the added complexity.  There is a little bit of innovative =
formatting because I'm using XML2RFCv2 now; there should be fixes for =
this soon.

The examples have been expanded to show the compression of DTLS =
handshake and application data messages; if you subtract the actual =
payload (cleartext and authenticator), the total DTLS overhead is around =
8 bytes for application data (so, including the =
TLS_PSK_WITH_AES_128_CCM_8 authenticator, a DTLS message is 16 bytes =
longer than an uncompressed NoSec one). The examples section also shows =
the very slight overall improvement to the compression (including a =
regression, where the example ND advertisement now needs a byte more).

I'm pretty sure now that we have reached the point of diminishing =
returns.
If we still had an active WG, I'd go for WG adoption and a WGLC soon.
We'll see how to handle this in the shutdown phase of the 6lowpan WG.
In the meantime, please do send in your comments (preferably to the =
6LoWPAN list).

I'm CCing 6man because part of the proposal is a new ND (ICMPv6) option =
for node capability indication.
Specific comments on that probably best go to the 6man mailing list.

Gr=FC=DFe, Carsten


From kerlyn2001@gmail.com  Fri Mar 29 07:20:34 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 0166521F9437 for ; Fri, 29 Mar 2013 07:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MVcwjbWncWuV for ; Fri, 29 Mar 2013 07:20:32 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2E21F9435 for ; Fri, 29 Mar 2013 07:20:29 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id n1so449693oag.23 for ; Fri, 29 Mar 2013 07:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sXUlHrow9nY5BanVNy5eStS4Q0dQKVdTDejP3oeB55k=; b=jPSoCOjmO0dpWWpGB8jnpMfkS50SGMVfYi3kCliR/fDh43HFHfBwAvZ4t+MAhD1WMJ oW5G6U5ji1rN9WID/5fk3uiF01JYJ2TjBLx9jjeFw8Axq07dMx6ptFzuOns15DUAv4mE G61gvlHGdph/ffFwCQm9BNMMMz9D5pHSdYcYhxB59jVwja0Y5MHT0nkO9KCpKeIjkde2 V3u4tcMF4fRPunBD0BkSPeQ7NVsjnNa+L6NhgCS6oqJSZpgbTfuOSngF5udWeHK+nca+ OHMB8lhXudpGcCdqyH4hJHRKkWrPhvsYHKTBGEiv2Tpu2VeLyRKNCS+yWJXgt5SE6Y8t QmpA==
MIME-Version: 1.0
X-Received: by 10.182.160.106 with SMTP id xj10mr869440obb.98.1364566829465; Fri, 29 Mar 2013 07:20:29 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.33.74 with HTTP; Fri, 29 Mar 2013 07:20:29 -0700 (PDT)
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
Date: Fri, 29 Mar 2013 10:20:29 -0400
X-Google-Sender-Auth: flXPFOgdPYhQfOrKVA1gPJmmA6I
Message-ID: 
From: Kerry Lynn 
To: "Jonathan Hui (johui)" , Richard Kelsey 
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll@ietf.org, Michael Richardson 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 14:20:34 -0000

Greetings,

Apart from the fact that this draft is introduced in ROLL to address a problem
inherent in multi-link subnets, I see nothing in the proposal that
limits it to such
networks.  It seems to me that trickle multicast could be considered in other
applications, e.g. homenet, if it compares favorably with PIM-xM in complexity.

In reading trickle multicast in this more general way, I'd like to see
additional
clarification regarding the use of Proactive Forwarding.  Section 4.2 reads:

   Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
      schedules transmissions of MPL Data Messages using the Trickle
      algorithm, without any prior indication that neighboring nodes
      have yet to receive the message.  After transmitting the MPL Data
      Message a limited number of times, the MPL Forwarder may terminate
      proactive forwarding for the MPL Data Message message.

I think the final sentence should read:

     After transmitting the MPL Data Message a limited number of times, the
     MPL Forwarder MUST terminate forwarding of the MPL Data Message.

This eliminates the possible interpretation that both Proactive and Reactive
Forwarding may be used by the same MPL Forwarder for the same MPL
Data Message within the same MPL Domain.  I believe the intent is that
Proactive and Reactive Forwarding should be mutually exclusive within
the same MPL Domain?

In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
Parameter".  I believe this should be set (or not) on a MPL Domain basis
(and therefore as an attribute of the Local Interface).  Again, it should be
made clear that Proactive and Reactive Forwarding are mutually exclusive,
e.g. by adding a sentence to the end of the first paragraph in section 5.4:

     If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
     is in use.

This ties it to section 5.1, which mandates MPL Control Messages on an
interface where Reactive Forwarding is in use.

I believe that section 5.5 should also be clarified with respect to the meaning
of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
read:

   This specification defines a fourth Trickle configuration parameter,
   TimerExpirations, which indicates the number of Trickle timer
   expiration events that occur before terminating the forwarding of a
   given MPL Data Message.

This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
number of times" statement in section 4.2.  Similarly, the definition of
DATA_MESSAGE_TIMER_EXPIRATIONS should read:

   DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
      expirations that occur before terminating the Trickle algorithm's
      re-transmission of a given MPL Data Message.
      DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.

This eliminates the possible interpretation that the Trickle algorithm may
not be used for subsequent MPL Data Messages.


Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
to suggest that this parameter should be described as the number of
doublings of Imin: "For example, a protocol might define Imax as 16."
If this interpretation is correct, then DATA_MESSAGE_IMAX should be
set to 0 in order to limit Imax to Imin.

Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
number of doublings, or at least specified in terms of worst-case link-
layer latency if my interpretation of RFC 6202 is incorrect.

The implication of specifying Imax = Imin seems to be that the dithering
interval for MPL Data Message re-transmission will *always* be [Imin/2,
Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
which is presumably the point for specifying the default values as they are.


Regarding the definition of MPL Domains, section 8 states:

   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 (subnet-local).

As Ralph Droms indicated in
http://www.ietf.org/mail-archive/web/roll/current/msg07829.html, "something
has to be done to allow MPL to use scope 0x03."  In the most expedient
scenario, 0x03 is re-defined from "reserved" to "undefined" and the proposal
then gets to define how 0x03 is used by trickle multicast.

Assuming the desired use of 0x03 multicast scope is to indicate
ALL_MPL_FORWARDERS within a given prefix, the question is how to
indicate the prefix in question?  RFC 6282 allows for the stateful compression
of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section 4.2
allows for the assignment of "Permanent IPv6 Multicast Group Identifiers"
for use with RFC 3306 multicast addresses.  Therefore it seems prudent to
also request from IANA a Permanent IPv6 Multicast Group Identifier
http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xml
to allow for the possibility of specifying the desired prefix in the MPL Domain
Address.


Lastly, to improve the clarity of section 11.2, the first bullet should read:

   o  This document defines a "consistent" transmission as receiving an
      MPL Control Message that results in a determination that neither the
      receiving nor transmitting node has any new MPL Data Messages to offer.

(The transmission indicates nothing about state at the receiver.)  Similarly,
the second bullet should read:

   o  This document defines an "inconsistent" transmission as receiving
      an MPL Control Message that results in a determination that either the
      receiving or transmitting node has at least one new MPL Data Message
      to offer.

It might be helpful to add a penultimate sentence to section 11.2:

      The Trickle timer is reset in response to external "events".

Regards, -K-


On Fri, Mar 15, 2013 at 7:34 AM, JP Vasseur (jvasseur)
 wrote:
>
> Dear all,
>
> All issues raised during the previous WG LC have been successfully addressed in draft-ietf-roll-trickle-mcast-04.
> That said, since we made several changes, this starts a 2-week WG LC that will end on March 29 at noon ET.
> Thanks.
>
> JP.
>
> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>
> Dear all,
>
> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list and during WG meeting a number of time; the document is stable and
> has been implemented. Thus this starts a 2-week WG Last call ending on Nov 9 at noon ET. Please send your comments to the authors
> and copy the mailing list and the co-chairs.
>
> Thanks.
>
> JP.
>
> _______________________________________________
> 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 Mar 29 07:37: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 30F2221F9333 for ; Fri, 29 Mar 2013 07:37:41 -0700 (PDT)
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 qWZ0pcSnEkR3 for ; Fri, 29 Mar 2013 07:37:39 -0700 (PDT)
Received: from nm26-vm0.access.bullet.mail.mud.yahoo.com (nm26-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.225]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE621F931B for ; Fri, 29 Mar 2013 07:37:39 -0700 (PDT)
Received: from [66.94.237.126] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 14:37:39 -0000
Received: from [98.138.84.213] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 14:37:39 -0000
Received: from [127.0.0.1] by smtp102.sbc.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 14:37:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364567858; bh=t2OLuI4IW3LcwQMwRfxoyhw2YvemgFjbfbOH5wYJFH0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=kpYFL3UxX+jySIgrrsvcLik3Gps/CKIg1nf0h+KZa8kt7nqvU5Wg21MIKuzgPc3w/lrpojA/rdeiYjxDWkD0986coH2VoHTc87fmMXdQ9qQ5eSQa7N1bPvoWPnU+Gil/xjYut1Nq8ZZAumrA8/qTslUPiWnk/Rypoy/EVVp/ITI=
X-Yahoo-Newman-Id: 944378.99654.bm@smtp102.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: HeAayKYVM1kgXc0wsOwis1YsSNcc9WEzE0p65p4JxvfO.lA DLe9QZp52SW9LVUSwVs.C5NyIQHVsdDcuaIZJ5XPQk2KLlbg_Dz_EjZY1Wgd 7w4wID01zbkZ4FI6eROwm4dQIxNPel1aR9oYE6AhkUUdQf53Qj985NBYVIX4 rPrVjQEugyhtC1FF.uP3GQn6G8RWnAjqkoEwL5yPBQj6aBVavfxzUhKSVmUY NcP.vTMKWin6r02VBgOYY3GXv2uZibu__1uLlPwtoCiG34GCrUJlHGj8siLo d4bhofGAHTDA1uRam_fPpp_l2loM7WrZCWNntJIKU7gT4JjLDI8PUiYgsfjj Z_9ypXgH6EAVtn6XTISRT0GnTpPSmYYclZzWCzaX3QjJd_AUewjdoSVAKB7_ i8vks36I3s7NxqzJFk8r0KmKNtruBFZmH2ntnetLcU1HTU2Zia1CeNi_2Ifw nlJVn0uA2RqwgJCx.AiMMa4qEGXE620ZoHA7.k1yYPH7xXbDO47gENeuuG76 .WhxzgmhBSLyTrfKPPoeQvFG1QUIuS8MC95tStOOX9VO6OxAKqirMzMsDo88 PCu8zdFtKuyHRHEhoWoxcNqLC
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.199] (d.sturek@69.105.136.152 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 29 Mar 2013 14:37:38 +0000 UTC
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Fri, 29 Mar 2013 07:37:34 -0700
From: Don Sturek 
To: Routing Over Low power and Lossy networks , "Jonathan Hui (johui)" , Richard Kelsey 
Message-ID: 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Michael Richardson 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 14:37:41 -0000

Hi Kerry,

The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
occurs in route-over mesh routing.  I don't believe Homenet has such
routing solutions in their charter.  It is possible to see how a group
like Manet might use the draft but the only concrete forwarding solution
proposed is over ROLL RPL instances (certainly, provision was left in for
other multicast address usage and attendant forwarding rules but those
were out of scope for this draft).

I would propose that we move forward with the draft, within ROLL, and not
wait for input from other groups since the scope of the initial draft
(absent extensions that other groups could propose in the future) is
focused on ROLL RPL.

Don



On 3/29/13 7:20 AM, "Kerry Lynn"  wrote:

>Greetings,
>
>Apart from the fact that this draft is introduced in ROLL to address a
>problem
>inherent in multi-link subnets, I see nothing in the proposal that
>limits it to such
>networks.  It seems to me that trickle multicast could be considered in
>other
>applications, e.g. homenet, if it compares favorably with PIM-xM in
>complexity.
>
>In reading trickle multicast in this more general way, I'd like to see
>additional
>clarification regarding the use of Proactive Forwarding.  Section 4.2
>reads:
>
>   Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
>      schedules transmissions of MPL Data Messages using the Trickle
>      algorithm, without any prior indication that neighboring nodes
>      have yet to receive the message.  After transmitting the MPL Data
>      Message a limited number of times, the MPL Forwarder may terminate
>      proactive forwarding for the MPL Data Message message.
>
>I think the final sentence should read:
>
>     After transmitting the MPL Data Message a limited number of times,
>the
>     MPL Forwarder MUST terminate forwarding of the MPL Data Message.
>
>This eliminates the possible interpretation that both Proactive and
>Reactive
>Forwarding may be used by the same MPL Forwarder for the same MPL
>Data Message within the same MPL Domain.  I believe the intent is that
>Proactive and Reactive Forwarding should be mutually exclusive within
>the same MPL Domain?
>
>In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
>Parameter".  I believe this should be set (or not) on a MPL Domain basis
>(and therefore as an attribute of the Local Interface).  Again, it should
>be
>made clear that Proactive and Reactive Forwarding are mutually exclusive,
>e.g. by adding a sentence to the end of the first paragraph in section
>5.4:
>
>     If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
>     is in use.
>
>This ties it to section 5.1, which mandates MPL Control Messages on an
>interface where Reactive Forwarding is in use.
>
>I believe that section 5.5 should also be clarified with respect to the
>meaning
>of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
>read:
>
>   This specification defines a fourth Trickle configuration parameter,
>   TimerExpirations, which indicates the number of Trickle timer
>   expiration events that occur before terminating the forwarding of a
>   given MPL Data Message.
>
>This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
>number of times" statement in section 4.2.  Similarly, the definition of
>DATA_MESSAGE_TIMER_EXPIRATIONS should read:
>
>   DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
>      expirations that occur before terminating the Trickle algorithm's
>      re-transmission of a given MPL Data Message.
>      DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.
>
>This eliminates the possible interpretation that the Trickle algorithm may
>not be used for subsequent MPL Data Messages.
>
>
>Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
>to suggest that this parameter should be described as the number of
>doublings of Imin: "For example, a protocol might define Imax as 16."
>If this interpretation is correct, then DATA_MESSAGE_IMAX should be
>set to 0 in order to limit Imax to Imin.
>
>Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
>number of doublings, or at least specified in terms of worst-case link-
>layer latency if my interpretation of RFC 6202 is incorrect.
>
>The implication of specifying Imax = Imin seems to be that the dithering
>interval for MPL Data Message re-transmission will *always* be [Imin/2,
>Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
>as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
>which is presumably the point for specifying the default values as they
>are.
>
>
>Regarding the definition of MPL Domains, section 8 states:
>
>   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 (subnet-local).
>
>As Ralph Droms indicated in
>http://www.ietf.org/mail-archive/web/roll/current/msg07829.html,
>"something
>has to be done to allow MPL to use scope 0x03."  In the most expedient
>scenario, 0x03 is re-defined from "reserved" to "undefined" and the
>proposal
>then gets to define how 0x03 is used by trickle multicast.
>
>Assuming the desired use of 0x03 multicast scope is to indicate
>ALL_MPL_FORWARDERS within a given prefix, the question is how to
>indicate the prefix in question?  RFC 6282 allows for the stateful
>compression
>of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section 4.2
>allows for the assignment of "Permanent IPv6 Multicast Group Identifiers"
>for use with RFC 3306 multicast addresses.  Therefore it seems prudent to
>also request from IANA a Permanent IPv6 Multicast Group Identifier
>http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xm
>l
>to allow for the possibility of specifying the desired prefix in the MPL
>Domain
>Address.
>
>
>Lastly, to improve the clarity of section 11.2, the first bullet should
>read:
>
>   o  This document defines a "consistent" transmission as receiving an
>      MPL Control Message that results in a determination that neither the
>      receiving nor transmitting node has any new MPL Data Messages to
>offer.
>
>(The transmission indicates nothing about state at the receiver.)
>Similarly,
>the second bullet should read:
>
>   o  This document defines an "inconsistent" transmission as receiving
>      an MPL Control Message that results in a determination that either
>the
>      receiving or transmitting node has at least one new MPL Data Message
>      to offer.
>
>It might be helpful to add a penultimate sentence to section 11.2:
>
>      The Trickle timer is reset in response to external "events".
>
>Regards, -K-
>
>
>On Fri, Mar 15, 2013 at 7:34 AM, JP Vasseur (jvasseur)
> wrote:
>>
>> Dear all,
>>
>> All issues raised during the previous WG LC have been successfully
>>addressed in draft-ietf-roll-trickle-mcast-04.
>> That said, since we made several changes, this starts a 2-week WG LC
>>that will end on March 29 at noon ET.
>> Thanks.
>>
>> JP.
>>
>> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>>
>> Dear all,
>>
>> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing
>>list and during WG meeting a number of time; the document is stable and
>> has been implemented. Thus this starts a 2-week WG Last call ending on
>>Nov 9 at noon ET. Please send your comments to the authors
>> and copy the mailing list and the co-chairs.
>>
>> Thanks.
>>
>> JP.
>>
>> _______________________________________________
>> 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 iesg-secretary@ietf.org  Fri Mar 29 08:00: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 6B39C21F93B1; Fri, 29 Mar 2013 08:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, 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 vafNGwNUw4F1; Fri, 29 Mar 2013 08:00:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618D21F9430; Fri, 29 Mar 2013 08:00:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
Message-ID: <20130329150002.28773.37801.idtracker@ietfa.amsl.com>
Date: Fri, 29 Mar 2013 08:00:02 -0700
Cc: roll mailing list , roll chair , RFC Editor 
Subject: [Roll] Document Action: 'Reactive Discovery of Point-to-Point Routes in Low	Power and Lossy Networks' to Experimental RFC	(draft-ietf-roll-p2p-rpl-17.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, 29 Mar 2013 15:00:08 -0000

The IESG has approved the following document:
- 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
   Networks'
  (draft-ietf-roll-p2p-rpl-17.txt) as Experimental 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-p2p-rpl/




Technical Summary

  Targeting Low power and Lossy Networks (LLNs), the RPL routing 
  protocol [RFC6550] provides paths along a Directed Acyclic Graph 
  (DAG) rooted at a single router in the network.  Establishment and 
  maintenance of a DAG is performed by routers in the LLN using DODAG 
  Information Object (DIO) messages.  When two arbitrary routers 
  (neither of which is the DAG's root) need to communicate, the data 
  packets are restricted to travel only along the links in the DAG. 
  Such point-to-point (P2P) routing functionality may not be sufficient 
  for several Home and Building Automation applications [RFC5826] 
  [RFC5867] due to the following reasons: 

  o  The need to pre-establish routes: each potential destination in 
      the network must declare itself as such ahead of the time a source 
      needs to reach it. 

  o  The need to route only along the links in the DAG: A DAG is built 
      to optimize the routing cost to reach the root.  Restricting P2P 
      routes to use only the in-DAG links may result in significantly 
      suboptimal routes and severe traffic congestion near the DAG root. 

  This document describes an extension to core RPL that enables an IPv6 
  router in the LLN to discover routes to one or more IPv6 routers in 
  the LLN "on demand", such that the discovered routes meet the 
  specified metrics constraints, without necessarily going along the 
  links in an existing DAG.  This reactive P2P route discovery 
  mechanism is henceforth referred to as P2P-RPL.  P2P-RPL does not 
  guarantee discovery of a route.  Also, the discovered routes may not 
  be optimal.  However, any discovered routes are guaranteed to satisfy 
  the desired constraints in terms of the routing metrics and are thus 
  considered "good enough" from the application's perspective. 

  A mechanism to measure the end-to-end cost of an existing route is 
  specified in [I-D.ietf-roll-p2p-measurement].  As discussed in 
  Section 4, measuring the end-to-end cost of an existing route may 
  help decide whether to initiate the discovery of a better route using 
  P2P-RPL and the metric constraints to be used for this purpose. 

Working Group Summary: 

  No discontent. Once again, few comments, request for clarifications
  that have all been addressed in this revision. 

Document Quality: 

  Yes there are several known implementations of these specification,
  with interop testing. 

  An interoperability event was carried out Oct 2012 with INRIA's
  implementation against Sigma Design's implementation. The 
  report can be found: 
     http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf 

  Experiments with P2P-RPL have also taken place on the Senslab
  testbed gathering boards based on MSP430 and 802.15.4 at
  2.4GHz: 
    http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf 

Personnel: 

  The Document Shepherd is JP Vasseur (jvasseur@cisco.com)
  The responsible AD is Adrian Farrel (adrian@olddog.co.uk) 

RFC Editor Note

  The reference to RFC 5226 may be removed.

---

Section 6.1 New bullet on page 13.
In the list of bullets under
   The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
   the following manner:
Add a new penultimate bullet as follows:

o  As discussed in Section 14, P2P-RPL does not distinguish between
      the "preinstalled" and "authenticated" security modes described in
      [RFC6550].  Consequently, the Origin MUST set the Authentication
      Enabled (A) flag to zero.  A received P2P mode DIO MUST be
      discarded if the A flag inside the DODAG Configuration Option is
      not zero.

---

Section 6.1 New bullet on page 14
In the list of bullets under
   A P2P mode DIO:
Add a new bullet to the end of the list as follows:

o  MAY carry one DODAG Configuration Option.  If a P2P mode DIO does
      not carry an explicit DODAG Configuration Option, the default
      DODAG Configuration Option defined in this section is considered
      to be in effect.

From iesg-secretary@ietf.org  Fri Mar 29 08:00: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 DD4B421F942B for ; Fri, 29 Mar 2013 08:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ezdPOeCONQys; Fri, 29 Mar 2013 08:00:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 424A621F9435; Fri, 29 Mar 2013 08:00:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IANA 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
X-IETF-Draft-string: draft-ietf-roll-p2p-rpl
X-IETF-Draft-revision: 17
Message-ID: <20130329150002.28773.45622.idtracker@ietfa.amsl.com>
Date: Fri, 29 Mar 2013 08:00:02 -0700
Cc: roll mailing list , roll chair , RFC Editor 
Subject: [Roll] Document Action: 'Reactive Discovery of Point-to-Point Routes in Low	Power and Lossy Networks' to Experimental RFC	(draft-ietf-roll-p2p-rpl-17.txt)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: noreply@ietf.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2013 15:00:09 -0000

The IESG has approved the following document:
- 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
   Networks'
  (draft-ietf-roll-p2p-rpl-17.txt) as Experimental 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-p2p-rpl/




Technical Summary

  Targeting Low power and Lossy Networks (LLNs), the RPL routing 
  protocol [RFC6550] provides paths along a Directed Acyclic Graph 
  (DAG) rooted at a single router in the network.  Establishment and 
  maintenance of a DAG is performed by routers in the LLN using DODAG 
  Information Object (DIO) messages.  When two arbitrary routers 
  (neither of which is the DAG's root) need to communicate, the data 
  packets are restricted to travel only along the links in the DAG. 
  Such point-to-point (P2P) routing functionality may not be sufficient 
  for several Home and Building Automation applications [RFC5826] 
  [RFC5867] due to the following reasons: 

  o  The need to pre-establish routes: each potential destination in 
      the network must declare itself as such ahead of the time a source 
      needs to reach it. 

  o  The need to route only along the links in the DAG: A DAG is built 
      to optimize the routing cost to reach the root.  Restricting P2P 
      routes to use only the in-DAG links may result in significantly 
      suboptimal routes and severe traffic congestion near the DAG root. 

  This document describes an extension to core RPL that enables an IPv6 
  router in the LLN to discover routes to one or more IPv6 routers in 
  the LLN "on demand", such that the discovered routes meet the 
  specified metrics constraints, without necessarily going along the 
  links in an existing DAG.  This reactive P2P route discovery 
  mechanism is henceforth referred to as P2P-RPL.  P2P-RPL does not 
  guarantee discovery of a route.  Also, the discovered routes may not 
  be optimal.  However, any discovered routes are guaranteed to satisfy 
  the desired constraints in terms of the routing metrics and are thus 
  considered "good enough" from the application's perspective. 

  A mechanism to measure the end-to-end cost of an existing route is 
  specified in [I-D.ietf-roll-p2p-measurement].  As discussed in 
  Section 4, measuring the end-to-end cost of an existing route may 
  help decide whether to initiate the discovery of a better route using 
  P2P-RPL and the metric constraints to be used for this purpose. 

Working Group Summary: 

  No discontent. Once again, few comments, request for clarifications
  that have all been addressed in this revision. 

Document Quality: 

  Yes there are several known implementations of these specification,
  with interop testing. 

  An interoperability event was carried out Oct 2012 with INRIA's
  implementation against Sigma Design's implementation. The 
  report can be found: 
     http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf 

  Experiments with P2P-RPL have also taken place on the Senslab
  testbed gathering boards based on MSP430 and 802.15.4 at
  2.4GHz: 
    http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf 

Personnel: 

  The Document Shepherd is JP Vasseur (jvasseur@cisco.com)
  The responsible AD is Adrian Farrel (adrian@olddog.co.uk) 

RFC Editor Note

  The reference to RFC 5226 may be removed.

---

Section 6.1 New bullet on page 13.
In the list of bullets under
   The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
   the following manner:
Add a new penultimate bullet as follows:

o  As discussed in Section 14, P2P-RPL does not distinguish between
      the "preinstalled" and "authenticated" security modes described in
      [RFC6550].  Consequently, the Origin MUST set the Authentication
      Enabled (A) flag to zero.  A received P2P mode DIO MUST be
      discarded if the A flag inside the DODAG Configuration Option is
      not zero.

---

Section 6.1 New bullet on page 14
In the list of bullets under
   A P2P mode DIO:
Add a new bullet to the end of the list as follows:

o  MAY carry one DODAG Configuration Option.  If a P2P mode DIO does
      not carry an explicit DODAG Configuration Option, the default
      DODAG Configuration Option defined in this section is considered
      to be in effect.

From kerlyn2001@gmail.com  Fri Mar 29 08:08: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 D091F21F8D2D for ; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qHBxAR+tVKMt for ; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 556AA21F8673 for ; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
Received: by mail-ob0-f181.google.com with SMTP id ni5so462780obc.26 for ; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=4HnRAfyXLKmN+z7W4NIOwbOsrn4UNUyhfslSyMxan5U=; b=kZv3jrOsP9wW4fgU2YlUGpfEHFVxW1clko5r/svHPGJAvggd/dbmfoXtOJKNF28abl aHSMjpxwSCkycTyP8NwAnCz+tHj78t9KDGtOQrLXfanrVd4/1i5w/n6yV3U0xI8EJe+/ QFswPVLBmfgYQPyNap2vavzT5rT9YW2bC/PZ8VVesS37OmKbVX9ktnvGPORbNkiYsg3X 492adWZo7IQh5Mv9tKRYXX3GGB5Vgkwnh8JkdcSTsKWF8e/7G3sErEQaJrpOVIv2/9FN jCh4JojE/Bf4FwYX+7lO0SPstNEfEeITz39r1tmhh4RpYJQnYkUy9arVc2HWn3UGcHm+ QUnA==
MIME-Version: 1.0
X-Received: by 10.60.169.231 with SMTP id ah7mr918270oec.142.1364569687894; Fri, 29 Mar 2013 08:08:07 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.33.74 with HTTP; Fri, 29 Mar 2013 08:08:07 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 29 Mar 2013 11:08:07 -0400
X-Google-Sender-Auth: 9-E5yLY4gteZWzdD9M1eWxlI2aY
Message-ID: 
From: Kerry Lynn 
To: roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 15:08:08 -0000

On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek  wrote:
> Hi Kerry,
>
> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
> occurs in route-over mesh routing.  I don't believe Homenet has such
> routing solutions in their charter.  It is possible to see how a group
> like Manet might use the draft but the only concrete forwarding solution
> proposed is over ROLL RPL instances (certainly, provision was left in for
> other multicast address usage and attendant forwarding rules but those
> were out of scope for this draft).
>
I don't think this opinion reflects on the validity of my comments for even
the restricted ROLL use and I'd be interested in feedback from the authors.

In addition to the comments I made previously, I am concerned that the
default for Imax (== Imin) prevents the Trickle timer interval I from ever
doubling.  Combined with a high k, this leads to aggressive Trickle forwarding
in dense parts of the mesh that may inhibit (by interfering with) unicast
responses in transit to the original sender.  Is there a reason for not
relaxing DATA_MESSAGE_IMAX to e.g.
DATA_MESSAGE_TIMER_EXPIRATIONS?

-K-

> I would propose that we move forward with the draft, within ROLL, and not
> wait for input from other groups since the scope of the initial draft
> (absent extensions that other groups could propose in the future) is
> focused on ROLL RPL.
>
> Don
>

From culler@EECS.Berkeley.EDU  Fri Mar 29 08:29: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 4919821F86DC for ; Fri, 29 Mar 2013 08:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 WOmeLkuSMxlU for ; Fri, 29 Mar 2013 08:29:22 -0700 (PDT)
Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED321F842D for ; Fri, 29 Mar 2013 08:29:22 -0700 (PDT)
Received: from cullersmac2.att.net (108-67-64-228.lightspeed.sntcca.sbcglobal.net [108.67.64.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.6/8.13.5) with ESMTP id r2TFGpef029540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 08:29:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: David Culler 
In-Reply-To: 
Date: Fri, 29 Mar 2013 08:24:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <24A23C01-24AB-44CE-A17A-3ACE48D13758@EECS.Berkeley.EDU>
References: 
To: Routing Over Low power and Lossy networks 
X-Mailer: Apple Mail (2.1085)
Cc: Michael Richardson , "Jonathan Hui \(johui\)" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 15:29:23 -0000

Hi Don,
   It is pretty hard to see how you come to the sweeping statement, "The =
problem that  draft-ietf-roll-trickle-mcast-04 addresses really only =
occurs in route-over mesh routing [sic]."  That is the purview of the =
draft and sufficient for it to address that domain, but your statement =
is quite another thing. =20

David


On Mar 29, 2013, at 7:37 AM, Don Sturek wrote:

> Hi Kerry,
>=20
> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really =
only
> occurs in route-over mesh routing.  I don't believe Homenet has such
> routing solutions in their charter.  It is possible to see how a group
> like Manet might use the draft but the only concrete forwarding =
solution
> proposed is over ROLL RPL instances (certainly, provision was left in =
for
> other multicast address usage and attendant forwarding rules but those
> were out of scope for this draft).
>=20
> I would propose that we move forward with the draft, within ROLL, and =
not
> wait for input from other groups since the scope of the initial draft
> (absent extensions that other groups could propose in the future) is
> focused on ROLL RPL.
>=20
> Don
>=20
>=20
>=20
> On 3/29/13 7:20 AM, "Kerry Lynn"  wrote:
>=20
>> Greetings,
>>=20
>> Apart from the fact that this draft is introduced in ROLL to address =
a
>> problem
>> inherent in multi-link subnets, I see nothing in the proposal that
>> limits it to such
>> networks.  It seems to me that trickle multicast could be considered =
in
>> other
>> applications, e.g. homenet, if it compares favorably with PIM-xM in
>> complexity.
>>=20
>> In reading trickle multicast in this more general way, I'd like to =
see
>> additional
>> clarification regarding the use of Proactive Forwarding.  Section 4.2
>> reads:
>>=20
>>  Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
>>     schedules transmissions of MPL Data Messages using the Trickle
>>     algorithm, without any prior indication that neighboring nodes
>>     have yet to receive the message.  After transmitting the MPL Data
>>     Message a limited number of times, the MPL Forwarder may =
terminate
>>     proactive forwarding for the MPL Data Message message.
>>=20
>> I think the final sentence should read:
>>=20
>>    After transmitting the MPL Data Message a limited number of times,
>> the
>>    MPL Forwarder MUST terminate forwarding of the MPL Data Message.
>>=20
>> This eliminates the possible interpretation that both Proactive and
>> Reactive
>> Forwarding may be used by the same MPL Forwarder for the same MPL
>> Data Message within the same MPL Domain.  I believe the intent is =
that
>> Proactive and Reactive Forwarding should be mutually exclusive within
>> the same MPL Domain?
>>=20
>> In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
>> Parameter".  I believe this should be set (or not) on a MPL Domain =
basis
>> (and therefore as an attribute of the Local Interface).  Again, it =
should
>> be
>> made clear that Proactive and Reactive Forwarding are mutually =
exclusive,
>> e.g. by adding a sentence to the end of the first paragraph in =
section
>> 5.4:
>>=20
>>    If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
>>    is in use.
>>=20
>> This ties it to section 5.1, which mandates MPL Control Messages on =
an
>> interface where Reactive Forwarding is in use.
>>=20
>> I believe that section 5.5 should also be clarified with respect to =
the
>> meaning
>> of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
>> read:
>>=20
>>  This specification defines a fourth Trickle configuration parameter,
>>  TimerExpirations, which indicates the number of Trickle timer
>>  expiration events that occur before terminating the forwarding of a
>>  given MPL Data Message.
>>=20
>> This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
>> number of times" statement in section 4.2.  Similarly, the definition =
of
>> DATA_MESSAGE_TIMER_EXPIRATIONS should read:
>>=20
>>  DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
>>     expirations that occur before terminating the Trickle algorithm's
>>     re-transmission of a given MPL Data Message.
>>     DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.
>>=20
>> This eliminates the possible interpretation that the Trickle =
algorithm may
>> not be used for subsequent MPL Data Messages.
>>=20
>>=20
>> Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
>> to suggest that this parameter should be described as the number of
>> doublings of Imin: "For example, a protocol might define Imax as 16."
>> If this interpretation is correct, then DATA_MESSAGE_IMAX should be
>> set to 0 in order to limit Imax to Imin.
>>=20
>> Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
>> number of doublings, or at least specified in terms of worst-case =
link-
>> layer latency if my interpretation of RFC 6202 is incorrect.
>>=20
>> The implication of specifying Imax =3D Imin seems to be that the =
dithering
>> interval for MPL Data Message re-transmission will *always* be =
[Imin/2,
>> Imin) =3D=3D DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
>> as 2*DATA_MESSAGE_K).  This has the effect of setting k =3D=3D =
infinity,
>> which is presumably the point for specifying the default values as =
they
>> are.
>>=20
>>=20
>> Regarding the definition of MPL Domains, section 8 states:
>>=20
>>  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 (subnet-local).
>>=20
>> As Ralph Droms indicated in
>> http://www.ietf.org/mail-archive/web/roll/current/msg07829.html,
>> "something
>> has to be done to allow MPL to use scope 0x03."  In the most =
expedient
>> scenario, 0x03 is re-defined from "reserved" to "undefined" and the
>> proposal
>> then gets to define how 0x03 is used by trickle multicast.
>>=20
>> Assuming the desired use of 0x03 multicast scope is to indicate
>> ALL_MPL_FORWARDERS within a given prefix, the question is how to
>> indicate the prefix in question?  RFC 6282 allows for the stateful
>> compression
>> of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section =
4.2
>> allows for the assignment of "Permanent IPv6 Multicast Group =
Identifiers"
>> for use with RFC 3306 multicast addresses.  Therefore it seems =
prudent to
>> also request from IANA a Permanent IPv6 Multicast Group Identifier
>> =
http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xm=

>> l
>> to allow for the possibility of specifying the desired prefix in the =
MPL
>> Domain
>> Address.
>>=20
>>=20
>> Lastly, to improve the clarity of section 11.2, the first bullet =
should
>> read:
>>=20
>>  o  This document defines a "consistent" transmission as receiving an
>>     MPL Control Message that results in a determination that neither =
the
>>     receiving nor transmitting node has any new MPL Data Messages to
>> offer.
>>=20
>> (The transmission indicates nothing about state at the receiver.)
>> Similarly,
>> the second bullet should read:
>>=20
>>  o  This document defines an "inconsistent" transmission as receiving
>>     an MPL Control Message that results in a determination that =
either
>> the
>>     receiving or transmitting node has at least one new MPL Data =
Message
>>     to offer.
>>=20
>> It might be helpful to add a penultimate sentence to section 11.2:
>>=20
>>     The Trickle timer is reset in response to external "events".
>>=20
>> Regards, -K-
>>=20
>>=20
>> On Fri, Mar 15, 2013 at 7:34 AM, JP Vasseur (jvasseur)
>>  wrote:
>>>=20
>>> Dear all,
>>>=20
>>> All issues raised during the previous WG LC have been successfully
>>> addressed in draft-ietf-roll-trickle-mcast-04.
>>> That said, since we made several changes, this starts a 2-week WG LC
>>> that will end on March 29 at noon ET.
>>> Thanks.
>>>=20
>>> JP.
>>>=20
>>> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>>>=20
>>> Dear all,
>>>=20
>>> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing
>>> list and during WG meeting a number of time; the document is stable =
and
>>> has been implemented. Thus this starts a 2-week WG Last call ending =
on
>>> Nov 9 at noon ET. Please send your comments to the authors
>>> and copy the mailing list and the co-chairs.
>>>=20
>>> Thanks.
>>>=20
>>> JP.
>>>=20
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From d.sturek@att.net  Fri Mar 29 08:29: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 41A6B21F942B for ; Fri, 29 Mar 2013 08:29:35 -0700 (PDT)
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 erCDh8QVwXcl for ; Fri, 29 Mar 2013 08:29:34 -0700 (PDT)
Received: from nm18-vm0.access.bullet.mail.mud.yahoo.com (nm18-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.23]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE021F9429 for ; Fri, 29 Mar 2013 08:29:34 -0700 (PDT)
Received: from [66.94.237.194] by nm18.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 15:29:34 -0000
Received: from [98.138.226.243] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 15:29:34 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 15:29:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364570974; bh=PWjhivTgeFRZ0n8cXjs234ecJlAEPd0wEe6QeWYh1Gw=; 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=lpaAk0r4+XKjDfcM9chKN/R+7RNQmqvFHPMjTbEZyQg/c82mlXYdCXP/O8+FHGwGQH5q/4EOU02K9+4vTcFjj7uSzmlMP+6TtLNCfBR8sB2IE68BdRmMIIETUPQTcniD0/1T86uB3yfWm9aebMFWeKjtrix5dTPr+OWuZOrLehw=
X-Yahoo-Newman-Id: 229275.78023.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: n0ms6eMVM1no8UDyctS1vwKuO5NSfuYvPN.PeZgzz4Px6ev Uytgx5uEJxxaLPprIpXftB9k7ul3fA.bUWBFsB7AChvk3SsoqVdPFKX_R1fd MlLAvyRoMLmbHp6a_OAdxV44ojylMa0k.MDfn_8O921cjRdz_uDnymTFuKAx 5ymoGBQaeUup8bz9jEu3mtMsvsrb89iGeau_5KhTh1IGXzo.I02DORIY0r2W YmyNyFJvAknmFkjmo8MSrauEsvntOKxhZfEjHUem0NJ7MxhwcIwCUBPj4ndE BT1DLVFok0vJzVPSJmtBcQdkRS7vfzbkdHvUqkqUR025zAHDj2WIfGZgUJ4A 3EOp1w3X5Jbiz2YSVTeB7dMxSMAvBKA.WlE7tYVaNPz5sZPiywz2WTX1SB9D W8eu6AgdF.Tj.NXLEHmDVCBB3qhPKUQkk4rve7K9GNzRHvk8Z9uVIrQJgFuR F2Hy0L0z5HzYui4F9A1k-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.199] (d.sturek@69.105.136.152 with login) by smtp114.sbc.mail.ne1.yahoo.com with SMTP; 29 Mar 2013 08:29:34 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Fri, 29 Mar 2013 08:28:18 -0700
From: Don Sturek 
To: Routing Over Low power and Lossy networks 
Message-ID: 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 15:29:35 -0000

Hi Kerry,

Do you have actual test results to back up the claims below?   We (the
ZigBee IP team) tested these parameters among 7 solution providers and did
not see what you are reporting.

Interested in seeing your results.....

Don


On 3/29/13 8:08 AM, "Kerry Lynn"  wrote:

>On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek  wrote:
>> Hi Kerry,
>>
>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
>> occurs in route-over mesh routing.  I don't believe Homenet has such
>> routing solutions in their charter.  It is possible to see how a group
>> like Manet might use the draft but the only concrete forwarding solution
>> proposed is over ROLL RPL instances (certainly, provision was left in
>>for
>> other multicast address usage and attendant forwarding rules but those
>> were out of scope for this draft).
>>
>I don't think this opinion reflects on the validity of my comments for
>even
>the restricted ROLL use and I'd be interested in feedback from the
>authors.
>
>In addition to the comments I made previously, I am concerned that the
>default for Imax (== Imin) prevents the Trickle timer interval I from ever
>doubling.  Combined with a high k, this leads to aggressive Trickle
>forwarding
>in dense parts of the mesh that may inhibit (by interfering with) unicast
>responses in transit to the original sender.  Is there a reason for not
>relaxing DATA_MESSAGE_IMAX to e.g.
>DATA_MESSAGE_TIMER_EXPIRATIONS?
>
>-K-
>
>> I would propose that we move forward with the draft, within ROLL, and
>>not
>> wait for input from other groups since the scope of the initial draft
>> (absent extensions that other groups could propose in the future) is
>> focused on ROLL RPL.
>>
>> Don
>>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll



From d.sturek@att.net  Fri Mar 29 08:32: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 BC6A921F942B for ; Fri, 29 Mar 2013 08:32:39 -0700 (PDT)
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 vEuyWm4-gPmw for ; Fri, 29 Mar 2013 08:32:38 -0700 (PDT)
Received: from nm20.access.bullet.mail.mud.yahoo.com (nm20.access.bullet.mail.mud.yahoo.com [66.94.237.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11021F89D8 for ; Fri, 29 Mar 2013 08:32:38 -0700 (PDT)
Received: from [66.94.237.199] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 15:32:37 -0000
Received: from [98.138.84.173] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Mar 2013 15:32:37 -0000
Received: from [127.0.0.1] by smtp107.sbc.mail.ne1.yahoo.com with NNFMP; 29 Mar 2013 15:32:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364571157; bh=DPQEB6YTFAFgzjbuGwiwKYIiLOaOvWrleEVnwXAmGmI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=b7VNUVomDjsnkStCPCar8kcbMwvOd+HAYwZzxUhuv1xARNo59a7cDWPmuTHiTDLLBi7Gyg3chv7trlHPb2/yrrlD8hmzajcIyo9IIqDKAla35mUjCtqf9CF8TzAf6TcyQ5GdthgsrCaM9/YcfQQnC+dhxATDvbAmMio12N44ceA=
X-Yahoo-Newman-Id: 828905.64252.bm@smtp107.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: T7GALyYVM1nI1KFra..JpHtpgaZ6.7xVedevVU0p6vxgOqd h3uhKJIbDqD3wxzoZcJk_DyvIZxhHn_5k6waP19h.ZNM0G06dnzn4wJSh_Vz M7C4I.tsvhlTBUOaZ9iyUzLzmHOOmw1Zy36wdABTGMgP4FvJykFhojXEMUxj Lj25MPxUGmHAlu9J.vxUwzh9dpe9PAfsstvMqPL.P2aB1xXqt.Jdoy16V.as FkgbK6rKp_H0e_aegAhAiZqE_pXEAx_3pEVfRWZ3bMsewqjzHk5TxnqXCEcN JsVxVLg7s8R53Qy2hI1ZHObddrF7gOaI.F0Nik.jlPsxleXFZKFn9skKKij0 c9tq1PCy8FwxdzAATTNsUm9eM7B1BkPTjCzENxLX5ciB6VHx0RDCqdaXdwyV cYQ.C.g1E0cNSiJU2PUuo37l5sYqjypp5LuscKK6LQlIhq_21u1Cb8MdzHNK lFanjeuAljf1bzAV2rb2m33P7nnbrxUGyN3F1eDKX6EWQD1nqY1G1BEtqXZP fBt8qgcv7bEnrDDT78utXgZhLW_5y6M36g49yODVgfr2G5n2R6hKJuCVtnrW _9W9xjCTZ3qJ4foelzIm9mw--
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.199] (d.sturek@69.105.136.152 with login) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 29 Mar 2013 08:32:37 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Fri, 29 Mar 2013 08:31:18 -0700
From: Don Sturek 
To: Routing Over Low power and Lossy networks 
Message-ID: 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: <24A23C01-24AB-44CE-A17A-3ACE48D13758@EECS.Berkeley.EDU>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Michael Richardson , "Jonathan Hui \(johui\)" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 15:32:39 -0000

Hi David,

Yes, fair enough.   It is possible that Trickle Multicast is used in areas
outside of route over mesh, however, as you note, the purview of the draft
is really just that.

Don


On 3/29/13 8:24 AM, "David Culler"  wrote:

>Hi Don,
>   It is pretty hard to see how you come to the sweeping statement, "The
>problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
>occurs in route-over mesh routing [sic]."  That is the purview of the
>draft and sufficient for it to address that domain, but your statement is
>quite another thing.
>
>David
>
>
>On Mar 29, 2013, at 7:37 AM, Don Sturek wrote:
>
>> Hi Kerry,
>> 
>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
>> occurs in route-over mesh routing.  I don't believe Homenet has such
>> routing solutions in their charter.  It is possible to see how a group
>> like Manet might use the draft but the only concrete forwarding solution
>> proposed is over ROLL RPL instances (certainly, provision was left in
>>for
>> other multicast address usage and attendant forwarding rules but those
>> were out of scope for this draft).
>> 
>> I would propose that we move forward with the draft, within ROLL, and
>>not
>> wait for input from other groups since the scope of the initial draft
>> (absent extensions that other groups could propose in the future) is
>> focused on ROLL RPL.
>> 
>> Don
>> 
>> 
>> 
>> On 3/29/13 7:20 AM, "Kerry Lynn"  wrote:
>> 
>>> Greetings,
>>> 
>>> Apart from the fact that this draft is introduced in ROLL to address a
>>> problem
>>> inherent in multi-link subnets, I see nothing in the proposal that
>>> limits it to such
>>> networks.  It seems to me that trickle multicast could be considered in
>>> other
>>> applications, e.g. homenet, if it compares favorably with PIM-xM in
>>> complexity.
>>> 
>>> In reading trickle multicast in this more general way, I'd like to see
>>> additional
>>> clarification regarding the use of Proactive Forwarding.  Section 4.2
>>> reads:
>>> 
>>>  Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
>>>     schedules transmissions of MPL Data Messages using the Trickle
>>>     algorithm, without any prior indication that neighboring nodes
>>>     have yet to receive the message.  After transmitting the MPL Data
>>>     Message a limited number of times, the MPL Forwarder may terminate
>>>     proactive forwarding for the MPL Data Message message.
>>> 
>>> I think the final sentence should read:
>>> 
>>>    After transmitting the MPL Data Message a limited number of times,
>>> the
>>>    MPL Forwarder MUST terminate forwarding of the MPL Data Message.
>>> 
>>> This eliminates the possible interpretation that both Proactive and
>>> Reactive
>>> Forwarding may be used by the same MPL Forwarder for the same MPL
>>> Data Message within the same MPL Domain.  I believe the intent is that
>>> Proactive and Reactive Forwarding should be mutually exclusive within
>>> the same MPL Domain?
>>> 
>>> In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
>>> Parameter".  I believe this should be set (or not) on a MPL Domain
>>>basis
>>> (and therefore as an attribute of the Local Interface).  Again, it
>>>should
>>> be
>>> made clear that Proactive and Reactive Forwarding are mutually
>>>exclusive,
>>> e.g. by adding a sentence to the end of the first paragraph in section
>>> 5.4:
>>> 
>>>    If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
>>>    is in use.
>>> 
>>> This ties it to section 5.1, which mandates MPL Control Messages on an
>>> interface where Reactive Forwarding is in use.
>>> 
>>> I believe that section 5.5 should also be clarified with respect to the
>>> meaning
>>> of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
>>> read:
>>> 
>>>  This specification defines a fourth Trickle configuration parameter,
>>>  TimerExpirations, which indicates the number of Trickle timer
>>>  expiration events that occur before terminating the forwarding of a
>>>  given MPL Data Message.
>>> 
>>> This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
>>> number of times" statement in section 4.2.  Similarly, the definition
>>>of
>>> DATA_MESSAGE_TIMER_EXPIRATIONS should read:
>>> 
>>>  DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
>>>     expirations that occur before terminating the Trickle algorithm's
>>>     re-transmission of a given MPL Data Message.
>>>     DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.
>>> 
>>> This eliminates the possible interpretation that the Trickle algorithm
>>>may
>>> not be used for subsequent MPL Data Messages.
>>> 
>>> 
>>> Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
>>> to suggest that this parameter should be described as the number of
>>> doublings of Imin: "For example, a protocol might define Imax as 16."
>>> If this interpretation is correct, then DATA_MESSAGE_IMAX should be
>>> set to 0 in order to limit Imax to Imin.
>>> 
>>> Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
>>> number of doublings, or at least specified in terms of worst-case link-
>>> layer latency if my interpretation of RFC 6202 is incorrect.
>>> 
>>> The implication of specifying Imax = Imin seems to be that the
>>>dithering
>>> interval for MPL Data Message re-transmission will *always* be [Imin/2,
>>> Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
>>> as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
>>> which is presumably the point for specifying the default values as they
>>> are.
>>> 
>>> 
>>> Regarding the definition of MPL Domains, section 8 states:
>>> 
>>>  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 (subnet-local).
>>> 
>>> As Ralph Droms indicated in
>>> http://www.ietf.org/mail-archive/web/roll/current/msg07829.html,
>>> "something
>>> has to be done to allow MPL to use scope 0x03."  In the most expedient
>>> scenario, 0x03 is re-defined from "reserved" to "undefined" and the
>>> proposal
>>> then gets to define how 0x03 is used by trickle multicast.
>>> 
>>> Assuming the desired use of 0x03 multicast scope is to indicate
>>> ALL_MPL_FORWARDERS within a given prefix, the question is how to
>>> indicate the prefix in question?  RFC 6282 allows for the stateful
>>> compression
>>> of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section 4.2
>>> allows for the assignment of "Permanent IPv6 Multicast Group
>>>Identifiers"
>>> for use with RFC 3306 multicast addresses.  Therefore it seems prudent
>>>to
>>> also request from IANA a Permanent IPv6 Multicast Group Identifier
>>> 
>>>http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.
>>>xm
>>> l
>>> to allow for the possibility of specifying the desired prefix in the
>>>MPL
>>> Domain
>>> Address.
>>> 
>>> 
>>> Lastly, to improve the clarity of section 11.2, the first bullet should
>>> read:
>>> 
>>>  o  This document defines a "consistent" transmission as receiving an
>>>     MPL Control Message that results in a determination that neither
>>>the
>>>     receiving nor transmitting node has any new MPL Data Messages to
>>> offer.
>>> 
>>> (The transmission indicates nothing about state at the receiver.)
>>> Similarly,
>>> the second bullet should read:
>>> 
>>>  o  This document defines an "inconsistent" transmission as receiving
>>>     an MPL Control Message that results in a determination that either
>>> the
>>>     receiving or transmitting node has at least one new MPL Data
>>>Message
>>>     to offer.
>>> 
>>> It might be helpful to add a penultimate sentence to section 11.2:
>>> 
>>>     The Trickle timer is reset in response to external "events".
>>> 
>>> Regards, -K-
>>> 
>>> 
>>> On Fri, Mar 15, 2013 at 7:34 AM, JP Vasseur (jvasseur)
>>>  wrote:
>>>> 
>>>> Dear all,
>>>> 
>>>> All issues raised during the previous WG LC have been successfully
>>>> addressed in draft-ietf-roll-trickle-mcast-04.
>>>> That said, since we made several changes, this starts a 2-week WG LC
>>>> that will end on March 29 at noon ET.
>>>> Thanks.
>>>> 
>>>> JP.
>>>> 
>>>> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>>>> 
>>>> Dear all,
>>>> 
>>>> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing
>>>> list and during WG meeting a number of time; the document is stable
>>>>and
>>>> has been implemented. Thus this starts a 2-week WG Last call ending on
>>>> Nov 9 at noon ET. Please send your comments to the authors
>>>> and copy the mailing list and the co-chairs.
>>>> 
>>>> Thanks.
>>>> 
>>>> JP.
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> 
>> _______________________________________________
>> 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 jvasseur@cisco.com  Fri Mar 29 12:09: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 548A221F8C45 for ; Fri, 29 Mar 2013 12:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.156
X-Spam-Level: 
X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.442, 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 nKtO6rt4RIC0 for ; Fri, 29 Mar 2013 12:09:20 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7621021F8C3C for ; Fri, 29 Mar 2013 12:09:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1364584160; x=1365793760; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ADY2rbVOX/nuheWZvYD+B19PO5nn5dQnuYbICwIIRVE=; b=CNQqd6vGPjBikzCBR+k4Yyt1clzxqM9QJFoXUfe9hswTNJu+8fv+M95k NvhSgAgNTcgkZVG+w7igsZnn+iomaLrg+Gubq0BNdBTvk1T0syi+owl4M IlkLfURMTIDxT5BKBO2VjWsRycZafN+Ia5s9pT3tVseaLG3btSlmpF0pJ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFANrlVVGtJXG8/2dsb2JhbABDgkN3vymBChZ0giABAQQBAQFrCxACAQgEHh0HJwsUEQIEDgUIiAwMv30EjVqBHC0EB4JfYQOndoMLgig
X-IronPort-AV: E=Sophos;i="4.87,374,1363132800";  d="scan'208,217";a="192791626"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 29 Mar 2013 19:09:08 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2TJ985t008781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Mar 2013 19:09:08 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 14:09:08 -0500
From: "JP Vasseur (jvasseur)" 
To: Routing Over Low power and Lossy networks 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
Thread-Index: AQHOIXEdgTiLqfJiVkmPoRqI8b/ZWpi9crMA
Date: Fri, 29 Mar 2013 19:09:07 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77233A84FB@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.91.97]
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77233A84FBxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: Michael Richardson 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 19:09:21 -0000

--_000_03B78081B371D44390ED6E7BADBB4A77233A84FBxmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This terminates the WG LC; authors please make sure the address the few con=
cerns that were raised during WG LC,
I am specifically referring to the editorial comments raised by Kerry.

Thanks.

JP.

On Mar 15, 2013, at 12:34 PM, JP Vasseur (jvasseur) wrote:

Dear all,

All issues raised during the previous WG LC have been successfully addresse=
d in draft-ietf-roll-trickle-mcast-04.
That said, since we made several changes, this starts a 2-week WG LC that w=
ill end on March 29 at noon ET.
Thanks.

JP.

On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:

Dear all,

draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list an=
d during WG meeting a number of time; the document is stable and
has been implemented. Thus this starts a 2-week WG Last call ending on Nov =
9 at noon ET. Please send your comments to the authors
and copy the mailing list and the co-chairs.

Thanks.

JP.

_______________________________________________
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


--_000_03B78081B371D44390ED6E7BADBB4A77233A84FBxmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <1C46DF3D3684FB48911ECDE1630635D5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






This terminates the WG LC; authors please make sure the address the few con=
cerns that were raised during WG LC,

I am specifically referring to the editorial comments raised by Kerry.=






Thanks.







JP.







On Mar 15, 2013, at 12:34 PM, JP Vasseur (jvasseur) wrote:







Dear all,






All issues raised during the previous WG LC have been successfully add=
ressed in draft-ietf-ro=
ll-trickle-mcast-04.



That said, since we made several changes, this starts a 2-week WG LC t=
hat will end on March 29 at noon ET.


Thanks.







JP.







On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:






Dear all,



draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing li=
st and during WG meeting a number of time; the document is stable and


has been implemented. Thus this starts a 2-week WG Last call ending on Nov =
9 at noon ET. Please send your comments to the authors


and copy the mailing list and the co-chairs.



Thanks.



JP.



_______________________________________________

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














--_000_03B78081B371D44390ED6E7BADBB4A77233A84FBxmbrcdx02ciscoc_--

From cabo@tzi.org  Fri Mar 29 14:25: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 B254521E8089; Fri, 29 Mar 2013 14:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.164
X-Spam-Level: 
X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 3tE71V32Jifc; Fri, 29 Mar 2013 14:25:15 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B17B021E8091; Fri, 29 Mar 2013 14:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TLP8Mg018341; Fri, 29 Mar 2013 22:25:08 +0100 (CET)
Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B18FF371E; Fri, 29 Mar 2013 22:25:07 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <1364591463.93179.YahooMailNeo@web142505.mail.bf1.yahoo.com>
Date: Fri, 29 Mar 2013 22:25:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E50F482-9281-4787-A825-AAFF639E513B@tzi.org>
References: <18113.1339529290@marajade.sandelman.ca>   <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl>  <1364591463.93179.YahooMailNeo@web142505.mail.bf1.yahoo.com>
To: Mark Smith 
X-Mailer: Apple Mail (2.1503)
Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org>, "ipv6@ietf.org List" , "core \(core@ietf.org\)" 
Subject: Re: [Roll] GHC now crunches DTLS (Re: [6lowpan] draft-bormann-ghc)
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, 29 Mar 2013 21:25:16 -0000

On Mar 29, 2013, at 22:11, Mark Smith  wrote:

> RFC5175, "IPv6 Router Advertisement Flags Option"

EFO was inspiration for 6CIO, but is different from 6CIO in that it is =
about flags promulgated by a router (and therefore can only be used in =
an RA).
6CIO is about the capabilities of the node sending that option.
That's why they are not the same thing.

6CIO is indeed meant to be general enough to carry other node =
capabilities that are relevant to a node-node situation.  ROHC-over-802 =
could have used it.  That's why I'm proposing creating an IANA registry. =
to make the other 47 bits available for other uses.

I'm completely neutral to whether GHC's compression scheme and 6CIO =
should be done in a combined draft or separate drafts.  In the latter =
case, stealing more text from 5175 is an obvious thing to do.

Is there anything that could/should be generalized about 6CIO?
(Without making it more complex, please.)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Fri Mar 29 22:32: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 91F0A21F8EF1; Fri, 29 Mar 2013 22:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.173
X-Spam-Level: 
X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 omVRNof6Mt+Z; Fri, 29 Mar 2013 22:32:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFBE21F8D84; Fri, 29 Mar 2013 22:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2U5WgjT012855; Sat, 30 Mar 2013 06:32:42 +0100 (CET)
Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3482378B; Sat, 30 Mar 2013 06:32:41 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Carsten Bormann 
Date: Sat, 30 Mar 2013 06:32:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org>
To: IETF Apps Discuss , draft-ietf-roll-terminology.all@tools.ietf.org
X-Mailer: Apple Mail (2.1503)
Cc: "roll@ietf.org WG" , The IESG 
Subject: [Roll] AppsDir review of draft-ietf-roll-terminology-12.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, 30 Mar 2013 05:32:50 -0000

I have been selected as the Applications Area Directorate (appsdir)
reviewer for this draft.  (For background on appsdir, please see
=
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)=
.

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document
shepherd or AD before posting a new version of the draft.


Document: draft-ietf-roll-terminology-12.txt
Title: Terminology in Low power And Lossy Networks
Reviewer: Carsten Bormann
Review Date: March 30, 2013
IETF Last Call Date: March 16, 2013
IESG Telechat Date: not known


Summary: This document is NOT ready for publication.

After reading this draft, only one conclusion is possible:
Neither the author not the working group care about this document.

The document mixes up a glossary function (is it really intended to
define new ROLL terminology for "Flash Memory"?  "RAM"?  "ROM"?
"HVAC"?  "ISA"?  "HART"?) with much-needed actual definition of
specific terminology for the domain of the working group.

Where the latter is intended, there is often failure:

           MP2P: Multipoint-to-Point is used to describe a particular =
traffic
           pattern (e.g.  MP2P flows collecting information from many =
nodes
           flowing upstream towards a collecting sink or an LBR).

All we learn is that it is "used to describe" a traffic pattern and an
example for one.  Now what is the definition of the term?  Is it the
upstreamness that is characteristic of MP2P or is it the many-to-one
relation?  But maybe it isn't really to *one*?  This is the kind of
question that this document must answer, and it almost completely
fails.

For the glossary function, shouldn't be some coverage of the ROLL
documents?  E.g., RFC 5548 revolves around the term U-LLN.  Why isn't
that presumably useful term copied into the glossary part of this
document?  What about the other terms defined in RFCs 5548, 5673,
5826, 5867, 6206, 6550, 6551, 6552, 6719?

There is a quite useful start in this document, but it requires a
major cleanup and a lot more detail work before it becomes
publishable.

As a first step, the document needs structure, with a separation
between the glossary function and the defining intent.  For the
latter, some minimum amount of rigorous thinking needs to be applied.
Where terms are by definition wishy-washy, that is also fine, but
should be explicit.

I'd be happy to review a reworked document in more detail.

Gr=FC=DFe, Carsten


From adrian@olddog.co.uk  Sat Mar 30 03: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 1396521F852A; Sat, 30 Mar 2013 03:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047,  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 nrft3OMJc8AK; Sat, 30 Mar 2013 03:15:19 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 17EB621F8506; Sat, 30 Mar 2013 03:15:18 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2UAFHMe017367;  Sat, 30 Mar 2013 10:15:17 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 r2UAFEmR017353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 10:15:15 GMT
From: "Adrian Farrel" 
To: "'Carsten Bormann'" , "'IETF Apps Discuss'" , 
References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org>
In-Reply-To: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org>
Date: Sat, 30 Mar 2013 10:15:16 -0000
Message-ID: <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIVSs5ndaiT3p7zpAliA/Q3NJikw5gvwyCA
Content-Language: en-gb
Cc: roll@ietf.org, 'The IESG' 
Subject: Re: [Roll] AppsDir review of draft-ietf-roll-terminology-12.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 30 Mar 2013 10:15:20 -0000

Hi all,

I think I see three things in Carsten's review.

1. Separation of glossary from new terms

I can see why this might be valuable, but I am not sure it is critical =
rather
than stylistic. That is, there are two types of term used in the ROLL =
work:
- terms that have a meaning specific to ROLL (terminology)
- terms that have a meaning in ROLL that is identical to their common =
meaning
(glossary)
In both cases, the words have a meaning in ROLL that needs to be =
documented.

2. Use of "more definitive" language for the explanation of new terms

I believe this may be a linguistic issue (or even cultural :-).
I, of course, reviewed the document and had no issue with "X is used to
describe..." To me, that is equivalent to "In the context of ROLL, X =
is...", or
the more simple "X is..." It is, perhaps, more chatty language than some =
would
use, but I think the meaning is clear: when you see "X" in a ROLL =
document you
know it means the totality of the paragraph.

Now, in the case that Carsten quotes for MP2P, I don't think the issue =
should be
with "used to describe" but with a transposition of "e.g." for "i.e.". =
Thus,
this is a specific problem with one paragraph, rather than with the =
general
text. And the author can sort this out.

3. Further trawling of related documents for terms that should be =
included

Thanks to Carsten for suggesting U-LLN as a term for inclusion. AFAICS, =
RFC 5548
is the only document using this term, and presents it as a documentation
abbreviation within the RFC rather than a generic term. So I don't think =
it
needs to be included.

As for "What about the other terms defined in RFCs 5548, 5673, 5826, =
5867, 6206,
6550, 6551, 6552, 6719?" I think we can assume that the author checked =
those
documents and made a decision about which terms should be included and =
which
excluded. Also that the WG is well aware of the existence of those =
documents. So
rather than an open-ended "Please do more work" it would be helpful to =
identify
which terms are believed to be missing and in need of inclusion.

Thanks,
Adrian

> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf =
Of
> Carsten Bormann
> Sent: 30 March 2013 05:33
> To: IETF Apps Discuss; draft-ietf-roll-terminology.all@tools.ietf.org
> Cc: roll@ietf.org WG; The IESG
> Subject: AppsDir review of draft-ietf-roll-terminology-12.txt
>=20
> I have been selected as the Applications Area Directorate (appsdir)
> reviewer for this draft.  (For background on appsdir, please see
> =
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate=
).
>=20
> Please resolve these comments along with any other Last Call comments
> you may receive.  Please wait for direction from your document
> shepherd or AD before posting a new version of the draft.
>=20
>=20
> Document: draft-ietf-roll-terminology-12.txt
> Title: Terminology in Low power And Lossy Networks
> Reviewer: Carsten Bormann
> Review Date: March 30, 2013
> IETF Last Call Date: March 16, 2013
> IESG Telechat Date: not known
>=20
>=20
> Summary: This document is NOT ready for publication.
>=20
> After reading this draft, only one conclusion is possible:
> Neither the author not the working group care about this document.
>=20
> The document mixes up a glossary function (is it really intended to
> define new ROLL terminology for "Flash Memory"?  "RAM"?  "ROM"?
> "HVAC"?  "ISA"?  "HART"?) with much-needed actual definition of
> specific terminology for the domain of the working group.
>=20
> Where the latter is intended, there is often failure:
>=20
>            MP2P: Multipoint-to-Point is used to describe a particular =
traffic
>            pattern (e.g.  MP2P flows collecting information from many =
nodes
>            flowing upstream towards a collecting sink or an LBR).
>=20
> All we learn is that it is "used to describe" a traffic pattern and an
> example for one.  Now what is the definition of the term?  Is it the
> upstreamness that is characteristic of MP2P or is it the many-to-one
> relation?  But maybe it isn't really to *one*?  This is the kind of
> question that this document must answer, and it almost completely
> fails.
>=20
> For the glossary function, shouldn't be some coverage of the ROLL
> documents?  E.g., RFC 5548 revolves around the term U-LLN.  Why isn't
> that presumably useful term copied into the glossary part of this
> document?  What about the other terms defined in RFCs 5548, 5673,
> 5826, 5867, 6206, 6550, 6551, 6552, 6719?
>=20
> There is a quite useful start in this document, but it requires a
> major cleanup and a lot more detail work before it becomes
> publishable.
>=20
> As a first step, the document needs structure, with a separation
> between the glossary function and the defining intent.  For the
> latter, some minimum amount of rigorous thinking needs to be applied.
> Where terms are by definition wishy-washy, that is also fine, but
> should be explicit.
>=20
> I'd be happy to review a reworked document in more detail.
>=20
> Gr=FC=DFe, Carsten


From stokcons@xs4all.nl  Sat Mar 30 05:24: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 54BE721F8814 for ; Sat, 30 Mar 2013 05:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.796
X-Spam-Level: 
X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 0xFmBcMf4LSw for ; Sat, 30 Mar 2013 05:24:19 -0700 (PDT)
Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62A21F8801 for ; Sat, 30 Mar 2013 05:24:19 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2UCOISb029757 for ; Sat, 30 Mar 2013 13:24:18 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 30 Mar 2013 13:24:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 30 Mar 2013 13:24:17 +0100
From: peter van der Stok 
To: 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: 
References: 
Message-ID: 
X-Sender: stokcons@xs4all.nl (e/nSuDJBDQVB5VrDsKDb0NazPZ8oAo26)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2013 12:24:20 -0000

Hi Don, Kerry,


As I tried to express earlier, I am not too happy with the suggested 
default values for the mpl parameters.
Their recommended values very much depend on the timing characteristics 
of the application and the topology of the network.
I think it is more appropriate to have these values cited in the 
applicability statements (if they are focused enough).

Coming back to simulation c.q. operation results:
I can well imagine that with a network that is loaded for a few percent 
of the time with mpl messages the value of k is not that important.
I can also imagine that at the edge of networks with a strongly varying 
density of repeaters, it is possible that some nodes at the edge only 
receive messages with a given regularity when k is infinity.
In the applications that I consider the density of repeaters is quite 
homogeneous, the end to end delays are expressed in hundreds of 
milliseconds and multiple seeds generate messages on a (tens of) seconds 
scale. In that case k=1 is often excellent and a higher k is not 
recommended.

hope this helps,

peter

Don Sturek schreef op 2013-03-29 16:28:
> Hi Kerry,
> 
> Do you have actual test results to back up the claims below?   We (the
> ZigBee IP team) tested these parameters among 7 solution providers and 
> did
> not see what you are reporting.
> 
> Interested in seeing your results.....
> 
> Don
> 
> 
> On 3/29/13 8:08 AM, "Kerry Lynn"  wrote:
> 
>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek  
>> wrote:
>>> Hi Kerry,
>>> 
>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really 
>>> only
>>> occurs in route-over mesh routing.  I don't believe Homenet has such
>>> routing solutions in their charter.  It is possible to see how a 
>>> group
>>> like Manet might use the draft but the only concrete forwarding 
>>> solution
>>> proposed is over ROLL RPL instances (certainly, provision was left 
>>> in
>>> for
>>> other multicast address usage and attendant forwarding rules but 
>>> those
>>> were out of scope for this draft).
>>> 
>> I don't think this opinion reflects on the validity of my comments 
>> for
>> even
>> the restricted ROLL use and I'd be interested in feedback from the
>> authors.
>> 
>> In addition to the comments I made previously, I am concerned that 
>> the
>> default for Imax (== Imin) prevents the Trickle timer interval I from 
>> ever
>> doubling.  Combined with a high k, this leads to aggressive Trickle
>> forwarding
>> in dense parts of the mesh that may inhibit (by interfering with) 
>> unicast
>> responses in transit to the original sender.  Is there a reason for 
>> not
>> relaxing DATA_MESSAGE_IMAX to e.g.
>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>> 
>> -K-
>> 
>>> I would propose that we move forward with the draft, within ROLL, 
>>> and
>>> not
>>> wait for input from other groups since the scope of the initial 
>>> draft
>>> (absent extensions that other groups could propose in the future) is
>>> focused on ROLL RPL.
>>> 
>>> Don
>>> 
>> _______________________________________________
>> 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  Sat Mar 30 06:13: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 6EB4F21F86D8 for ; Sat, 30 Mar 2013 06:13:50 -0700 (PDT)
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 fESrJykcV-mP for ; Sat, 30 Mar 2013 06:13:49 -0700 (PDT)
Received: from nm17.access.bullet.mail.sp2.yahoo.com (nm17.access.bullet.mail.sp2.yahoo.com [98.139.44.144]) by ietfa.amsl.com (Postfix) with ESMTP id 938E821F86D6 for ; Sat, 30 Mar 2013 06:13:49 -0700 (PDT)
Received: from [98.139.44.106] by nm17.access.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
Received: from [98.138.226.241] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364649229; bh=A/UMt5/8qS5XJpu8R/G/dlfKCjrND06uHWgEZoRL7k0=; 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=RR1TCji7KlWb8dtkmM5rd6R+IwqFf5IVeYiaPGq8TZ6YFd6AbGkFit8F1IXazQI/+SzvFI+xebAZ+lxzgiUdZlb5Xw4f1HXhvZIp5EFtqVybQtcw7EJb39TjJB6jdCBupo9yXu8e2lzlq4u1fPSkcAU7zAi9rIiKqx+GRCc/Mdc=
X-Yahoo-Newman-Id: 91014.34415.bm@smtp112.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: s_cdrT0VM1nq7z83pWdQMxlNfCFXlbIn2EUxCfy_5BkvYhz tSqIcIYcQ3HNyzY2NnhghqMRWak_oKn_uUeehLm_7vt2se.zkpEG7yOXYV6f uRLVVbl24q4mo.r4vFBMZmryVG1b7Qct3jjKMAKX89F1LLeJ7ahBraiu.T4w _hEwMosRXzD1DNlRy9rdGiOs2TYaLpQDgOCiQm88HOC4QUJlKwszpO8u81fr 3F5A3k9lKo.FBm9f364kCZ9FQD2bjp8.GdCwzbDk3HbA6H3LCK42u.x5Naa4 1Slg1Dcn9GWxWkKSWmtvcZ0roRGMb8n8BVithQUFSMbhPiEJet9keQLdZR.r fkD_iItWF3R2OMMcDBqDvtR7CkI1cQqukP06KAq._XEvlc3Csg5v6rqQC0Y7 b1QRB5IAhU0MJ0ETdw5bdTmwEV5.CfYnIzDZ0bfB.01SfQG3SPjWKBluERoT qQvpwlxx0Lcm2DtyUKGY-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.199] (d.sturek@69.105.137.143 with login) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 30 Mar 2013 06:13:49 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Sat, 30 Mar 2013 06:11:17 -0700
From: Don Sturek 
To: , Routing Over Low power and Lossy networks 
Message-ID: 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 30 Mar 2013 13:13:50 -0000

Hi Peter,

What you wrote below sounds quite correct.   Given our testing, your
statement that that recommend default paramters depend on the timing
characteristics of the application and topology of the network aligns very
well with the test results we gathered.

Our test used our assumed topology (30 node network with 3 hops).   We
created the network using IEEE 802.15.4 devices connected via wires on SMA
connectors (with attenuators to reflect distance between the devices).
Our test set up was to create a multicast message targeting from 1 to 8
devices in the network where each of the targeted devices was to create a
multicast message in response (we were testing how mDNS would work using
Trickle Multicast in our network).   Our success criteria was to see that
every node in the network (100% coverage on the requst) saw the original
multicast request and that the requestor would see all of the responses
(100% coverage on the responses received).   We ran quite a few tests with
varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted the
window to be small thinking that would best service the requests/responses
but could only get to around 60% of requests seen and responses received.
Finally, we had to set Imax out to 512ms to achieve our goal.   One clear
observation is that these settings were definitely tied to the number of
devices in the network and topology.

I know for lighting applications that multicasts must be received within
250ms.   That was not our use case so we did not impose this restriction.
It would have been interesting to see if we could have achieved both
goals:   all devices seeing the request AND the multicast request
delivered within 250ms.

Don


On 3/30/13 5:24 AM, "peter van der Stok"  wrote:

>Hi Don, Kerry,
>
>
>As I tried to express earlier, I am not too happy with the suggested
>default values for the mpl parameters.
>Their recommended values very much depend on the timing characteristics
>of the application and the topology of the network.
>I think it is more appropriate to have these values cited in the
>applicability statements (if they are focused enough).
>
>Coming back to simulation c.q. operation results:
>I can well imagine that with a network that is loaded for a few percent
>of the time with mpl messages the value of k is not that important.
>I can also imagine that at the edge of networks with a strongly varying
>density of repeaters, it is possible that some nodes at the edge only
>receive messages with a given regularity when k is infinity.
>In the applications that I consider the density of repeaters is quite
>homogeneous, the end to end delays are expressed in hundreds of
>milliseconds and multiple seeds generate messages on a (tens of) seconds
>scale. In that case k=1 is often excellent and a higher k is not
>recommended.
>
>hope this helps,
>
>peter
>
>Don Sturek schreef op 2013-03-29 16:28:
>> Hi Kerry,
>> 
>> Do you have actual test results to back up the claims below?   We (the
>> ZigBee IP team) tested these parameters among 7 solution providers and
>> did
>> not see what you are reporting.
>> 
>> Interested in seeing your results.....
>> 
>> Don
>> 
>> 
>> On 3/29/13 8:08 AM, "Kerry Lynn"  wrote:
>> 
>>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek 
>>> wrote:
>>>> Hi Kerry,
>>>> 
>>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really
>>>> only
>>>> occurs in route-over mesh routing.  I don't believe Homenet has such
>>>> routing solutions in their charter.  It is possible to see how a
>>>> group
>>>> like Manet might use the draft but the only concrete forwarding
>>>> solution
>>>> proposed is over ROLL RPL instances (certainly, provision was left
>>>> in
>>>> for
>>>> other multicast address usage and attendant forwarding rules but
>>>> those
>>>> were out of scope for this draft).
>>>> 
>>> I don't think this opinion reflects on the validity of my comments
>>> for
>>> even
>>> the restricted ROLL use and I'd be interested in feedback from the
>>> authors.
>>> 
>>> In addition to the comments I made previously, I am concerned that
>>> the
>>> default for Imax (== Imin) prevents the Trickle timer interval I from
>>> ever
>>> doubling.  Combined with a high k, this leads to aggressive Trickle
>>> forwarding
>>> in dense parts of the mesh that may inhibit (by interfering with)
>>> unicast
>>> responses in transit to the original sender.  Is there a reason for
>>> not
>>> relaxing DATA_MESSAGE_IMAX to e.g.
>>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>>> 
>>> -K-
>>> 
>>>> I would propose that we move forward with the draft, within ROLL,
>>>> and
>>>> not
>>>> wait for input from other groups since the scope of the initial
>>>> draft
>>>> (absent extensions that other groups could propose in the future) is
>>>> focused on ROLL RPL.
>>>> 
>>>> Don
>>>> 
>>> _______________________________________________
>>> 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 cabo@tzi.org  Sat Mar 30 06:33:33 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 1AA8921F87F5; Sat, 30 Mar 2013 06:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.176
X-Spam-Level: 
X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 5NLmOctl9GAP; Sat, 30 Mar 2013 06:33:32 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1C21F855A; Sat, 30 Mar 2013 06:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2UDXQSI028334; Sat, 30 Mar 2013 14:33:26 +0100 (CET)
Received: from [192.168.217.135] (p548925A4.dip.t-dialin.net [84.137.37.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74EFC3812; Sat, 30 Mar 2013 14:33:26 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk>
Date: Sat, 30 Mar 2013 14:33:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk>
To: 
X-Mailer: Apple Mail (2.1503)
Cc: roll@ietf.org, draft-ietf-roll-terminology.all@tools.ietf.org, 'IETF Apps Discuss' , 'The IESG' 
Subject: Re: [Roll] AppsDir review of draft-ietf-roll-terminology-12.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, 30 Mar 2013 13:33:33 -0000

Hi Adrian,

thanks for trying to read my somewhat terse statements, and I apologize =
for making them as easy to misunderstand as I did.

I didn't pay attention to the discussion that led up to this document.
I was trying to read it from scratch as a document that somebody from a =
different area would use to gain access to the terminology used in the =
ROLL work.

With my critique, I was less interested in the stylistic issues but in =
the definitional intent.

I think we can all agree that terms like "flash memory" or "field =
device" are useful in the vocabulary of someone trying understand ROLL =
documents.
There is no need to "define" these terms, as they already work in their =
industry-standard usage.
So that would be the glossary aspect of the document: gathering =
information about these terms that is focused on the ROLL context.  =
E.g., highlighting the potential constrainedness of field devices makes =
this glossary entry more immediately useful than a Wikipedia entry =
(which strangely doesn't exist) would be.

Re the coverage:  I used U-LLN as an example of a potentially missing =
term because draft-tripathi-roll-reactive-applicability-00.txt uses it =
as if the reader were expected to know it.
Fortunately, its first use there is close to a reference to 5548, so the =
definition was easy to find.
But. more generally speaking, if the intent is to list terms that are =
*not* defined in the RFCs, that would also be a useful way of scoping.

I was expecting more definitional intent on the terms that have been =
invented or appropriated for and by ROLL. =20
But maybe that is a misunderstanding on my part of what this document is =
about (the WG charter did not help me in identifying its objective, and =
the introduction reads like there is defining intent).


So, in summary, if the WG intends this to be a loose collection of a =
number of background terms with a glossary-like intent, there is indeed =
only a bit more editorial work remaining, starting with clarifying that =
objective.  Maybe the alphabetic arrangement should have alerted me that =
this might really be the objective.

But then, coming from an applications area point of view, I'm still =
looking forward to a future ROLL terminology document.  Is "MP2P" a =
traffic pattern while "P2MP" isn't?  What is the relationship between =
RFC 4461 "P2MP LSP"s and what is called "P2MP" in RFC 6550?  What is the =
relationship between RFC 1112's "multicast" and what is called =
"multicast" in draft-ietf-roll-trickle-mcast-04.txt, which just =
completed WGLC?  What is the relationship between RFC 1122's "host"s and =
RFC 6550's "host"s?  What *is* an LLN?

Gr=FC=DFe, Carsten


From sm@resistor.net  Sat Mar 30 19:21: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 A67EC21F8928 for ; Sat, 30 Mar 2013 19:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level: 
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 pOtv9au6GTia for ; Sat, 30 Mar 2013 19:21:26 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E628321F86C9 for ; Sat, 30 Mar 2013 19:21:25 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2V2LKv1019092 for ; Sat, 30 Mar 2013 19:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364696484; bh=z4MXlSsz+5bdy9ZEKNZx/osx0XApQcnY7f7tXqFeJvo=; h=Date:To:From:Subject:In-Reply-To:References; b=3VaZU7NKdHlk6/wRGD0WLiMpcIx2wF47vUfprc+zeLGhTlB9ZOAajDBPifV8D1H5B fKgGBdI+9Z6tChnYi9yDQLTkdG3I/fEFF8BscH0i9ZGhDYN0FGWLRoTU6f0oUFBs6N Mxg2V3wScBG2TBwqx5jTJ7SlBh1/7oH8Yp3UPLuk=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364696484; i=@resistor.net; bh=z4MXlSsz+5bdy9ZEKNZx/osx0XApQcnY7f7tXqFeJvo=; h=Date:To:From:Subject:In-Reply-To:References; b=q3xR0MmlCmtoUzHekK3NoHWiuCEqf6yISekMjKqvSMQ6JKSNuZdGUT0VQEMU0O0fL vW3l59Ru09N8XHwQ+il74fXi2xiSzBhbLQw3UzMjK6s7eSNim/DA3W/1k0mYrOquDt A/Aw3C9hA4qG9chwhPALoLTMaXeeL0kBhmJNMNng=
Message-Id: <6.2.5.6.2.20130330183240.0bdade90@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 30 Mar 2013 18:57:32 -0700
To: roll@ietf.org
From: SM 
In-Reply-To: <20130316171751.11374.33419.idtracker@ietfa.amsl.com>
References: <20130316171751.11374.33419.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [Roll] Last Call:  (Terminology in 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: , 
X-List-Received-Date: Sun, 31 Mar 2013 02:21:28 -0000

At 10:17 16-03-2013, The IESG wrote:
>The IESG has received a request from the Routing Over Low power and Lossy
>networks WG (roll) to consider the following document:
>- 'Terminology in Low power And Lossy Networks'
>    as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@ietf.org mailing lists by 2013-03-30. Exceptionally, comments may be

I took a quick look at the document.

In Section 2:

   "Thus in order to avoid confusion or discrepancies, this document
    specifies the common terminology to be used in all ROLL
    Working Group documents."

It may be better to define terminology for a technology and not for 
work within a working group only.

   "This document should be listed as an informative reference."

As the document defines terminology it might have to be a normative 
reference in other documents.  It's easier to leave it to document 
authors to determine whether the reference should be normative or informative.

In Section 2:

   'Downstream: Data direction traveling from outside of the LLN (e.g.
    traffic coming from a LAN, WAN or the Internet) via a LBR, or in
    general "deeper" in the Directed Acyclic Graph computed by the
    routing protocol.'

LBR is in the next paragraph.  There are other such cases in 
draft-ietf-roll-terminology-12.

  "Smart Grid: A Smart Grid is a broad class of applications to network
   and automate utility infrastructure."

I suggest running this definition through the Smart Power Directorate 
to avoid any conflicting definition in future.

Regards,
-sm 


From stokcons@xs4all.nl  Sun Mar 31 05:16:45 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 A413621F8555 for ; Sun, 31 Mar 2013 05:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.146
X-Spam-Level: 
X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 J7HoT+D+cRB8 for ; Sun, 31 Mar 2013 05:16:44 -0700 (PDT)
Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB1221F850F for ; Sun, 31 Mar 2013 05:16:43 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2VCGd2I024853; Sun, 31 Mar 2013 14:16:40 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sun, 31 Mar 2013 14:16:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 31 Mar 2013 14:16:39 +0200
From: peter van der Stok 
To: Don Sturek 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: 
References: 
Message-ID: <926b15ffb3256aee113b86446093fdcd@xs4all.nl>
X-Sender: stokcons@xs4all.nl (X5SulLxVqj05Tw+8mHrgoEZONd+w7iBt)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: Routing Over Low power and Lossy networks 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks 
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2013 12:16:45 -0000

Hi Don,

Nice to read that some of my conclusions are confirmed by real 
experience.
The behavior you sketch is also recognized by me.

Currently, I try to analyze timing behavior for 1 to 2 hop networks 
including a 10% loss on a link between seed and a destination.
I am not interested in responses (for the moment).
But your aim to have a 100% reception probablity is certainly shared.

Let's compare results when my understanding of this simple network 
topology has increased.

Greetings,

peter

Don Sturek schreef op 2013-03-30 14:11:
> Hi Peter,
> 
> What you wrote below sounds quite correct.   Given our testing, your
> statement that that recommend default paramters depend on the timing
> characteristics of the application and topology of the network aligns 
> very
> well with the test results we gathered.
> 
> Our test used our assumed topology (30 node network with 3 hops).   We
> created the network using IEEE 802.15.4 devices connected via wires on 
> SMA
> connectors (with attenuators to reflect distance between the devices).
> Our test set up was to create a multicast message targeting from 1 to 
> 8
> devices in the network where each of the targeted devices was to 
> create a
> multicast message in response (we were testing how mDNS would work 
> using
> Trickle Multicast in our network).   Our success criteria was to see 
> that
> every node in the network (100% coverage on the requst) saw the 
> original
> multicast request and that the requestor would see all of the 
> responses
> (100% coverage on the responses received).   We ran quite a few tests 
> with
> varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted 
> the
> window to be small thinking that would best service the 
> requests/responses
> but could only get to around 60% of requests seen and responses 
> received.
> Finally, we had to set Imax out to 512ms to achieve our goal.   One 
> clear
> observation is that these settings were definitely tied to the number 
> of
> devices in the network and topology.
> 
> I know for lighting applications that multicasts must be received 
> within
> 250ms.   That was not our use case so we did not impose this 
> restriction.
> It would have been interesting to see if we could have achieved both
> goals:   all devices seeing the request AND the multicast request
> delivered within 250ms.
> 
> Don
> 
> 
> On 3/30/13 5:24 AM, "peter van der Stok"  wrote:
> 
>> Hi Don, Kerry,
>> 
>> 
>> As I tried to express earlier, I am not too happy with the suggested
>> default values for the mpl parameters.
>> Their recommended values very much depend on the timing 
>> characteristics
>> of the application and the topology of the network.
>> I think it is more appropriate to have these values cited in the
>> applicability statements (if they are focused enough).
>> 
>> Coming back to simulation c.q. operation results:
>> I can well imagine that with a network that is loaded for a few 
>> percent
>> of the time with mpl messages the value of k is not that important.
>> I can also imagine that at the edge of networks with a strongly 
>> varying
>> density of repeaters, it is possible that some nodes at the edge only
>> receive messages with a given regularity when k is infinity.
>> In the applications that I consider the density of repeaters is quite
>> homogeneous, the end to end delays are expressed in hundreds of
>> milliseconds and multiple seeds generate messages on a (tens of) 
>> seconds
>> scale. In that case k=1 is often excellent and a higher k is not
>> recommended.
>> 
>> hope this helps,
>> 
>> peter
>> 
>> Don Sturek schreef op 2013-03-29 16:28:
>>> Hi Kerry,
>>> 
>>> Do you have actual test results to back up the claims below?   We 
>>> (the
>>> ZigBee IP team) tested these parameters among 7 solution providers 
>>> and
>>> did
>>> not see what you are reporting.
>>> 
>>> Interested in seeing your results.....
>>> 
>>> Don
>>> 
>>> 
>>> On 3/29/13 8:08 AM, "Kerry Lynn"  wrote:
>>> 
>>>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek 
>>>> wrote:
>>>>> Hi Kerry,
>>>>> 
>>>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses 
>>>>> really
>>>>> only
>>>>> occurs in route-over mesh routing.  I don't believe Homenet has 
>>>>> such
>>>>> routing solutions in their charter.  It is possible to see how a
>>>>> group
>>>>> like Manet might use the draft but the only concrete forwarding
>>>>> solution
>>>>> proposed is over ROLL RPL instances (certainly, provision was left
>>>>> in
>>>>> for
>>>>> other multicast address usage and attendant forwarding rules but
>>>>> those
>>>>> were out of scope for this draft).
>>>>> 
>>>> I don't think this opinion reflects on the validity of my comments
>>>> for
>>>> even
>>>> the restricted ROLL use and I'd be interested in feedback from the
>>>> authors.
>>>> 
>>>> In addition to the comments I made previously, I am concerned that
>>>> the
>>>> default for Imax (== Imin) prevents the Trickle timer interval I 
>>>> from
>>>> ever
>>>> doubling.  Combined with a high k, this leads to aggressive Trickle
>>>> forwarding
>>>> in dense parts of the mesh that may inhibit (by interfering with)
>>>> unicast
>>>> responses in transit to the original sender.  Is there a reason for
>>>> not
>>>> relaxing DATA_MESSAGE_IMAX to e.g.
>>>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>>>> 
>>>> -K-
>>>> 
>>>>> I would propose that we move forward with the draft, within ROLL,
>>>>> and
>>>>> not
>>>>> wait for input from other groups since the scope of the initial
>>>>> draft
>>>>> (absent extensions that other groups could propose in the future) 
>>>>> is
>>>>> focused on ROLL RPL.
>>>>> 
>>>>> Don
>>>>> 
>>>> _______________________________________________
>>>> 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 d.sturek@att.net  Sun Mar 31 11:02:03 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 203DC21F86D2 for ; Sun, 31 Mar 2013 11:02:03 -0700 (PDT)
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 Hov6GrkRBrWc for ; Sun, 31 Mar 2013 11:02:02 -0700 (PDT)
Received: from nm10.access.bullet.mail.sp2.yahoo.com (nm10.access.bullet.mail.sp2.yahoo.com [98.139.44.137]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25521F86C1 for ; Sun, 31 Mar 2013 11:02:02 -0700 (PDT)
Received: from [98.139.44.104] by nm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 31 Mar 2013 18:02:02 -0000
Received: from [98.138.84.173] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 31 Mar 2013 18:02:02 -0000
Received: from [127.0.0.1] by smtp107.sbc.mail.ne1.yahoo.com with NNFMP; 31 Mar 2013 18:02:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364752922; bh=zRrjpTO+utB4ZmCXFD14tit2M1jSMSJFX3TOl1bGgAk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Ct5mkpKigmw9iXZyoXrcg5ncGDuy2zPwDV3rAdl+5FGlhr+Z6+vWoGDub5aPj0bNgYza4uRxRv6j5aR7bt0Y393ZgVCEXtjPinyT9lOogeY/UTbJsiNm21pbeIij7pS5GFWlss5BG3gxXljs4/32i7OrvKmeJM3pvwV79/NdpYc=
X-Yahoo-Newman-Id: 79345.56918.bm@smtp107.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: XVKWjwEVM1mCMeZQAOT_LIHWCl2cyNS8k9e0TWDLQFmvx47 LYPks0MBv3I6zrqhAdkNs3FBpw4Ix2jbR3lJ1RchMQEKZ55G00Pg1O3fzmjz j0akvIIT3JVOcf_dT.CCqXHOQLnChlM5oUXMpLVdFIifjui8IhaFb5GRl8ac Vh0VQUPV6q0_KBBV9Rw4eEJFdmSnZcR60nRn8ajM9wpnrawW6sL5Qp2PJ1gt HyvyZHL.sWSb_iERU92GkKSyZa.dYZ4IhlpXeC9ZvDI1VOzlA79XmfgRN7C7 7BBNdQRjzJ0qCdRNz8mlz1UbW0cQw4fbqqokXfl9_4UMaHJYbYqwNnhVN1pT ABZ4aLCkJEuY3Ef1rMcWFVA5NXuzKgOHZJjtGU2.f5RC83B.a3SsWv.WxyJP AtJAfkSDGswiQXfGf4Mj1rZXvsjQfgBlv65dXav6PU7uD..USn01kkiJM5AV bRlrB3WMr2Y83umPkasU-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.198] (d.sturek@69.105.138.153 with login) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 31 Mar 2013 11:02:02 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Sun, 31 Mar 2013 11:01:57 -0700
From: Don Sturek 
To: 
Message-ID: 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: <926b15ffb3256aee113b86446093fdcd@xs4all.nl>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Routing Over Low power and Lossy networks 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 31 Mar 2013 18:02:03 -0000

Hi Peter,

One thing I forgot to mention.  For the 30 nodes/3 hops, we isolated two
parts of the network such that 15 devices on each half had upward paths to
the DAG root.   This allowed us to model the network as if the DAG root
were in the center of two 15 node network segments of hop count 3 from the
root.   This forced the multicast distribution to transmit all of the way
up to the DAG root and back down to service devices on the other half of
the network segment.

Don


On 3/31/13 5:16 AM, "peter van der Stok"  wrote:

>Hi Don,
>
>Nice to read that some of my conclusions are confirmed by real
>experience.
>The behavior you sketch is also recognized by me.
>
>Currently, I try to analyze timing behavior for 1 to 2 hop networks
>including a 10% loss on a link between seed and a destination.
>I am not interested in responses (for the moment).
>But your aim to have a 100% reception probablity is certainly shared.
>
>Let's compare results when my understanding of this simple network
>topology has increased.
>
>Greetings,
>
>peter
>
>Don Sturek schreef op 2013-03-30 14:11:
>> Hi Peter,
>> 
>> What you wrote below sounds quite correct.   Given our testing, your
>> statement that that recommend default paramters depend on the timing
>> characteristics of the application and topology of the network aligns
>> very
>> well with the test results we gathered.
>> 
>> Our test used our assumed topology (30 node network with 3 hops).   We
>> created the network using IEEE 802.15.4 devices connected via wires on
>> SMA
>> connectors (with attenuators to reflect distance between the devices).
>> Our test set up was to create a multicast message targeting from 1 to
>> 8
>> devices in the network where each of the targeted devices was to
>> create a
>> multicast message in response (we were testing how mDNS would work
>> using
>> Trickle Multicast in our network).   Our success criteria was to see
>> that
>> every node in the network (100% coverage on the requst) saw the
>> original
>> multicast request and that the requestor would see all of the
>> responses
>> (100% coverage on the responses received).   We ran quite a few tests
>> with
>> varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted
>> the
>> window to be small thinking that would best service the
>> requests/responses
>> but could only get to around 60% of requests seen and responses
>> received.
>> Finally, we had to set Imax out to 512ms to achieve our goal.   One
>> clear
>> observation is that these settings were definitely tied to the number
>> of
>> devices in the network and topology.
>> 
>> I know for lighting applications that multicasts must be received
>> within
>> 250ms.   That was not our use case so we did not impose this
>> restriction.
>> It would have been interesting to see if we could have achieved both
>> goals:   all devices seeing the request AND the multicast request
>> delivered within 250ms.
>> 
>> Don
>> 
>> 
>> On 3/30/13 5:24 AM, "peter van der Stok"  wrote:
>> 
>>> Hi Don, Kerry,
>>> 
>>> 
>>> As I tried to express earlier, I am not too happy with the suggested
>>> default values for the mpl parameters.
>>> Their recommended values very much depend on the timing
>>> characteristics
>>> of the application and the topology of the network.
>>> I think it is more appropriate to have these values cited in the
>>> applicability statements (if they are focused enough).
>>> 
>>> Coming back to simulation c.q. operation results:
>>> I can well imagine that with a network that is loaded for a few
>>> percent
>>> of the time with mpl messages the value of k is not that important.
>>> I can also imagine that at the edge of networks with a strongly
>>> varying
>>> density of repeaters, it is possible that some nodes at the edge only
>>> receive messages with a given regularity when k is infinity.
>>> In the applications that I consider the density of repeaters is quite
>>> homogeneous, the end to end delays are expressed in hundreds of
>>> milliseconds and multiple seeds generate messages on a (tens of)
>>> seconds
>>> scale. In that case k=1 is often excellent and a higher k is not
>>> recommended.
>>> 
>>> hope this helps,
>>> 
>>> peter
>>> 
>>> Don Sturek schreef op 2013-03-29 16:28:
>>>> Hi Kerry,
>>>> 
>>>> Do you have actual test results to back up the claims below?   We
>>>> (the
>>>> ZigBee IP team) tested these parameters among 7 solution providers
>>>> and
>>>> did
>>>> not see what you are reporting.
>>>> 
>>>> Interested in seeing your results.....
>>>> 
>>>> Don
>>>> 
>>>> 
>>>> On 3/29/13 8:08 AM, "Kerry Lynn"  wrote:
>>>> 
>>>>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek 
>>>>> wrote:
>>>>>> Hi Kerry,
>>>>>> 
>>>>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses
>>>>>> really
>>>>>> only
>>>>>> occurs in route-over mesh routing.  I don't believe Homenet has
>>>>>> such
>>>>>> routing solutions in their charter.  It is possible to see how a
>>>>>> group
>>>>>> like Manet might use the draft but the only concrete forwarding
>>>>>> solution
>>>>>> proposed is over ROLL RPL instances (certainly, provision was left
>>>>>> in
>>>>>> for
>>>>>> other multicast address usage and attendant forwarding rules but
>>>>>> those
>>>>>> were out of scope for this draft).
>>>>>> 
>>>>> I don't think this opinion reflects on the validity of my comments
>>>>> for
>>>>> even
>>>>> the restricted ROLL use and I'd be interested in feedback from the
>>>>> authors.
>>>>> 
>>>>> In addition to the comments I made previously, I am concerned that
>>>>> the
>>>>> default for Imax (== Imin) prevents the Trickle timer interval I
>>>>> from
>>>>> ever
>>>>> doubling.  Combined with a high k, this leads to aggressive Trickle
>>>>> forwarding
>>>>> in dense parts of the mesh that may inhibit (by interfering with)
>>>>> unicast
>>>>> responses in transit to the original sender.  Is there a reason for
>>>>> not
>>>>> relaxing DATA_MESSAGE_IMAX to e.g.
>>>>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>>>>> 
>>>>> -K-
>>>>> 
>>>>>> I would propose that we move forward with the draft, within ROLL,
>>>>>> and
>>>>>> not
>>>>>> wait for input from other groups since the scope of the initial
>>>>>> draft
>>>>>> (absent extensions that other groups could propose in the future)
>>>>>> is
>>>>>> focused on ROLL RPL.
>>>>>> 
>>>>>> Don
>>>>>> 
>>>>> _______________________________________________
>>>>> 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