From nobody Mon Sep 1 13:38:32 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596BD1A06F6 for ; Mon, 1 Sep 2014 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqomXEjU2jhB for ; Mon, 1 Sep 2014 13:38:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B991A06F0 for ; Mon, 1 Sep 2014 13:38:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F57120028; Mon, 1 Sep 2014 16:42:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BCB3963AE8; Mon, 1 Sep 2014 16:38:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AD4FA638D6; Mon, 1 Sep 2014 16:38:22 -0400 (EDT) From: Michael Richardson To: manav bhatia , roll@ietf.org In-Reply-To: References: <087f01cfc036$26032120$72096360$@ionosnetworks.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/NOw4ym-r2wf-elsOYrqauCIdvQg Cc: draft-ietf-roll-security-threats.all@tools.ietf.org, roll-chairs@tools.ietf.org, draft-ietf-roll-security-threats@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:38:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Thank you Manav for your extensive and detailed review. I'm CC'ing the WG for further comment, perhaps they would like to disagree with me. If there is some significant discussion that we need to have on any of your points, I'll open tickets to track it. I just want to pull some text up to the top. *** This document is as much about naming the threat, and much less about providing a definitive solution to the threat... *** On Mon, Aug 25, 2014 at 12:58 PM, Manav Bhatia wr= ote: > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: > > draft-ietf-roll-security-threats-09 > > Reviewer: Manav Bhatia > Review Date: 25-08-14 > IETF LC End Date: 28-08-14 > Intended Status: Informational > > Summary: > > I have some concerns about this document and recommend that the Routing > ADs discuss these issues further with the authors. > > Comments: > > This document presents a threat analysis for securing the routing > protocols used in LLNs which are more prone to packet losses and other > vulnerabilities. It then discusses how those attacks/threats can be > mitigated. > > Major Issues: > > (1) Sec 7.2.2. "Countering Overclaiming and Misclaiming Attacks" says > that " counter to overclaiming and misclaiming may employ: comparison with > historical routing/topology data;" > > I don't understand how this will work. Assume node A was always a leaf > node and was never attached to any routing device. Later, a new router > gets attached to this node. The node A now starts advertising this new > router. How will the peers know whether it's a legitimate advertisement or > an "overclaim" from node A? I don't agree with notion that somebody could > look at the historical data to figure out if a router is over/under > claiming. > > I also don't think it's a good idea to suggest that we "restrict > realizable network topologies" to counter overclaim/misclaim attacks. I guess I will say two things about this. 1) we have no specific mechanisms in RPL to either recognize this situation or deal with it. It's an attack that (any) node with the L2-keys can do, and therefore falls in the category of threats by insiders. *** This document is as much about naming the threat, and much less about providing a definitive solution to the threat... *** 2) while RPL does have the *A* bit, which can restrict which nodes can operate as intermediate routers and which ones are restricted to leaf nodes. This requires layer-3 security (rather than just layer-2) and further in many situations seems to require that the layer-3 security be provided by asymmetric cryptographic mechanisms. Many are not (yet) convinced that this can be done cheaply enough... The *A* bit can not keep one router from claiming something that belongs to another router, though. It can only keep leafs from becoming routers. > (2) Sec 7.3.2 "Countering Overload Attacks" suggests that "overload > attacks" can be countered by "isolate nodes which send traffic above a > certain threshold based on system operation characteristics;". Has this > been adequately discussed in the WG? It's certainly possible that in an No; I would say that it is a subject of much research. On the topic of nodes getting overloaded, one might want to depreference t= he overloaded node, one would need better energy aware objective functions. RPL has pluggable objective functions, and we know that coming up with bett= er ones is a hot reserach topic. http://datatracker.ietf.org/doc/draft-ajunior-roll-energy-awareness/ is an example of such an effort, but I suspect that over time there will be better ones. On the topic of sending too much non-malicious traffic, the 6tisch WG exists specifically to deal with providing tracks (an MPLS-like form of routes) with both upper and lower bounds on traffic. If the node is malicious, isolation seems to be the right answer. Turning it into a leaf node doesn't help, the node can still send traffic. > Minor Issues: > > (1) A common threat in routing protocols is that there is some > unauthorized entity that somehow manages to gain access to keying > material. Using this material, the attacker can send packets that pass the > authenticity checks based on Message Authentication Codes (MACs). The most > obvious way to mitigate such threat is by periodically changing the keys > currently in use by the legitimate routing peers. Hence routing protocols > designed for LLN must provide provision to easily change their keying > material. Additionally security mechanisms designed for RPL must be such > that the operators can quickly change keys without disrupting the routing > system (data loss) and with minimal operational overhead/expense. If there > is a significant overhead than this can lead to the keys not being changed > often enough. I don't think this aspect is covered in the document. Changing keys is certainly and important way, and if you look at the securi= ty parts of the applicability statements allude to in section 2, and of which draft-ietf-roll-applicability-template* is the template, you'll see that it specifically asks what kind of security mechanisms will be in place. Being able to change keys easily is important, but it is not always possibl= e. > (2) Nodes in this environment can be installed but not switched on for > quite some time. How would such devices get the updated keying material if > it has changed by the time these get turned on? On a related note, what > happens if these nodes support an authentication/encryption algorithm that > gets deprecated by the time these nodes get switched on -- can happen if > this particular node lies dormant for a few years before its turned on > (refer to sec 4.3) I think that those nodes which do not get updated (and can not securely firmware updated), are, sadly, industrial waste. Dan Greer has some opinions about that. I don't know what the security threats documents should say about that. > (3) An automated key management protocol is a very important component of > the security framework. Do all nodes in the LLN need to be manually > configured? This may not be possible if there are large number of nodes in > the routing domain. Wouldn't it make sense to actually discuss this It's not a security framework; it's a set of security threats. > (4) Sec 4.4. "RPL Security Objectives". Are we interested in message > contents validation? Lest there is any doubt let me clarify that I am not > talking about message integrity. I am talking about ensuring that a claim > made in the route advertisement is indeed correct before accepting it > (like SIDR). If we're not doing this, then it might help to explicitly > state that message content validation is out of scope. If you're adding > this, then a note or two on why would be extremely helpful. There are no mechanisms at present to carry SIDR like statements; perhaps a future protocol will figure out how to add that. The WG has discussed this some very long time ago. > (5) Sec 4.4 says " Hence, routing in LLNs needs to bootstrap the > authentication process and allow for flexible expiration scheme of > authentication credentials." > > Can you explain this a bit more? Will this not lead to a circular > dependency where routing bootstraps security, but you need security > already in place for routing to work (to ensure we're speaking to an > authorized node)? It's not circular, but rather, concentric. The security has to bootstraped From=20the root node outwards. > (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really > suggesting that RPL should redundantly flood protocol messages over > multiple paths in the hope that at least one will make it to the > destination. Given the delicate energy and network utilization constraints > this just doesn't look right. Shouldn't we focus more on ensuring that we > don't get an insider malicious node than on what we can do once we have > one inside our routing domain? Flooding is an option if you want to deal with selective forwarding attacks. Yes, that's right, it's a really bad answer, energy-wise. Some deployments might be willing to make that tradeoff. In fact, MPL does *exactly* this, using trickle to control the flood. Or, there is option two: "dynamically selecting the next hop from a set of candidates", as you note. They are mostly mutually exclusive choices. Or, option three: applicability statement says that they aren't going to solve it. > (7) Sec 7.3.3 suggests "dynamically selecting the next hop from a set of > candidates." to counter selective forwarding attacks. I am not sure i > completely understand the point. Are you suggesting that we should > consider multiple paths when constructing the shortest path tree? This > will only work when you have ECMP because its only then that you have a > set of nexthops that you can use without affecting the total cost to reach > the destination. Without ECMP, how can you have a set of nexthops to > choose from? I don't think you're alluding to pinning the path here? You used the term "shortest path" --- RPL doesn't always make a shortest pa= th tree. It can make a lowest-energy-cost tree, or a lowest-latency-tree, or a number of other things if you come up with new objective functions. Most nodes will be in radio range of quite a number of other nodes, so even ECMP is not unreasonable. > (8)7.3.4 "Countering Sinkhole Attacks" suggests "isolate nodes which > receive traffic above a certain threshold;". I disagree doing this without > further qualifying on what's meant by a "certain threshold" for the same > reason as i cited above in (4). > > Nits: > > (1) There are several instances where RFC 2119 keywords are used. While I > personally don't have an issue with using those keywords in an > Informational draft, I was grilled in the IESG review on this and went > through the pain of removing those at the last minute. The WG discussed this recently, and decided to keep 2119 keywords. > (2) Sec 6 describes the threats and the possible attacks on RPL. In this > context the title of Sec 6.1 is very clear and the reader understands the > threat/attack being discussed in the following subsection. However the > title of Sec 6.2 is very vague. I had to read the entire subsection to > understand what the subsection was about. I think what you want to cover > are the threats you get exposed to if your system *lacks* confidentiality. So you are suggesting that the title: 6.2. Threats and Attacks on Confidentiality should say something more like: 6.2. Threats due to failures to keep routing information confidential ??? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVATZPICLcPvd0N1lAQJbwQf8Dd8gU8IUBNyxWHZ4c76R39I+8NoVw83o 2Tv8Kpt2UOD8URkj3rt7RojSQrGfdSpe2HUzCF1PihgijjUAwqMgc3COTFbQUOVA 1LEzNeyWPEk2nur7zbO9vMWdS1e+nVaRKKA46F/ieW7ZTQpDecVsaxEJTdWa7PZt TjtAjXwv9WDzaXUgZCE2EKOJ2DoXrxhmm5+jRE0DC/1sxSDbB5zImeAiWu+HLHoD +NIcoP1VLR4uVXmltsueUHmS7qpC9YxL+wD1OP/w57goy+585iKHkAIbZALGE4Em PGyZe8KRRyWhx2mUjQNW9HkRCjkLXbUC8bGn+1TD9SbGZcj7kTgreA== =VKTy -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 3 13:44:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16B71A0AEB for ; Wed, 3 Sep 2014 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK5Jd10GdHQr for ; Wed, 3 Sep 2014 13:44:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BC01A036C for ; Wed, 3 Sep 2014 13:44:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 19DBF1C7A; Wed, 3 Sep 2014 22:44:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s7F7SWM8PVUz; Wed, 3 Sep 2014 22:44:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 22:44:37 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 129C320036; Wed, 3 Sep 2014 22:44:37 +0200 (CEST) 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 at1feZt8H-TU; Wed, 3 Sep 2014 22:44:36 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 24AF820035; Wed, 3 Sep 2014 22:44:36 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 22:44:35 +0200 From: "Sehgal, Anuj" To: "roll@ietf.org" Thread-Topic: Issue with multiple instances in RPL Thread-Index: AQHPx7ffe1SAELIbPUe8HXLi/MG7HA== Date: Wed, 3 Sep 2014 20:44:35 +0000 Message-ID: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.155.157.24] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/LTQ246VInTdBDnEmYgYuoJlQjdk Subject: [Roll] Issue with multiple instances in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:44:45 -0000 Hi, We are working on an application that would require the use of multiple RPL= instances. For implementation purposes we adopted Contiki 2.7, since it ha= s at least rudimentary support for multiple DODAGs and multiple instances a= lready built-in. However, during our development of the multi-instance code= in Contiki we discovered a problem that seems to stem from RFC 6550 itself= . The RFC 6550 states that during preferred parent discovery "nodes that deci= de to join a DODAG MUST provision at least one DODAG parent as a default ro= ute for the associated instance." Even though the RFC states that the defau= lt route should be for the associated instance, while building a routing ta= ble in the IP layer there is no ability to select multiple default routes. = Furthermore, an IP routing table does not allow for marking which default r= oute applies to which instance. In fact, since IP packets do not carry any = information as to which instance originated the packet, even special markup= associated with IP routes cannot be used for making an appropriate routing= decision. This essentially means that when a node is part of two instances, it can on= ly have one default route, which either belongs to DODAG from instance A, o= r DODAG from instance B. Consequentially, whichever is the currently the "a= ctive" instance, i.e. the DODAG for which the last DIO message was received= , occupies the default route within the IP routing table. Another side effe= ct of this is that each time a DIO message is received from the other insta= nce, the default route changes. Of course, this leads to non-decisive routi= ng of packets; the main problem being that instance A might try to route pa= ckets for instance B and vice-versa, while this should not occur. Since the IP routing table does not support the ability to have two default= routes, a simple solution appears to be that instead of configuring a defa= ult route upon receiving a DIO message, the node should just add a simple r= outing table entry for the prefixes announced in the message. This should s= olve the problem with multiple default routes, and even the constantly chan= ging default route issue. The only shortcoming of not having a default route is that packets that are= intended for being routed outside of the RPL instance(s) will not find a v= alid route. This could be solved by the intended border router also adverti= sing a prefix for all routes. This should work in most applications since i= t would seem unlikely that there is more than one Internet gateway in an ap= plication. Based on the presented information, what do the authors of RFC 6550 recomme= nd be done with default routes, in case of multiple RPL instances? Furtherm= ore, a clarification might be needed for the language in the RFC, so that i= mplementations of RPL adopt the appropriate solution. Warm regards, Anuj Sehgal From nobody Wed Sep 3 20:55:11 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C91A6F68 for ; Wed, 3 Sep 2014 20:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PefEPyRZjWVO for ; Wed, 3 Sep 2014 20:55:08 -0700 (PDT) Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.66]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE01A6F76 for ; Wed, 3 Sep 2014 20:55:06 -0700 (PDT) Received: from ece.iisc.ernet.in (www.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (8.13.1/8.13.1) with ESMTP id s843spIA000741 for ; Thu, 4 Sep 2014 09:24:51 +0530 Received: from ece.iisc.ernet.in (localhost [127.0.0.1]) by ece.iisc.ernet.in (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id s843rGmq027941 for ; Thu, 4 Sep 2014 09:23:16 +0530 Received: (from wwwrun@localhost) by ece.iisc.ernet.in (8.13.6/8.13.6/Submit) id s843rGKg027939; Thu, 4 Sep 2014 09:23:16 +0530 From: Anand@ece.iisc.ernet.in Received: from 10.16.40.11 (proxying for 61.3.27.226) (SquirrelMail authenticated user Anand) by www.ece.iisc.ernet.in with HTTP; Thu, 4 Sep 2014 09:23:16 +0530 Message-ID: <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in> In-Reply-To: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> References: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> Date: Thu, 4 Sep 2014 09:23:16 +0530 To: "Routing Over Low power and Lossy networks" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-IISc-MailScanner-Information: Please contact the ISP for more information X-IISc-MailScanner: Found to be clean X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.799, required 6.5, ALL_TRUSTED -1.00, BAYES_00 -1.90, FSL_RCVD_USER 0.00, NO_REAL_NAME 1.00, _LOCAL_RCVD_THRU_RPROXY 1.10) X-IISc-MailScanner-From: anand@ece.iisc.ernet.in Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZIgyO8b_vVuA6C3gl3VkQ-riknY Subject: Re: [Roll] Issue with multiple instances in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 03:55:09 -0000 Hi Anuj, Just curious to know, is it difficult to tweak IP layer code to realise what you mentioned ? I know a typical IP implementation is what you are referring to. These days with so much happening in the forwarding path in the form of policy based routing, one can have an internal mechanism to achieve what you are saying, no ? Hope my understanding of your concern is right. Anand > Hi, > > We are working on an application that would require the use of multiple > RPL instances. For implementation purposes we adopted Contiki 2.7, since > it has at least rudimentary support for multiple DODAGs and multiple > instances already built-in. However, during our development of the > multi-instance code in Contiki we discovered a problem that seems to stem > from RFC 6550 itself. > > The RFC 6550 states that during preferred parent discovery "nodes that > decide to join a DODAG MUST provision at least one DODAG parent as a > default route for the associated instance." Even though the RFC states > that the default route should be for the associated instance, while > building a routing table in the IP layer there is no ability to select > multiple default routes. Furthermore, an IP routing table does not allow > for marking which default route applies to which instance. In fact, since > IP packets do not carry any information as to which instance originated > the packet, even special markup associated with IP routes cannot be used > for making an appropriate routing decision. > > This essentially means that when a node is part of two instances, it can > only have one default route, which either belongs to DODAG from instance > A, or DODAG from instance B. Consequentially, whichever is the currently > the "active" instance, i.e. the DODAG for which the last DIO message was > received, occupies the default route within the IP routing table. Another > side effect of this is that each time a DIO message is received from the > other instance, the default route changes. Of course, this leads to > non-decisive routing of packets; the main problem being that instance A > might try to route packets for instance B and vice-versa, while this > should not occur. > > Since the IP routing table does not support the ability to have two > default routes, a simple solution appears to be that instead of > configuring a default route upon receiving a DIO message, the node should > just add a simple routing table entry for the prefixes announced in the > message. This should solve the problem with multiple default routes, and > even the constantly changing default route issue. > > The only shortcoming of not having a default route is that packets that > are intended for being routed outside of the RPL instance(s) will not find > a valid route. This could be solved by the intended border router also > advertising a prefix for all routes. This should work in most applications > since it would seem unlikely that there is more than one Internet gateway > in an application. > > Based on the presented information, what do the authors of RFC 6550 > recommend be done with default routes, in case of multiple RPL instances? > Furthermore, a clarification might be needed for the language in the RFC, > so that implementations of RPL adopt the appropriate solution. > > Warm regards, > Anuj Sehgal > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nobody Thu Sep 4 02:44:44 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6691A00F1 for ; Thu, 4 Sep 2014 02:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm24De10lq7t for ; Thu, 4 Sep 2014 02:44:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051EB1A00BB for ; Thu, 4 Sep 2014 02:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5103; q=dns/txt; s=iport; t=1409823879; x=1411033479; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8WStD6C33bF7eNqzJTo4u6w4CfsEluf30N5elhfxTKg=; b=TRjnkazrbnpACYkhGwTFF3F+e15H9Enm88anbxt6qnlMGfeb4pSpIVSV B6nt2LEOySMQWL/xA09Qd77pjRLsBGvSgI/JXUxp+DkxF2qz9INVjgTVZ PiB4zYMSFEF8H/ZXN0Pn7wOn2AA2IwtqPgeobmWpFOpd1zAJkcNOKUM9/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAD0zCFStJV2d/2dsb2JhbABZgw1TW8gZCodMAYEKFneEAwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgTiCcNvlQBEwSKL4RQHTgGgymBHQWRPpdKiQaDYWwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,465,1406592000"; d="scan'208";a="74857681" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 04 Sep 2014 09:44:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s849ibm4000694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Sep 2014 09:44:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 04:44:37 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Issue with multiple instances in RPL Thread-Index: AQHPx7ffe1SAELIbPUe8HXLi/MG7HJvwq+UAgAALd8A= Date: Thu, 4 Sep 2014 09:44:36 +0000 Deferred-Delivery: Thu, 4 Sep 2014 09:44:00 +0000 Message-ID: References: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in> In-Reply-To: <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YPOFocCC6MrxsVm2qmqCeVxMbSo Subject: Re: [Roll] Issue with multiple instances in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:44:42 -0000 Hi Anuj, There is no problem with RPL itself.=20 To support multiple instances the platform needs to be capable of implement= ing something like Virtual Routing and Forwarding (VRF). >From an information such as receive interface, flow label, TOS bits or RPL= option, the router derives a table ID / scope and looks up the RIB that co= rresponds to that table ID / scope. If you system can only have one RIB, then you are not capable of participat= ing to multiple instances of RPL at the same time. You'll find that draft-thubert-6lo-rpl-nhc elides the instance ID when it i= s zero.=20 I can extend that to a well-known admin value default 0 if you need, please= suggest that on the 6lo list if so. =20 Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of > Anand@ece.iisc.ernet.in > Sent: jeudi 4 septembre 2014 05:53 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Issue with multiple instances in RPL >=20 > Hi Anuj, >=20 > Just curious to know, is it difficult to tweak IP layer code to realise w= hat you > mentioned ? I know a typical IP implementation is what you are referring = to. > These days with so much happening in the forwarding path in the form of > policy based routing, one can have an internal mechanism to achieve what > you are saying, no ? Hope my understanding of your concern is right. >=20 > Anand >=20 > > Hi, > > > > We are working on an application that would require the use of > > multiple RPL instances. For implementation purposes we adopted Contiki > > 2.7, since it has at least rudimentary support for multiple DODAGs and > > multiple instances already built-in. However, during our development > > of the multi-instance code in Contiki we discovered a problem that > > seems to stem from RFC 6550 itself. > > > > The RFC 6550 states that during preferred parent discovery "nodes that > > decide to join a DODAG MUST provision at least one DODAG parent as a > > default route for the associated instance." Even though the RFC states > > that the default route should be for the associated instance, while > > building a routing table in the IP layer there is no ability to select > > multiple default routes. Furthermore, an IP routing table does not > > allow for marking which default route applies to which instance. In > > fact, since IP packets do not carry any information as to which > > instance originated the packet, even special markup associated with IP > > routes cannot be used for making an appropriate routing decision. > > > > This essentially means that when a node is part of two instances, it > > can only have one default route, which either belongs to DODAG from > > instance A, or DODAG from instance B. Consequentially, whichever is > > the currently the "active" instance, i.e. the DODAG for which the last > > DIO message was received, occupies the default route within the IP > > routing table. Another side effect of this is that each time a DIO > > message is received from the other instance, the default route > > changes. Of course, this leads to non-decisive routing of packets; the > > main problem being that instance A might try to route packets for > > instance B and vice-versa, while this should not occur. > > > > Since the IP routing table does not support the ability to have two > > default routes, a simple solution appears to be that instead of > > configuring a default route upon receiving a DIO message, the node > > should just add a simple routing table entry for the prefixes > > announced in the message. This should solve the problem with multiple > > default routes, and even the constantly changing default route issue. > > > > The only shortcoming of not having a default route is that packets > > that are intended for being routed outside of the RPL instance(s) will > > not find a valid route. This could be solved by the intended border > > router also advertising a prefix for all routes. This should work in > > most applications since it would seem unlikely that there is more than > > one Internet gateway in an application. > > > > Based on the presented information, what do the authors of RFC 6550 > > recommend be done with default routes, in case of multiple RPL instance= s? > > Furthermore, a clarification might be needed for the language in the > > RFC, so that implementations of RPL adopt the appropriate solution. > > > > Warm regards, > > Anuj Sehgal > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > -- > > This message has been scanned for viruses and dangerous content by > > MailScanner, and is believed to be clean. > > >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Sep 4 08:07:10 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F611A8906 for ; Thu, 4 Sep 2014 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcfa2jkAYb5T for ; Thu, 4 Sep 2014 08:06:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C6F1A88FE for ; Thu, 4 Sep 2014 08:06:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AB9E120028 for ; Thu, 4 Sep 2014 11:10:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7355A63AE8; Thu, 4 Sep 2014 11:06:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D915638D6 for ; Thu, 4 Sep 2014 11:06:35 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Nlo2JB1EMkKKmqYSc9dL3fLOA3g Subject: Re: [Roll] Issue with multiple instances in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:06:50 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > participating to multiple instances of RPL at the same time. You'll > find that draft-thubert-6lo-rpl-nhc elides the instance ID when it is > zero. I can extend that to a well-known admin value default 0 if you > need, please suggest that on the 6lo list if so. Did you typo "0" somewhere here? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVAh/+YCLcPvd0N1lAQKriwgAvUba/NzG+DukJ3asf31SB5qdfVo4SdQC dwHT/4vQ9J+Lt8euvldZ7C1Re4vbfP5Vze4tsbKFwmS8AdCFMURR7eTYijCoCbzT A/XNpS5IIHhqvzSTexssI5WwQACPuFe8PlSJF7YAzxW+SYUmiFtps3cQ1Sa0Cu8K Gxefl7BS7xZ8tdGxr0Ar8fg0ijoB9iSIby6R9e2EDHyJOS7ETRF8/cXo63+g57bG dHQcn6nY/gcb5zW+aXZZU372Ztl4FdYeR3qn5vL3bsJvmHyovn5uPoC+W9RJYbfD 03g3zcq/Fwhfp+Jv93/F5Sk4AEv0S5zXlKMQMfpVby6env0O/CatBQ== =O6ZU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 4 08:48:56 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68E41A8905 for ; Thu, 4 Sep 2014 08:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqv0W3FmI0Lx for ; Thu, 4 Sep 2014 08:48:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA4C1A03ED for ; Thu, 4 Sep 2014 08:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=941; q=dns/txt; s=iport; t=1409845687; x=1411055287; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BTkl51jmDUq+hy5oeeefAPWz++UTm0O+Bg7kU9ceGuk=; b=FUisWFty+mWUaCtU/NbuN35G2o1Yf/iTWZkCwTzxJ4wj+KttoaCzahrF 7V0TCB+rYKyor7ILErIzeIa2Edi4I7RtENUmwj5rf1kZUiOi08FDA5vyN VOoLxE8sBDnr2z75gRG67D95EnXklIZ9MyUb2ZLB/X8FPXPalifiNGI3L Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAJCICFStJV2U/2dsb2JhbABZgw2BKgTPdAGBBRZ3hAMBAQEEOksEAgEIEQQBAQEKFAkHMhQJCAIEEwiIOr0RAReOfx04BoMpgR0BBJE+l0qJBoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,466,1406592000"; d="scan'208";a="349489744" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2014 15:48:06 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s84Fm5lL028132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Sep 2014 15:48:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 10:48:05 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Issue with multiple instances in RPL Thread-Index: AQHPyFH/u0dbz6TYK0mvOEfWp9N7k5vxHj0g Date: Thu, 4 Sep 2014 15:48:04 +0000 Deferred-Delivery: Thu, 4 Sep 2014 15:48:00 +0000 Message-ID: References: <8727EEDC-3231-42EE-89FE-36CBCEB6C455@jacobs-university.de> <88d10f004652cc18ce329da7d94800b1.squirrel@www.ece.iisc.ernet.in> <16807.1409843195@sandelman.ca> In-Reply-To: <16807.1409843195@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/sBc8WkH9r8g26-KVMP81AAVj0s8 Subject: Re: [Roll] Issue with multiple instances in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:48:53 -0000 I meant that the elided instance could be 0 (zero) by default but a context= could indicate otherwise... Pardon my French : ) Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: jeudi 4 septembre 2014 17:07 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Issue with multiple instances in RPL >=20 >=20 > Pascal Thubert (pthubert) wrote: > > participating to multiple instances of RPL at the same time. You'l= l > > find that draft-thubert-6lo-rpl-nhc elides the instance ID when it = is > > zero. I can extend that to a well-known admin value default 0 if y= ou > > need, please suggest that on the 6lo list if so. >=20 > Did you typo "0" somewhere here? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Fri Sep 5 05:44:14 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49181A066B; Fri, 5 Sep 2014 05:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.999, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSg9VoHPFa94; Fri, 5 Sep 2014 05:44:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678311A0696; Fri, 5 Sep 2014 05:44:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51E332002A; Fri, 5 Sep 2014 08:48:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D303E63AE9; Fri, 5 Sep 2014 08:44:02 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BD560638D6; Fri, 5 Sep 2014 08:44:02 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, 6tisch@ietf.org X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/oSAA8xEBkT7taWrrTlaKJ4hsPP8 Subject: [Roll] any interest in a RPL adjancy MIB/YANG model X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:44:11 -0000 --=-=-= This reminded me: internet-drafts@ietf.org wrote: > Title : Definition of Managed Objects for IPv6 over Low-Power > Wireless Personal Area Networks (6LoWPANs) Authors : Juergen that I think it would be useful to have a standard way to get the list of adjacencies from a route-over mesh. I know that RedwireLLC produced a really nice graphic from some custom instrumentation that they did, and I've seen similar graphs from Cisco too. I was thinking about this the other morning during my cycle to work, and realized that the list of possible adjancies is perhaps the read-only version of the 6top data model. The PCE would need to know the list of all the possible adjancies (not just the ones that RPL locally chose), and so that there is significant overlap. Am I missing something here? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVAmwEICLcPvd0N1lAQJAQQf/WbLewGedQHCA1pO+csbXON+GkmbWaELG rwJsPguDWtx9ECwdEcUU+YZ0tLOMkaKhmC49l/GjExfV+u2N/0FO6nn0RU3lnlt7 bcEX40l3ZzjXnoUBKnpQfajB3zYdStrJuDMjEaFN2b4MeTTZ6zwwo1Cx0DGY/ToE 6+Gy9VEK/UlevpdToq/0ofQ3Oeufv+5Oydv3a79xK9ilNV2tZSdt/91mPnuQwOEU WuOe25Kx0Vfgt8+kQMvK3cR4F+R/Ns8XULF4AWmQQz6uead7K7yc/O1Lxw0NfD0F XGFoo/9kahGu5o7Twk5di7GxYBeuV0I02Dv4Ln1I0Urna36BKUg9Qg== =OM5i -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 8 08:36:32 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F51E1A052E; Mon, 8 Sep 2014 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynRa3y4cBnaG; Mon, 8 Sep 2014 08:36:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A850F1A8877; Mon, 8 Sep 2014 08:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908153622.32407.83705.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 08:36:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/IGwOVB7YTvIm2X-MQBcmXGlAU3g Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:36:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL) Authors : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Michael Richardson Filename : draft-ietf-roll-security-threats-10.txt Pages : 40 Date : 2014-09-08 Abstract: This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-security-threats-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 9 04:56:47 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD31A0052 for ; Tue, 9 Sep 2014 04:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po4JPRjC8GV0 for ; Tue, 9 Sep 2014 04:46:47 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D1C1A004C for ; Tue, 9 Sep 2014 04:46:46 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so4284966lab.1 for ; Tue, 09 Sep 2014 04:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xvPoEK5TIaKcj7nVqgrZjEbnfQC3dPVv9oBco+a+000=; b=cCa1bovMzayvKXMNai7keww7/IkSMiQyeyneEHwHEBWlZNXA/6eAGM5MRwd39q8ooP 7iM2AfPayM0NyKxCdsK/NLOIBhiyG454Or+u1k8hbjmd4iTfsTGrxuEmy3RE/wiSPRTL L5Y8FjNycczW22QHZplJ6U8lkT4CDMBZ303rDz1rob0CSc73RMjEmDoxpdoIXraKJ/tH uhLucxBApfweW8AIE3OVZO3YnL6+kofBwZTyMxYApdLRBMTIqzMgY8ewATr0aDvujssc 7DP5hV7s1LWzryt6EP3b0OLfQbytp2+TLaBy91mE933q9XkA155nlkRjkRsr7+nQ6hT0 Tw8A== X-Gm-Message-State: ALoCoQn4jfoB+aqD3/V/XxIkWlJ8mVPPKYMScyspF1MloP+0fAslsRHd/+43I7q7hO4XgwPib0OM MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr33215109lbb.11.1410263204942; Tue, 09 Sep 2014 04:46:44 -0700 (PDT) Received: by 10.112.126.132 with HTTP; Tue, 9 Sep 2014 04:46:44 -0700 (PDT) In-Reply-To: <9079.1409603902@sandelman.ca> References: <087f01cfc036$26032120$72096360$@ionosnetworks.com> <9079.1409603902@sandelman.ca> Date: Tue, 9 Sep 2014 17:16:44 +0530 Message-ID: From: manav bhatia To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3QLUAxhS3-fHs_JmDiC4IQJyTag X-Mailman-Approved-At: Tue, 09 Sep 2014 04:56:43 -0700 Cc: draft-ietf-roll-security-threats.all@tools.ietf.org, draft-ietf-roll-security-threats@tools.ietf.org, roll@ietf.org, "rtg-ads@tools.ietf.org" , roll-chairs@tools.ietf.org Subject: Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:46:49 -0000 Hi Michael, > *** > This document is as much about naming the threat, and much less about > providing a definitive solution to the threat... > *** Then what precisely is Sec 7 - "Countermeasures" for? All my comments are on the text within those sub sections. [clipped] >> >> I also don't think it's a good idea to suggest that we "restrict >> realizable network topologies" to counter overclaim/misclaim attacks. > > I guess I will say two things about this. > 1) we have no specific mechanisms in RPL to either recognize this situation > or deal with it. It's an attack that (any) node with the L2-keys > can do, and therefore falls in the category of threats by insiders. I dont think you get my point. What i am describing is not an attack. The counter provided in the text to avoid misclaiming imo doesnt look proper to me. However if i am the only one who thinks that the guidance provided is not the best, then we could ignore this and move on. >> (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really >> suggesting that RPL should redundantly flood protocol messages over >> multiple paths in the hope that at least one will make it to the >> destination. Given the delicate energy and network utilization constraints >> this just doesn't look right. Shouldn't we focus more on ensuring that we >> don't get an insider malicious node than on what we can do once we have >> one inside our routing domain? > > Flooding is an option if you want to deal with selective forwarding attacks. > Yes, that's right, it's a really bad answer, energy-wise. Some deployments > might be willing to make that tradeoff. In fact, MPL does *exactly* this, > using trickle to control the flood. > > Or, there is option two: "dynamically selecting the next hop from a set of > candidates", as you note. They are mostly mutually exclusive choices. > > Or, option three: applicability statement says that they aren't going to > solve it. Flooding just doesnt seem right, especially in energy constrained networks and devices. > > > So you are suggesting that the title: > 6.2. Threats and Attacks on Confidentiality > > should say something more like: > 6.2. Threats due to failures to keep routing information confidential Yup, this is better. Manav From nobody Fri Sep 12 06:42:31 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21AA1A0B7F; Fri, 12 Sep 2014 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=2, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU3xs0xAJm5s; Fri, 12 Sep 2014 06:42:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0E91A0B75; Fri, 12 Sep 2014 06:42:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A68C62002D; Fri, 12 Sep 2014 09:46:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3C61563AEB; Fri, 12 Sep 2014 09:42:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1BE94637FC; Fri, 12 Sep 2014 09:42:23 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/cGwwb0_JoBYG59teCAazW9NnIdc Cc: 6man@ietf.org, 6lo@ietf.org Subject: [Roll] Use of flow-label in RPL (LLN) networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 13:42:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable PROPOSED LAST CALL QUESTION on draft-flow-label Background: at IETF90, at the ROLL WG meeting it was agreed that the flow-label draft could go as an AD sponsored draft, as the ROLL WG would otherwise be shutting down, and the flow-label work was not quite in charter. The plan was to have a joint last call between 6man and ROLL, and if the parties agreed, that the document would advance as an AD sponsored draft. A LC was issued in August 2014, and there was some discussion. Three tickets were opened to track issues: http://tools.ietf.org/wg/6man/trac/ticket/5 - Evidence about energy consumption http://tools.ietf.org/wg/6man/trac/ticket/6 - Updates: 6437 (if approved) - add section with explanation http://tools.ietf.org/wg/6man/trac/ticket/7 - Relation with RFC 6294 http://tools.ietf.org/wg/6man/trac/ticket/8 - relation with draft-bormann-6lo-rpl-mesh-00 It is the opinion of the ROLL co-chairs that we got a pretty good consensus that use of the flow-label in the manner proposed was acceptable. Further that it was acceptable to reset/change the flow label upon entering an LLN, and it was also reasonable to reset the flow label to value (as if it had been zero) upon exiting the LLN, for the benefit for the core Internet. We are going to call this part of the consensus "6man blessing" We also feel that there was consensus that the RFC6553 Hop-by-Hop header is energy inefficient, and a mistake. draft-bormann-6lo-rpl-mesh proposes a different way to encode the InstanceID (a constant) and Rank (a value which changes hop by hop) using the 6lowpan = HC mechanisms. This mechanism is equivalently efficient as draft-thubert-6man-flow-label-for-rpl, provided that the flow label is zero= ,=20 and HC can compress it out.=20=20 draft-bormann-6lo-rpl-mesh therefore depends upon 6man to reset the flow label upon entering/exiting the LLN. The ROLL co-chairs did not come to the conclusion that there was a compelling technical reason to use the flow lab= el or the HC option expressed. There was also not any clear support or discussion about the benefits of either mechanism outside of the authors of each draft; the co-chairs, taking advice from http://tools.ietf.org/html/rfc7282 (On Consensus and Humming in the IETF),= =20 section 2, concluded that we have essentially an A or B situation.=20=20 We also took in account that perhaps mid-summer August was not the best time to solicit opinions.=20 There are two paths for forward (perhaps more):=20 A. adopt draft-thubert-6man-flow-label-for-rpl, incorporate 6man feedback, publish (perhaps add to ROLL milestones)=20 B. create a 6man-flow-label considerations in LLNs document, taking just the issues about resetting flowlabel to zero, and negotiate who (6lo vs ROLL) will adopt draft-bormann-6lo-rpl-mesh=20 What we are looking for is not a process discussion at this point (if you think we should add a C, please unicast the chairs). So we are also not looking "I like X" comments, but rather "mechanism Y does not work because of Z". (see RFC7282 if you like) This is not a WGLC or a Consensus call, we are interested in discussion. Having said that, we are sensitive to the fact that 6tisch would like to specify *a* solution sooner. So there is no end date, but we sure=20 would like to hear from people by 2014-09-30. This discussion should please occur on the ROLL mailing list. Ines and Michael. =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) iQEVAwUBVBL4PICLcPvd0N1lAQL/sAgAoCQfKxzntHvDuy7vfz9D5kPgN01/Ja3d 9uefBFvgpMnwSXiKRcnud07w5v2aStPkrARXRNOjJxUtqIEz+dF59X8rgI5Oy+mp nmPA0IDQqPzeM31PHDkJQISlfRMLgGSWkyoTnY0pKU/v9UCGokyR9okvWGX3H3se /yX/w+8SEZcvZH5sdIs61OIZ1i5UG1b7rqkRNSKheN03KTM3Rfo19NII2tpL13Kj yWkuc+yKuN/7nXWZtQBB4gizEj7x2xnzgvZh93/1kcEErS6AAEuAVoOcHf8KiZgS yJU1XEYbZGX/48cXpDxBrS5b0n9u57kJ8tdjLXesrafozRhQhPd5WQ== =TEhl -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 12 07:15:12 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8D1A086B; Fri, 12 Sep 2014 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI0ODbf0P83F; Fri, 12 Sep 2014 07:14:51 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C72D1A06D8; Fri, 12 Sep 2014 07:14:45 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x3so906434qcv.30 for ; Fri, 12 Sep 2014 07:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=dU2M95S5XKP5Y8r/apEmLPXK2RvEbKuo+IGA2eSTpM0=; b=Y0FOALV9H4b8NS2yotzmANN9+yV3Ti4DzlEZ66LWvZsIsmbfOhg+uL7XZTYoScGCJs mibrm7mK0MsNjjDDoxuWy02v55lueqSgd+DA4L/arES+x0/rmW1aI0q3Tzm6pvrPUKnr O55Pg/9ZDP+Z6Mf0Mh3SywXqrN7RKI0Ny0hcsWICnkn2EwETjQFGqwUTwcp/7bBOGPxc ljG0vnJA/HJ06UX0L/Xsdq3w01AsZvznXZ+adQ0spwBcjoxOqb4GlfEAfvBAJAy2nxTv QsiD1Z5LXjL004QlxNzMOy9V+5nFBlDcC63Cb1dHhRYByTXJh13nqCbeEopTflJACr0z 2dlQ== X-Received: by 10.140.44.98 with SMTP id f89mr7512354qga.44.1410531284412; Fri, 12 Sep 2014 07:14:44 -0700 (PDT) Received: from [10.180.222.223] ([166.170.34.200]) by mx.google.com with ESMTPSA id w8sm3026679qgw.46.2014.09.12.07.14.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 07:14:43 -0700 (PDT) References: <26959.1410529343@sandelman.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <26959.1410529343@sandelman.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Ralph Droms Date: Fri, 12 Sep 2014 10:14:39 -0400 To: Michael Richardson Archived-At: http://mailarchive.ietf.org/arch/msg/roll/bRFGQ_bPdJYsuhqF9wDs97nMRTw Cc: "roll@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Use of flow-label in RPL (LLN) networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 14:14:57 -0000 Seems to me this doc could be judged to be in scope of the 6man charter. As= this document was to be joint last called in both 6man and roll, and consid= ering bringing docs to the IESG is usually preferred over AD sponsorship, I s= uggest that 6man consider taking this doc. - Ralph > On Sep 12, 2014, at 9:42 AM, Michael Richardson wr= ote: >=20 >=20 > PROPOSED LAST CALL QUESTION on draft-flow-label >=20 > Background: at IETF90, at the ROLL WG meeting it was agreed that the > flow-label draft could go as an AD sponsored draft, as the ROLL WG would > otherwise be shutting down, and the flow-label work was not quite in > charter. The plan was to have a joint last call between 6man and ROLL, an= d > if the parties agreed, that the document would advance as an AD sponsored > draft. >=20 > A LC was issued in August 2014, and there was some discussion. > Three tickets were opened to track issues: >=20 > http://tools.ietf.org/wg/6man/trac/ticket/5 - Evidence about energy > consumption > http://tools.ietf.org/wg/6man/trac/ticket/6 - Updates: 6437 (if approved) -= > add section with explanation > http://tools.ietf.org/wg/6man/trac/ticket/7 - Relation with RFC 6294 > http://tools.ietf.org/wg/6man/trac/ticket/8 - relation with > draft-bormann-6lo-rpl-mesh-00= >=20 > It is the opinion of the ROLL co-chairs that we got a pretty good consensu= s > that use of the flow-label in the manner proposed was acceptable. Further= > that it was acceptable to reset/change the flow label upon entering an LLN= , > and it was also reasonable to reset the flow label to value (as if it had= > been zero) upon exiting the LLN, for the benefit for the core Internet. W= e > are going to call this part of the consensus "6man blessing" >=20 > We also feel that there was consensus that the RFC6553 Hop-by-Hop header i= s > energy inefficient, and a mistake. >=20 > draft-bormann-6lo-rpl-mesh proposes a different way to encode the Instance= ID > (a constant) and Rank (a value which changes hop by hop) using the 6lowpan= HC > mechanisms. This mechanism is equivalently efficient as > draft-thubert-6man-flow-label-for-rpl, provided that the flow label is zer= o,=20 > and HC can compress it out. =20 >=20 > draft-bormann-6lo-rpl-mesh therefore depends upon 6man to reset the flow > label upon entering/exiting the LLN. The ROLL co-chairs did not come to th= e > conclusion that there was a compelling technical reason to use the flow la= bel > or the HC option expressed. There was also not any clear support or > discussion about the benefits of either mechanism outside of the authors o= f > each draft; the co-chairs, taking advice from > http://tools.ietf.org/html/rfc7282 (On Consensus and Humming in the IETF),= =20 > section 2, concluded that we have essentially an A or B situation. =20 > We also took in account that perhaps mid-summer August was not the best ti= me > to solicit opinions.=20 >=20 > There are two paths for forward (perhaps more):=20 > A. adopt draft-thubert-6man-flow-label-for-rpl, incorporate 6man feedback= , > publish (perhaps add to ROLL milestones)=20 > B. create a 6man-flow-label considerations in LLNs document, taking just > the issues about resetting flowlabel to zero, and negotiate who (6lo v= s > ROLL) will adopt draft-bormann-6lo-rpl-mesh=20 >=20 > What we are looking for is not a process discussion at this point > (if you think we should add a C, please unicast the chairs). >=20 > So we are also not looking "I like X" comments, but rather "mechanism Y do= es > not work because of Z". (see RFC7282 if you like) >=20 > This is not a WGLC or a Consensus call, we are interested in discussion. >=20 > Having said that, we are sensitive to the fact that 6tisch would like to > specify *a* solution sooner. So there is no end date, but we sure=20 > would like to hear from people by 2014-09-30. >=20 > This discussion should please occur on the ROLL mailing list. >=20 > Ines and Michael. >=20 > --=20 > Michael Richardson , Sandelman Software Works=20 > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Fri Sep 12 10:30:17 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D71A802F; Fri, 12 Sep 2014 10:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clt1Wy1Dn9Pg; Fri, 12 Sep 2014 10:30:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A32B1A7D81; Fri, 12 Sep 2014 10:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43370; q=dns/txt; s=iport; t=1410543004; x=1411752604; h=from:to:cc:subject:date:message-id:mime-version; bh=1/gt1SuSMbW4OdINc1prRtOiyueEWD7u2lQPQK0em/o=; b=GpiJNcGw8e4/fbblb+yTU7PcIuGG2lWJdDyet2LZKjKoNv5BhYQXx70h xWoQuKTNdz1/ZAEZ9cVQpeHpjmSVWKYblxlwbAz4bhdMR3EbPl5F83psi b2G1jMiUjD9qXN4m9GEILUHt7t/MrToYLJ8jJkTtI/kNQ7UAmhp1+qXFq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAOwsE1StJV2Z/2dsb2JhbABGGoJHRlNXBMhxh0wBgRAWeIQFAQQtTBIBKgsLAT8mAQQODROIJw02vVcBEwSMHgGBHoE4BwEBHi0EEYMlgR0FkU2EN4I9kG+JF4NhbAEEgQEJFyKBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,514,1406592000"; d="scan'208,217"; a="77433043" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 12 Sep 2014 17:30:02 +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 s8CHU1UK006222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 17:30:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.160]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 12:30:01 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Minutes Webex 12 September 2014, 6TiSCH WG Thread-Index: Ac/OrveXgbqBszvdT5Wmsz1EG7578Q== Date: Fri, 12 Sep 2014 17:30:00 +0000 Deferred-Delivery: Fri, 12 Sep 2014 17:29:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.3] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842DAD973xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qUKpxBQaEouuPZLWTMk7RW7ssUA Cc: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: [Roll] Minutes Webex 12 September 2014, 6TiSCH WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:30:09 -0000 --_000_E045AECD98228444A58C61C200AE1BD842DAD973xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The 6TiSCH bi weekly call was focused on the compression of the RPL option.= The various options were considered. >From the call, it appears that the uncompressed form of the RPL option in t= he HbH is not acceptable for 6TiSCH due to the size of the frame (127bytes)= . So we need a compression solution from either ROLL or 6lo and are debatin= g which one we'd prefer see. But we need to well advanced in November when = the minimal draft is due to IESG. It is also appears that transporting 20 bits of random data in the flow lab= el as prescribed in RFC 6437 is not acceptable in the LLN. We need to obtai= n an exception from 6MAN for the LLN. draft-thubert-6man-flow-label-for-rpl= -05 concentrates on that exception and the text to use the flow label for R= PL was removed, to be placed in an ROLL draft if the group leans in that di= rection. The discussion on whether it is better to opt for a ROLL solution (based on= flow label) or a 6lo solution was debated. Please find more below, include= d the minutes and the recording: Resources * Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D8b= 6415fd8dff42a99fccf118ff2faa82 * Wiki: https://bitbucket.org/6tisch/meetings/wiki/140912_webex * Slides: https://bitbucket.org/6tisch/meetings/src/master/140912_webex= /slides_140912_webex.ppt Taking notes (can't live without them :) ) 1. Xavi Vilajosana 2. Thomas Watteyne Present (thanks guys!) 1. Thomas Watteyne 2. Pascal Thubert 3. Ariton Xhafa (call in user 3) 4. Dominique Barthel 5. Elvis Vogli 6. Kazushi Muraoka 7. Martin Turon 8. Michael Richardson 9. Pat Kinney 10. Patrick Wetterwald 11. Paventhen Arumugam 12. Qin Wang 13. Rene Struik 14. Sedat Gormus 15. Xavi Vilajosana Action Items * Pascal will post to 6lo and ROLL indicating that these minutes contai= n a discussion on the RPL option for 6TiSCH * Martin should rebound on that Agenda * Administrivia [3min] * Approval agenda * Approval minutes last call * Minimal RPL support for RPL option [30min] * Continue Flow Label vs. 6LowPAN discussion [20min] * AOB [2min] Minutes * _[08.05] Administrivia * last call minutes are approved. No concerns are raised. * Agenda is approved. No concerns are raised. * [08.10] Minimal RPL support for RPL option [30min]_ * Can 6TiSCH live with the HBH ? * [Thomas]It works but would be better to have some compression * [Xavi] can we leave the draft not specifying this? * [Michael] we cannot that otherwise no interop * [Pascal] agreed with Michael, implementations need to know what to= implement for interoperability. we must be clear on what we use. * [Pat Kinney] Do not like HBH. It is not a think that may live for = a long time. * [Thomas] I support that and we need to do something quick. * [Pascal] Zigbee IP uses 15.4g with large frames so 8Bytes are noth= ing compared to their packets so they can survive with that. * Can we reuse the flow label ? * [Xavi] what propose? flow label is not adopted yet, 6lo not workin= g yet on HbH compression * [Pascal] 6man did not reject it. we need to have 6man think about = the rule that a flow label cannot be changed. * [Thomas] Currently 6man requires the end to end flow label. * [Michael] random on a per-flow basis * [Pascal] we still carry 20 bit across the LLN to satisfy the core.= We need to change those rules anyway. * [Pascal] 6man chairs will people to support and want a good reason= . * [Michael] You got consensus on the 6man ML so we can discuss about= that. ROLL Mail trying to move that forward. My take is that we have conse= nsus from 6man, that when a packet enters the LLN we can reset the flow lab= el field. It is consistent with zero-flow label existing practice. Using th= e flow label on a hop by hop basis in the LLN is our matter then. * [Michael] There was silent when asked for consensus about that. * [Martin Turon] Are we talking about the RPL option described in RF= C6553? * [Pascal] yes * Should we go to ROLL or 6lo? * [Pascal] Roll approach: we do something in ROLL? Other approach: w= e propose a solution in 6lowpan that works in 6lowpan world only. The RPL v= ersion might use the Flow Label but some people do not like. The 6lowpan ap= proach can have some benefit but might be limited to 6lowpan networks. Acco= rding to 6lo, hbh header needs only to be compressed in 6lowpan networks. W= ill we be able to have something by November? * [Thomas] There are things that go fast. Do you have a description = of both approaches? * [Pascal] The big difference is whether we compress in 6lowpan or i= n the flow label. The 6lowpan consumes dispatch resources or next header re= sources. * [Thomas] Also, there is the need to clarify the exception to the r= ule for the flow label. Break the rule and define an argument. * [Michael] Is there some place where we can put the rank (changing = part)? instance id can go in the flow label and the rest somewhere else. ca= n the constant part go in the 6lo context? header compression can use the c= ontext. * [Pascal] we need a stable work group document in 2 months. We need= to decide what space in the current headers we use, it is only that. * [Ariton] Would like to see slides on the problem. * [Martin] There is something compelling on using 6lowpan compressio= n. But it exposes a problem in 6lowpan header, it is not clear what the ord= ering should be or it should end. * [Pascal] Well, RFC4944 is clear on the order, and new drafts can b= e clear as well. e.g. Carsten's draft imposes his new dispatch right before= IP_HC. * [Pat] what can happen if both approaches become standards? would e= verything work the same? * [Pascal] We could say 6lo if present else HbH if present else flow= label. Trouble is with source router packets in non-storing going down the= DODAG to the device; they may or may not carry a RPL option, and if the do= not but yet have a flow label, then we might be confused. * [Martin] take into account that in the future more protocols will = be there and we cannot consume many bits in 6LoWPAN compression for a speci= fic protocol such as RPL. Can we accept new routing protocols with the Flow= Label solution? * [Pascal] there is one bit left in the flow label. So we can do wha= t we do with dispatch. If first bit is zero then the FL is used by RPL. Oth= er settings with first bit to 1 reserved for other usages, like another rou= ting protocol in the same LLN. Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD842DAD973xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

The 6TiSCH bi weekly call was focused on the compression of= the RPL option. The various options were considered.

From the call, it appears that the uncompressed form of the= RPL option in the HbH is not acceptable for 6TiSCH due to the size of the = frame (127bytes). So we need a compression solution from either ROLL or 6lo and are debating which one we’d prefer see. But w= e need to well advanced in November when the minimal draft is due to IESG.<= o:p>

It is also appears that transporting 20 bits of random data= in the flow label as prescribed in RFC 6437 is not acceptable in the LLN. = We need to obtain an exception from 6MAN for the LLN. draft-thubert-6man-flow-label-for-rpl-05 concentrates on that exception an= d the text to use the flow label for RPL was removed, to be placed in an RO= LL draft if the group leans in that direction.

The discussion on whether it is better to opt for a ROLL so= lution (based on flow label) or a 6lo solution was debated. Please find mor= e below, included the minutes and the recording:

Resources

Taking notes= (can't live without them :) )

  1. Xavi Vilajosana
  2. Thomas Watteyne

Present (thanks guys!)

  1. Thomas Watteyne
  2. Pascal Thubert
  3. Ariton Xhafa (call in user 3)
  4. Dominique Barthel
  5. Elvis Vogli
  6. Kazushi Muraoka
  7. Martin Turon
  8. Michael Richardson
  9. Pat Kinney
  10. Patrick Wetterwald
  11. Paventhen Arumugam
  12. Qin Wang
  13. Rene Struik
  14. Sedat Gormus
  15. Xavi Vilajosana

Action Items

  • Pascal will post to 6lo and ROLL indicating that these minutes contain a di= scussion on the RPL option for 6TiSCH
  • Martin should rebound on that

Agenda

  • Administrivia [3min]
    • Approval agenda
    • Approval minutes last call
  • Minimal RPL support for RPL option [30min]
  • Continue Flow Label vs. 6LowPAN discussion [20min]
  • AOB [2min]

Minutes

<= span style=3D"mso-list:Ignore">·        _[08.05] Administrivia

    • last call minutes are approved. No concerns are raised.
    • Agenda is approved. No concerns are raised.

<= span style=3D"mso-list:Ignore">·        [08.10] Minimal RPL support for RPL opti= on [30min]_

<= span style=3D"mso-list:Ignore">·        Can 6TiSCH live with the HBH ?

    • [Thomas]It works but would be better to have some compression
    • [Xavi] can we leave the draft not specifying this?
    • [Michael] we cannot that otherwise no interop
    • [Pascal] agreed with Michael, implementations need to know what to implemen= t for interoperability. we must be clear on what we use.
      • [Pat Kinney] Do not like HBH. It is not a think that may live for a long ti= me.
    • [Thomas] I support that and we need to do something quick.
      • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l0 level2 lfo8"> [Pascal] Zigbee IP uses 15.4g with large frames so 8Bytes are nothing compa= red to their packets so they can survive with that.

<= span style=3D"mso-list:Ignore">·        Can we reuse the flow label ?

    • [Xavi] what propose? flow label is not adopted yet, 6lo not working yet on = HbH compression
    • [Pascal] 6man did not reject it. we need to have 6man think about the rule = that a flow label cannot be changed.
    • [Thomas] Currently 6man requires the end to end flow label.
    • [Michael] random on a per-flow basis
    • [Pascal] we still carry 20 bit across the LLN to satisfy the core. We need = to change those rules anyway.
    • [Pascal] 6man chairs will people to support and want a good reason.
    • [Michael] You got consensus on the 6man ML so we can discuss about that. RO= LL Mail trying to move that forward. My take is that we have consensus from= 6man, that when a packet enters the LLN we can reset the flow label field.= It is consistent with zero-flow label existing practice. Using the flow label on a hop by hop basis in the= LLN is our matter then.
    • [Michael] There was silent when asked for consensus about that.<= /li>
    • [Martin Turon] Are we talking about the RPL option described in RFC6553?
    • [Pascal] yes

<= span style=3D"mso-list:Ignore">·        Should we go to ROLL or 6lo?

    • [Pascal] Roll approach: we do something in ROLL? Other approach: we propose= a solution in 6lowpan that works in 6lowpan world only. The RPL version mi= ght use the Flow Label but some people do not like. The 6lowpan approach ca= n have some benefit but might be limited to 6lowpan networks. According to 6lo, hbh header needs only to be= compressed in 6lowpan networks. Will we be able to have something by Novem= ber?
    • [Thomas] There are things that go fast. Do you have a description of both a= pproaches?
    • [Pascal] The big difference is whether we compress in 6lowpan or in the flo= w label. The 6lowpan consumes dispatch resources or next header resources.
    • [Thomas] Also, there is the need to clarify the exception to the rule for t= he flow label. Break the rule and define an argument.
    • [Michael] Is there some place where we can put the rank (changing part)? in= stance id can go in the flow label and the rest somewhere else. can the con= stant part go in the 6lo context? header compression can use the context.
    • [Pascal] we need a stable work group document in 2 months. We need to decid= e what space in the current headers we use, it is only that.
    • [Ariton] Would like to see slides on the problem.
    • [Martin] There is something compelling on using 6lowpan compression. But it= exposes a problem in 6lowpan header, it is not clear what the ordering sho= uld be or it should end.
    • [Pascal] Well, RFC4944 is clear on the order, and new drafts can be clear a= s well. e.g. Carsten's draft imposes his new dispatch right before IP_HC.
    • [Pat] what can happen if both approaches become standards? would everything= work the same?
    • [Pascal] We could say 6lo if present else HbH if present else flow label. T= rouble is with source router packets in non-storing going down the DODAG to= the device; they may or may not carry a RPL option, and if the do not but = yet have a flow label, then we might be confused.
    • [Martin] take into account that in the future more protocols will be there = and we cannot consume many bits in 6LoWPAN compression for a specific proto= col such as RPL. Can we accept new routing protocols with the Flow Label so= lution?
    • [Pascal] there is one bit left in the flow label. So we can do what we do w= ith dispatch. If first bit is zero then the FL is used by RPL. Other settin= gs with first bit to 1 reserved for other usages, like another routing prot= ocol in the same LLN.

 

Cheers,

 

 

Pascal

 

 

--_000_E045AECD98228444A58C61C200AE1BD842DAD973xmbrcdx01ciscoc_-- From nobody Fri Sep 12 11:42:15 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1801A6FC4 for ; Fri, 12 Sep 2014 11:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG_PnaXKF0h4 for ; Fri, 12 Sep 2014 11:42:12 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7F81A6F85 for ; Fri, 12 Sep 2014 11:42:11 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0430.eurprd01.prod.exchangelabs.com (10.242.221.21) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 18:41:48 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1024.012; Fri, 12 Sep 2014 18:41:48 +0000 From: "Turner, Randy" To: "roll@ietf.org" Thread-Topic: Roll Status Pages Thread-Index: Ac/OuRjwdn73P6QLQ3OqoLtLSqOEqg== Date: Fri, 12 Sep 2014 18:41:48 +0000 Message-ID: <1f48bd08112a4ef0a5c9497ea7bb726e@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [148.80.255.144] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(50986999)(33646002)(66066001)(80022001)(54356999)(95666004)(81342001)(81542001)(90102001)(16236675004)(105586002)(99396002)(20776003)(107046002)(64706001)(2351001)(107886001)(106356001)(229853001)(110136001)(15202345003)(15975445006)(85306004)(19625215002)(85852003)(97736003)(19300405004)(2501002)(108616004)(19580395003)(83322001)(86362001)(74502001)(2656002)(4396001)(31966008)(74662001)(83072002)(87936001)(101416001)(21056001)(92566001)(77982001)(74316001)(76482001)(79102001)(46102001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0430; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_1f48bd08112a4ef0a5c9497ea7bb726eDB4PR01MB0431eurprd01pr_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/P6ABRxOWPfYE13OqKdM9-1XO6IM Subject: [Roll] Roll Status Pages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 18:42:13 -0000 --_000_1f48bd08112a4ef0a5c9497ea7bb726eDB4PR01MB0431eurprd01pr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I noticed that RFC 6553 is not in the list of documents on the Roll Status = Page (tools.ietf.org/wg/roll/) Should this be added? Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_1f48bd08112a4ef0a5c9497ea7bb726eDB4PR01MB0431eurprd01pr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

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

 

Should this be added?

 

Randy


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

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

--_000_1f48bd08112a4ef0a5c9497ea7bb726eDB4PR01MB0431eurprd01pr_-- From nobody Fri Sep 12 13:17:01 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BAD1A004C for ; Fri, 12 Sep 2014 13:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fckLAOObpoI for ; Fri, 12 Sep 2014 13:16:58 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4735A1A0083 for ; Fri, 12 Sep 2014 13:16:47 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z11so1592724lbi.35 for ; Fri, 12 Sep 2014 13:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d9cFc9A06ABt48CorkNqmvMPYEeyT72vs/c5rORZWWs=; b=hVEgNZGEtlqQqd6QplrFVYYxOGFTuUt/0pJRnyVovPbJguAYrQeCHkFpWhtFEeZmSH Uw1OBBcUbe1uYyAuBIljE10x/+Q5Mhk62dXdrpyY6bE26PUEjryWfUzQw0A4vJFdd8Xq nPZn80iKkkCl63glc/IBVHEI2QbzNH0RQIXN88CJMBf73LbrWVUCnPJyWDOXNEz+kHwf pPEqvBKcGo8vPIYc2LwQfanrSPLdDKf0tDDRQUGzQRNY8iYLml3j6h0L3Zr+g58R3gxd U2NZZrsIm01wrQPFrDVAhjCin9UFX0ZMGyuLqQ0yC19V9uk3RRrFTogY0C0UcTa6VU1N fmTg== MIME-Version: 1.0 X-Received: by 10.112.130.101 with SMTP id od5mr10893477lbb.76.1410553005590; Fri, 12 Sep 2014 13:16:45 -0700 (PDT) Received: by 10.25.159.75 with HTTP; Fri, 12 Sep 2014 13:16:45 -0700 (PDT) In-Reply-To: <1f48bd08112a4ef0a5c9497ea7bb726e@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> References: <1f48bd08112a4ef0a5c9497ea7bb726e@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> Date: Fri, 12 Sep 2014 22:16:45 +0200 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b343442d5d3eb0502e3f6a2 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6MxFBB72ZERNa-LcPEa2FBYmgIA Subject: Re: [Roll] Roll Status Pages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 20:17:00 -0000 --047d7b343442d5d3eb0502e3f6a2 Content-Type: text/plain; charset=UTF-8 Hi Randy, Thanks for your comments. The document was adopted at that time by 6man. [ http://www.ietf.org/mail-archive/web/ipv6/current/msg11894.html] We will investigate if we can link in some way into the ROLL web page RFCs such as 6553, 6554. Cheers, Ines 2014-09-12 20:41 GMT+02:00 Turner, Randy : > > > I noticed that RFC 6553 is not in the list of documents on the Roll Status > Page (tools.ietf.org/wg/roll/) > > > > Should this be added? > > > > Randy > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legally > privileged. If you are not an intended recipient or an authorized > representative of an intended recipient, you are prohibited from using, > copying or distributing the information in this e-mail or its attachments. > If you have received this e-mail in error, please notify the sender > immediately by return e-mail and delete all copies of this message and any > attachments. Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7b343442d5d3eb0502e3f6a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Randy,

Thanks for your comments.=C2= =A0

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

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

Cheers,<= /div>

Ines


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

=C2=A0

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

=C2=A0

Should this be added?

=C2=A0

Randy


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

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


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


--047d7b343442d5d3eb0502e3f6a2-- From nobody Fri Sep 12 13:22:16 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE1A1A0079 for ; Fri, 12 Sep 2014 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us3D9KZkxq4a for ; Fri, 12 Sep 2014 13:22:12 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF441A0056 for ; Fri, 12 Sep 2014 13:22:12 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0429.eurprd01.prod.exchangelabs.com (10.242.221.20) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 20:21:49 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1024.012; Fri, 12 Sep 2014 20:21:49 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Roll Status Pages Thread-Index: Ac/OuRjwdn73P6QLQ3OqoLtLSqOEqgADWBOA//++WYA= Date: Fri, 12 Sep 2014 20:21:48 +0000 Message-ID: References: <1f48bd08112a4ef0a5c9497ea7bb726e@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [99.1.245.63] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(52314003)(199003)(377454003)(41574002)(189002)(19617315012)(92566001)(20776003)(64706001)(80022001)(86362001)(81542001)(97736003)(92726001)(95666004)(66066001)(81342001)(87936001)(2656002)(83322001)(19580395003)(19580405001)(16236675004)(106356001)(107046002)(107886001)(105586002)(31966008)(74502001)(74662001)(21056001)(79102001)(90102001)(99396002)(110136001)(36756003)(54356999)(77982001)(85852003)(83506001)(83072002)(15975445006)(4396001)(76176999)(46102001)(15202345003)(50986999)(85306004)(76482001)(101416001)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0429; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D038CD7624B5randyturnerlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fW2x49_Fk8gL39ATEFPnNrcnfmk Subject: Re: [Roll] Roll Status Pages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 20:22:15 -0000 --_000_D038CD7624B5randyturnerlandisgyrcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the features of RPL is that it can detect instabilities quickly by i= ncluding rank information with every packet sent - I thought 6553 was how t= his is done...seems more of a ROLL thing than a 6MAN thing in that it's int= imately tide to RPL - Anyway, a link to these docs from the ROLL page is pr= obably good enough... Thanks! R. From: Ines Robles > Reply-To: "roll@ietf.org" > Date: Friday, September 12, 2014 at 4:16 PM To: "roll@ietf.org" > Subject: Re: [Roll] Roll Status Pages Hi Randy, Thanks for your comments. The document was adopted at that time by 6man. [http://www.ietf.org/mail-ar= chive/web/ipv6/current/msg11894.html] We will investigate if we can link in some way into the ROLL web page RFCs = such as 6553, 6554. Cheers, Ines 2014-09-12 20:41 GMT+02:00 Turner, Randy >: I noticed that RFC 6553 is not in the list of documents on the Roll Status = Page (tools.ietf.org/wg/roll/) Should this be added? Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_D038CD7624B5randyturnerlandisgyrcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

One of the features of RPL is that it can detect instabilities quickly= by including rank information with every packet sent – I thought 655= 3 was how this is done…seems more of a ROLL thing than a 6MAN thing i= n that it’s intimately tide to RPL — Anyway, a link to these docs from the ROLL page is probably good enough…

Thanks!
R.

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

Hi Randy,

Thanks for your comments. 

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

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

Cheers,

Ines


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

 

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

 

Should this be added?

 

Randy


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

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


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


 --_000_D038CD7624B5randyturnerlandisgyrcom_-- From nobody Wed Sep 17 00:48:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CE51A0310; Wed, 17 Sep 2014 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrSjACaV3H3w; Wed, 17 Sep 2014 00:48:42 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2801A00D4; Wed, 17 Sep 2014 00:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1885; q=dns/txt; s=iport; t=1410940122; x=1412149722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ryt3LJpKvDVh2ykmMIUIsRBLuuDXlftDoBR5Rx6Eoj4=; b=FBZQrJCkUBHsw0GCA4Wcr6JqGRVHn7UfiPFIPIcRE+kZ49Gfp3HfWpO1 1NrnnFM9W090OYZL0+lR7moyzPWYjhaxbldyb9V1GYmq07gDHcpV1MX3M MfxtCye9STKShdwg3j9dgWSJvuHIV2NsNdFoSCGgp2v6AYV8HaGZ9+ej9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAEQ8GVStJV2Y/2dsb2JhbABggw2BKgTQdAGBFxYBeYQDAQEBBHkMBAIBCA4DBAEBAQodBzIUCQgCBA4FCBOII6lGlAoBF48aMQcGgyiBHQEEiwOGSqEDg15sgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,539,1406592000"; d="scan'208";a="78602010" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 17 Sep 2014 07:48:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8H7mf7b009611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Sep 2014 07:48:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 02:48:41 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts Thread-Index: AQHP0kJzH1qZ2czsj0ybHQLexU1vAZwE7hTQ Date: Wed, 17 Sep 2014 07:48:40 +0000 Deferred-Delivery: Wed, 17 Sep 2014 07:48:00 +0000 Message-ID: References: <037472BD-E257-4561-8A07-988039DD4641@nestlabs.com> <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> In-Reply-To: <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/u7iM6NXcilzGgDkqjg06QK09Tn8 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:48:43 -0000 Hello Carsten: The split and domain-dependent use of the Flow Label field was still on the= table in the RFC 6437 discussions. This was rejected as a general rule but= we still need an exception to RFC 6437 for LLNs so let us see what we get = there. I can still agree with you to progress on a 6lo NHC proposal and produce th= e best personal submission we can for WG evaluation. This in turn does not = mean that 6lo will adopt the work or that ROLL will favor that option.=20 I suggest we focus discussions on the relevant MLs: - 6MAN on whether we can avoid having to set and/or carry a field of random= ized 20 bits in the LLN then eventually rewrite it for LLN purpose - ROLL to decide whether to use a ROLL solution (based on FL is the only on= e on the table) or wait for 6lo to deliver - 6Lo to decide whether and how to compress the RPL option (3 proposals on = the table) In any case copying 6TiSCH, which depends on the overall result to deliver = the minimal draft, is a good idea. Cheers, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: mercredi 17 septembre 2014 08:42 > To: Pascal Thubert (pthubert) > Cc: 6tisch@ietf.org; 6lo@ietf.org > Subject: Re: [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts >=20 > On 17 Sep 2014, at 07:46, Pascal Thubert (pthubert) > wrote: >=20 > > we have one free bit there >=20 > It's not free, all 20 bits of the flow label are the flow label. >=20 > (Again, we can argue dedicating the field that way in 1994, and keeping i= t > that way even while nibbling off bits for other uses, was bad protocol de= sign, > but that's water under the bridge.) >=20 > I would prefer to stop wasting time on trying to hijack the flow label an= d > instead finish the work on an NHC representation. >=20 > Gr=FC=DFe, Carsten From nobody Wed Sep 17 01:02:31 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08801A03E1; Wed, 17 Sep 2014 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL0jUXr15kXD; Wed, 17 Sep 2014 01:02:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843351A03DF; Wed, 17 Sep 2014 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8H8259m019569; Wed, 17 Sep 2014 10:02:05 +0200 (CEST) Received: from [192.168.217.145] (p548903CF.dip0.t-ipconnect.de [84.137.3.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 100B5B78; Wed, 17 Sep 2014 10:02:02 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 17 Sep 2014 10:02:00 +0200 X-Mao-Original-Outgoing-Id: 432633719.993071-68352a572df23452ea67c4e649f36c34 Content-Transfer-Encoding: quoted-printable Message-Id: <0FE1C6E1-EBA2-431D-A2DB-1C3874234827@tzi.org> References: <037472BD-E257-4561-8A07-988039DD4641@nestlabs.com> <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JucujuGXStF24lIzbI5XUU2e9rE Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 08:02:19 -0000 On 17 Sep 2014, at 09:48, Pascal Thubert (pthubert) = wrote: > - 6MAN on whether we can avoid having to set and/or carry a field of = randomized 20 bits in the LLN =20 Laudable, and completely unrelated to the hijacking. (Not on critical path, anyway.) > then eventually rewrite it for LLN purpose Don=92t do that. > - ROLL to decide whether to use a ROLL solution (based on FL is the = only one on the table) or The flow label is not ROLL=92s, so there is nothing to do here. > wait for 6lo to deliver ROLL has waited long enough for consensus to build in 6man around the = flow label hijacking. Not happening. > - 6Lo to decide whether and how to compress the RPL option (3 = proposals on the table) I think we are converging quickly here. Summary: I=92m calling for all involved to stop muddying the water with the dead = flow label hijacking proposal. It is a distraction from the consensus that is being built around a 6lo = solution, and it will never fly. Gr=FC=DFe, Carsten From nobody Wed Sep 17 03:11:37 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE91A0154; Wed, 17 Sep 2014 03:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQl4RhUZFuZr; Wed, 17 Sep 2014 03:11:30 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF56C1A0067; Wed, 17 Sep 2014 03:11:29 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id n8so1515416qaq.12 for ; Wed, 17 Sep 2014 03:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZzskrjH2BNe/cF1zl/9VCIs8TQo8xaMKYAAYhJZ38JY=; b=OF6VDCTZ/WK/puMaDy1zXe+PuETpmRJfhLq7KzR7rYHltfnQWNEUD+3h8YITSTqf9p S7xfNVrFWlVef1W9LA33UAbCMtW7wF7UfJ0bxvgTAZpRLLrU2lwlJW0edMfH/ZodFLAU VhC54Ox3fZdrzAr1EY0/L3hnz7WyLOjA+muk2xYPkDhdhZv/MFw4NHB7ZSY1XQM1eDo9 xioTz2P157i9vYCy4SAlFcQ9YqEBt+1Y+r32rv/v/bHLpMs2w8lwI7MhGppPzRb4kgVj j9bki8eAfg7leAGXqyJA6LjJO4ufugUid+BJJf+O0czZ5fOIYmR7sDpuz3KOZc2dhptd vUZQ== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr50159190yhc.53.1410948688973; Wed, 17 Sep 2014 03:11:28 -0700 (PDT) Received: by 10.170.86.196 with HTTP; Wed, 17 Sep 2014 03:11:28 -0700 (PDT) In-Reply-To: <0FE1C6E1-EBA2-431D-A2DB-1C3874234827@tzi.org> References: <037472BD-E257-4561-8A07-988039DD4641@nestlabs.com> <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> <0FE1C6E1-EBA2-431D-A2DB-1C3874234827@tzi.org> Date: Wed, 17 Sep 2014 12:11:28 +0200 Message-ID: From: Abdussalam Baryun To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0122971c67161c05034017d9 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/U_MolLAbBqaPWbw5ArwIl1L7IKU Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: Comparison of 6lo-rpl drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 10:11:35 -0000 --089e0122971c67161c05034017d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, September 17, 2014, Carsten Bormann wrote: > On 17 Sep 2014, at 09:48, Pascal Thubert (pthubert) > wrote: > > > - 6MAN on whether we can avoid having to set and/or carry a field of > randomized 20 bits in the LLN > > Laudable, and completely unrelated to the hijacking. > (Not on critical path, anyway.) > > > then eventually rewrite it for LLN purpose > > Don=E2=80=99t do that. Why not? > > > - ROLL to decide whether to use a ROLL solution (based on FL is the onl= y > one on the table) or > > The flow label is not ROLL=E2=80=99s, so there is nothing to do here. If this WG decides that we want ROLL's solution decision then we may do cross WGs discussions or cross areas (this in not done much in IETF because still IETF is not flexible or ADs are not promoting that enough). > > > wait for 6lo to deliver > > ROLL has waited long enough for consensus to build in 6man around the flo= w > label hijacking. > Not happening. > > > - 6Lo to decide whether and how to compress the RPL option (3 proposals > on the table) > > I think we are converging quickly here. I think we need to clarify that 3 proposals. So why you think we are doing it quickly. > > Summary: > > I=E2=80=99m calling for all involved to stop muddying the water with the = dead flow > label hijacking proposal. > It is a distraction from the consensus that is being built around a 6lo > solution, and it will never fly. Why you think that it is dead? I don't think it expired yet. What do you mean by consensus built around 6Lo solution, do you mean the 6Lo charter? Why you think that it never fly? I understood Martins proposal but did not understand your reply reasons. AB --089e0122971c67161c05034017d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, September 17, 2014, Carsten Bormann wrote:
On 17 Sep 2014, at 09:48, Pascal Thubert (pthubert= ) <pthubert@cisco.com> wrote:

> - 6MAN on whether we can avoid having to set and/or carry a field of r= andomized 20 bits in the LLN

Laudable, and completely unrelated to the hijacking.
(Not on critical path, anyway.)

> then eventually rewrite it for LLN purpose

Don=E2=80=99t do that.

Why not?
= =C2=A0

> - ROLL to decide whether to use a ROLL solution (based on FL is the on= ly one on the table) or

The flow label is not ROLL=E2=80=99s, so there is nothing to do here.

If this WG decides that we want ROLL's solut= ion decision then we may do cross WGs discussions or cross areas (this in n= ot done much in IETF because still IETF is not flexible or ADs are not prom= oting that enough).=C2=A0
=C2=A0

> wait for 6lo to deliver

ROLL has waited long enough for consensus to build in 6man around the flow = label hijacking.
Not happening.

> - 6Lo to decide whether and how to compress the RPL option (3 proposal= s on the table)

I think we are converging quickly here.

I t= hink we need to clarify that 3 proposals. So why you think we are doing it = quickly.=C2=A0
=C2=A0

Summary:

I=E2=80=99m calling for all involved to stop muddying the water with the de= ad flow label hijacking proposal.
It is a distraction from the consensus that is being built around a 6lo sol= ution, and it will never fly.

Why you think= that it is dead? I don't think it expired yet. What do you mean by con= sensus built around 6Lo solution, do you mean the 6Lo=C2=A0charter? Why you= think that it=C2=A0never fly?

I understood Martin= s proposal but did not understand your reply reasons.=C2=A0

<= /div>

=C2=A0AB
--089e0122971c67161c05034017d9-- From nobody Wed Sep 17 04:05:56 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5481A0203; Wed, 17 Sep 2014 04:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uswhx1wfLdN; Wed, 17 Sep 2014 04:05:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF491A02D9; Wed, 17 Sep 2014 04:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8HB511n016137; Wed, 17 Sep 2014 13:05:01 +0200 (CEST) Received: from [192.168.217.145] (p548903CF.dip0.t-ipconnect.de [84.137.3.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B70A8D4A; Wed, 17 Sep 2014 13:05:00 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 17 Sep 2014 13:04:59 +0200 X-Mao-Original-Outgoing-Id: 432644699.462023-a7006d3a706778c13caef4895a7421ec Content-Transfer-Encoding: quoted-printable Message-Id: <456B8E96-0AB0-4F18-B8A3-601EBAFDDEC4@tzi.org> References: <037472BD-E257-4561-8A07-988039DD4641@nestlabs.com> <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> <0FE1C6E1-EBA2-431D-A2DB-1C3874234827@tzi.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/8lgYVdO8SXgKAUe3xmYcOfPOzKI Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: Comparison of 6lo-rpl drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:05:37 -0000 On 17 Sep 2014, at 12:11, Abdussalam Baryun = wrote: > Why not? RFC 6437 explains what flow labels are and how you can use them. > If this WG decides that we want ROLL's solution decision then we may = do cross WGs discussions or cross areas (this in not done much in IETF = because still IETF is not flexible or ADs are not promoting that = enough).=20 There already was a common WGLC between ROLL and 6man. Initially, there was some flexibility on the 6man side along the lines = of =93if you really have to do this=94. Once it was demonstrated that there is no actual need to hijack the flow = label, the sentiment shifted. I see little point in repeating this experiment. > I think we need to clarify that 3 proposals. So why you think we are = doing it quickly.=20 Because the 6lo WG has a track record of getting things done quickly. (Also, I=92m only aware of a single active proposal, but maybe I haven=92t= been paying enough attention.) > Why you think that it is dead?=20 See above. Gr=FC=DFe, Carsten From nobody Tue Sep 23 11:27:40 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E691A8857; Tue, 23 Sep 2014 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OezDjp7M9JwH; Tue, 23 Sep 2014 11:27:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816F41A8851; Tue, 23 Sep 2014 11:27:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B51D720012; Tue, 23 Sep 2014 14:32:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A3F2B63AE9; Tue, 23 Sep 2014 14:27:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8B16D63AD5; Tue, 23 Sep 2014 14:27:31 -0400 (EDT) From: Michael Richardson To: Carsten Bormann In-Reply-To: <456B8E96-0AB0-4F18-B8A3-601EBAFDDEC4@tzi.org> References: <037472BD-E257-4561-8A07-988039DD4641@nestlabs.com> <2992BA1F-147C-4652-B713-D2F31F45F74F@tzi.org> <0FE1C6E1-EBA2-431D-A2DB-1C3874234827@tzi.org> <456B8E96-0AB0-4F18-B8A3-601EBAFDDEC4@tzi.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Va3wFyMgMYXf5Tz1o7zNLtxS1ho Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] Fwd: Comparison of 6lo-rpl drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 18:27:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > There already was a common WGLC between ROLL and 6man. > Initially, there was some flexibility on the 6man side along the lines > of =E2=80=9Cif you really have to do this=E2=80=9D. > Once it was demonstrated that there is no actual need to hijack the > flow label, the sentiment shifted. > I see little point in repeating this experiment. The 6man WG chairs have not confirmed the conclusion of Ines and I, and we did not observe wuch a "shift". One 6man co-chair is on paternity leave, so perhaps we will still hear from them. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVCG7k4CLcPvd0N1lAQKHWAgAgGvhQhZFmz5k8ZkgesNk3OnmQnA5uZKQ 7l6aTRwE+3cbpjg7KDeEENJtsdYjhSJX8lwBCT3e9HFI186OwhH0lNNcdThBQJaf sVpDP8B/sYjC/UJooBkct78WafYxGMOPmWq4YUcHq0XRvZhEaodmiYdBlJ3PZvA1 jbd5zA+1CkIspHiBchIfD7n56tbNAV0qtnMs1gvw1wadJAdce7FxuEjMIq0j8edU R6PTlJHyeMbFLjTBUSWYqXII99/V0jlRfOX9U28yeJVWFa2JsxhLtZlgxMmHN2dh gWSlAHebpbRV/UPtIyMn5fDoNVll66PTMnAzctyinFGYylng687qwg== =tuQf -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 26 10:19:16 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF71A8034 for ; Fri, 26 Sep 2014 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp4E_Z_8hHFv for ; Fri, 26 Sep 2014 10:19:12 -0700 (PDT) Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B18F1A82E2 for ; Fri, 26 Sep 2014 10:19:12 -0700 (PDT) Received: from [76.14.58.121] (port=50040 helo=[192.168.1.3]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XXZAk-0005SL-Gf; Fri, 26 Sep 2014 10:19:11 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <26959.1410529343@sandelman.ca> Date: Fri, 26 Sep 2014 10:19:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <484D9E4C-3202-4E04-984B-43914D6D7897@cs.stanford.edu> References: <26959.1410529343@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QwhNXcK-6Sxd7uyTagZq01--4ic Cc: roll@ietf.org Subject: Re: [Roll] Use of flow-label in RPL (LLN) networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:19:14 -0000 On Sep 12, 2014, at 6:42 AM, Michael Richardson = wrote: > There are two paths for forward (perhaps more):=20 > A. adopt draft-thubert-6man-flow-label-for-rpl, incorporate 6man = feedback, > publish (perhaps add to ROLL milestones)=20 > B. create a 6man-flow-label considerations in LLNs document, taking = just > the issues about resetting flowlabel to zero, and negotiate who = (6lo vs > ROLL) will adopt draft-bormann-6lo-rpl-mesh=20 B is a better approach. draft-bormann-6lo-rpl-mesh does not require any = updates, changes, notes, or deviations to RFC6437. I originally said = that I thought the reasoning behind = draft-thubert-6man-flow-label-for-rpl (improved energy efficiency due to = reduced header overheads) was sufficient to warrant a second case in = which the flow label was not preserved end-to-end. But that was under = the assumption that we had to twiddle with the flow label in this way. = If we can achieve the same goals without doing so, that is a technically = superior solution. In short, draft-bormann-6lo-rpl-mesh is more efficient (uses fewer bits) = than draft-thubert-6man-flow-label-for-rpl. Furthermore, unlike = draft-thubert-6man-flow-label-for-rpl it complies with RFC6437 and = requires no exceptions. I understand that there is a sense of time pressure here, but I think = that, in the context of standards, expediency is not a good motivation = for decision making. I.e., it's better to have a better standard that = will stick and become the solid technical basis for decades to come, = rather than get something out quick that we'll have to redo.=20 Phil=